Thanks to visit codestin.com
Credit goes to github.com

Skip to content

[Console] Events and InputDefinition problematic #10695

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
Tobion opened this issue Apr 11, 2014 · 5 comments
Closed

[Console] Events and InputDefinition problematic #10695

Tobion opened this issue Apr 11, 2014 · 5 comments
Labels

Comments

@Tobion
Copy link
Contributor

Tobion commented Apr 11, 2014

When listening to the console.command event and trying to access information there are some problems:

  1. You cannot acess arguments or options in the InputInterface like $input->getOption('myoption'); because they are not parsed yet. It's done only later by the application.
    A workaround is something like $command->mergeApplicationDefinition(); $input->bind($command->getDefinition()); inside your listener.
    IMO the input should already have to params bound before the listener. Otherwise the input is pretty useless in listeners. Since people might want to add arguments/options dynamically in a listener (see 2.), the definition probably also needs to be bound after the listener just as now. So it should be done before and after the listener automatically.
    Solved by [Console] Bind input before executing the COMMAND event #15938
  2. Modifying the inputdefinition in a listener does not really work with the help. One can add options/arguments to some commands dynamically like in http://php-and-symfony.matthiasnoback.nl/2013/11/symfony2-add-a-global-option-to-console-commands-and-generate-pid-file/. But this will not properly work with the help display because running the help for a command (app/console mycommand --help) will actually run the HelpCommand and an event for this command. Thus the definition is not modifying for the "mycommand" but for the help. So the changed definition is not displayed.
@Tobion Tobion added the Console label Apr 28, 2014
@Taluu
Copy link
Contributor

Taluu commented Sep 1, 2014

+:100:, especially for the 1st bullet point. In my case, we need to check if an option exists, if it has a value, and then feed another object (a bag) if it has a valid value.

But, I think I'm gonna need to do the workaround @Tobion is describing (the mergeApplicationDefintion etc).

A solution would be to maybe fire another event, which is fired after the input is bound ?

@konradpodgorski
Copy link

👍

I noticed your issue after writing mine here #11912

@jaredm4
Copy link

jaredm4 commented Jun 10, 2015

+1. The arguments are not compiled until $command->run() is executed. The argument parsing should happen prior to the run. Additionally, to not introduce breaking changes, we could possibly add a new Event that happens after parsing them, so that the COMMAND event still happens before parsing.

fabpot added a commit that referenced this issue Sep 30, 2015
…t (WouterJ)

This PR was merged into the 2.8 branch.

Discussion
----------

[Console] Bind input before executing the COMMAND event

| Q             | A
| ------------- | ---
| Bug fix?      | no
| New feature?  | yes
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | #10695 (problem 1)
| License       | MIT
| Doc PR        | -

Previously, `$input` wasn't very usefull in the `console.command` event, as the input was not yet bound to the command definition.

With this PR, the input is now bound twice: Once before the event is dispatched (to make it usefull in the listeners) and once at the original location in `Command#run()` (to allow changing the input definition in an event listener).

Commits
-------

0af1676 Bind input before executing the COMMAND event
@Tobion
Copy link
Contributor Author

Tobion commented Oct 18, 2015

Closing this as the first main point has been fixed. I don't see a solution for the second one about the help. In theory the help could be different depending on arguments or any other runtime config. So there seems no generic way to adjust the help when a command is reconfigured using a listener.

@Tobion Tobion closed this as completed Oct 18, 2015
@punkeel
Copy link

punkeel commented Nov 17, 2015

Thanks for having this fixed :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants