[FrameworkBundle] Added events for CLI commands #6124

bamarni · 2012-11-26T23:13:56Z

Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes

Fixes the following tickets: #1929, #3889

I've allowed myself to continue the effort from @flevour in #3889 as it was only missing unit tests and a small tweak from my pov, I've kept the authorship in the commit.

stof · 2012-11-26T23:17:44Z

src/Symfony/Bundle/FrameworkBundle/Console/Event/ConsoleEvent.php

+ * file that was distributed with this source code.
+ */
+
+namespace Symfony\Bundle\FrameworkBundle\Console\Event;


I would move the event object outside the Console namespace

You mean Symfony\Bundle\FrameworkBundle\Event\ConsoleEvent?

lsmith77 · 2012-11-27T09:13:52Z

+1

everzet · 2012-11-27T09:22:42Z

👍

lolautruche · 2012-11-27T09:30:23Z

src/Symfony/Bundle/FrameworkBundle/Console/AbstractCommand.php

+     */
+    public function run(InputInterface $input, OutputInterface $output)
+    {
+        $doDispatch = $this->dispatcher && !$this->isSilent();


Better do an isset($this->dispatcher) ?

Why the isSilent here ?

@rande : I think it's better to check it here too, relying only on whether or not the dispatcher is there is not entirely true as it is just an optimization of the current application, avoiding the service to be build when it is not needed, checking here too makes the command more robust.

@lolautruche : I don't think it is a big deal, and I often see this without isset() in symfony code.

lolautruche · 2012-11-27T09:34:59Z

👍

pborreli · 2012-11-27T09:39:35Z

src/Symfony/Bundle/FrameworkBundle/Console/AbstractCommand.php

+    private $dispatcher;
+
+    /**
+     * Wether or not events should be dispatched for the command.


DenisGorbachev · 2012-12-08T10:15:38Z

I second this PR, very much needed.

bamarni · 2012-12-08T12:01:08Z

What are the use-cases for this? The only one I saw was the swiftmailer
command to send emails from the spool, which currently fails when it
comes to memory spool, as it uses the kernel.terminate event.

Ideally this capability should be on top of ContainerAwareCommand not to
mess up the Application, here I've kind of blindly implemented what was
discussed on the original ticket, which was to add this on all commands
excepted cache:clear, but it just leads to a dirty hack imo.

Excepted commands one define himself, most of them are just isolated
tools for the application / developer, as such it looks weird to me to
know that potentially emails could be sent when I run any of them.

I'd suggest to have an EventDispatchingCommand extending
ContainerAwareCommand, and that's it. I'd also suggest to provide traits
support for this, which should be the best way to easily plug
capabilities to commands on the long-term whitout running into hacks.

What do you think?

stof · 2012-12-08T12:52:08Z

I see another use case: setting the base url in the routing RequestContext so that generated urls are right.

and for Swiftmailer, it would send emails only if your command send an email. The MemorySpool will never send an email spooled in a different proces.

I don't like the idea of introducing a separate class for this. It would mean that every developer writing a command would have to decide if the command will dispatch events or no, making it confusing for people using the event ("Why don't I see the event for this command ?")

bamarni · 2012-12-08T15:06:11Z

For the swiftmailer issue my fault indeed it's about sending emails from
commands with the memory setting, and for your other use case yes it's
interesting, while those use cases are very common (eg. newsletter), I
don't see why they should affect all other commands, people needing
those kind of feature could just extend a command on top of
ContainerAwareCommand (EventDispatchingCommand or even AbstractCommand
to allow new features later on),

I'm not against making all commands dispatching events in the absolute,
but unfortunately it complicates the code, remember it'd also forces us
to allow disabling it (cache clear command) or to somehow manually
disabling it for this command, while I could practically revert all the
changes of this PR if we choose my first suggestion and come up with a
single class addition.

lsmith77 · 2012-12-08T17:26:36Z

my initial use case was a header I had to set on specific http connections that were triggered both on the web site as well as CLI.

bamarni · 2012-12-09T12:36:58Z

I've just took time to look at it and I've been able to implement @stof suggestion without so much pain, so I'm fine with all commands dispatching events.

stof · 2012-12-09T14:06:45Z

src/Symfony/Bundle/FrameworkBundle/Command/CacheClearCommand.php

 {
+    protected $dispatcher;


why the dispatcher here ?

typo => container
Le 9 déc. 2012 15:07, "Christophe Coevoet" [email protected] a
écrit :

In src/Symfony/Bundle/FrameworkBundle/Command/CacheClearCommand.php:

{

protected $dispatcher;

why the dispatcher here ?

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/6124/files#r2358459.

This adds an init and terminate event for commands. They are dispatched from ContainerAwareCommand. The cache:clear command can't implement this (cf. #3889 on Github).

bamarni · 2012-12-09T18:44:30Z

from my pov this PR is now finished.

ghost · 2012-12-29T00:22:08Z

@bamarni - I think you need to rebase this to current master as it cannot be automatically merged as it stands.

Conflicts: src/Symfony/Bundle/FrameworkBundle/CHANGELOG.md

bamarni · 2012-12-29T11:35:52Z

argh... it should be fixed now, thx

bamarni · 2013-01-06T13:50:02Z

Is it too late for adding this to 2.2? As a reminder this in not only a new feature, but it'd provide a way to fix a bug, with the standard edition, by default, all mails sent from commands are lost (cf. symfony/symfony-standard#249).

cc @fabpot

lsmith77 · 2013-01-30T15:05:16Z

ping

attilabukor · 2013-01-30T15:11:06Z

I think it would be nice to have it in 2.2 too.

rande · 2013-01-30T15:13:10Z

+1000

marcospassos · 2013-02-02T21:44:14Z

+1

marcospassos · 2013-02-02T22:15:32Z

IMO the dialog helper should be passed through the event. I've an use case of a multitenant application that I need to ask the host before some commands are executed (like doctrine:*), in order to set the RequestContext.

XWB · 2013-02-05T08:57:44Z

+1 I was looking for such an implementation, it would be nice to have it in 2.2

@fabpot ping

startupz · 2013-02-06T09:21:10Z

I need it too

@fabpot ping

bamarni · 2013-02-06T10:23:30Z

I've added the helperSet as per @marcospassos suggestion and also made the tests more robusts by checking both events are getting dispatched properly.

startupz · 2013-02-21T11:14:07Z

Up

XWB · 2013-02-22T08:46:12Z

@fabpot ping

bamarni · 2013-02-22T09:24:42Z

there is no need to ping I guess :) 2.2 is in rc now, so it's obviously too late, and this is not the best moment for the core team to review 2.3 features.

XWB · 2013-02-22T22:23:08Z

Fair enough :)

lsmith77 · 2013-03-06T18:55:25Z

i guess now its time to ping again :)

XWB · 2013-03-07T08:34:04Z

@fabpot ping ;)

fabpot · 2013-03-25T19:41:19Z

closing in favor of #7466

This PR was merged into the master branch. Discussion ---------- Console dispatcher | Q | A | ------------- | --- | Bug fix? | no | New feature? | yes | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | #3889, #6124 | License | MIT | Doc PR | symfony/symfony-docs#2352 refs #1884, #1929 This is an alternative implementation for adding events to console applications. This implementation has the following features: * Available for anyone using the Console component and it is not tied to FrameworkBundle (this is important as one thing we are trying to solve is email sending from a command, and frameworks like Silex using the Console component needs a solution too); * Non-intrusive as the current code has not been changed (except for renaming an internal variable that was wrongly named -- so that's not strictly needed for this PR) * The new DispatchableApplication class also works without a dispatcher, falling back to the regular behavior. That makes easy to create applications that can benefit from a dispatcher when available, but can still work otherwise. * Besides the *before* and *after* events, there is also an *exception* event that is dispatched whenever an exception is thrown. * Each event is quite powerful and can manipulate the input, the output, but also the command to be executed. Commits ------- 4f9a55a refactored the implementation of how a console application can handle events 4edf29d added helperSet to console event objects f224102 Added events for CLI commands

stof reviewed Nov 26, 2012
View reviewed changes

lolautruche reviewed Nov 27, 2012
View reviewed changes

pborreli reviewed Nov 27, 2012
View reviewed changes

stof reviewed Dec 9, 2012
View reviewed changes

[FrameworkBundle] Added events for CLI commands

e429365

This adds an init and terminate event for commands. They are dispatched from ContainerAwareCommand. The cache:clear command can't implement this (cf. #3889 on Github).

Merge branch 'master' into standard-events-cli

9270e1c

Conflicts: src/Symfony/Bundle/FrameworkBundle/CHANGELOG.md

bamarni added 2 commits February 6, 2013 11:19

[FrameworkBundle] added helperSet to console event objects

41557c9

[FrameworkBundle] tweaked some tests

4a630fd

Merge branch 'master' into standard-events-cli

211b57d

This was referenced Mar 23, 2013

[2.2] [FrameworkBundle] Add events to console commands #3889

Closed

Console dispatcher #7466

Merged

fabpot closed this Mar 25, 2013

marcospassos mentioned this pull request Nov 19, 2013

[Console] Consider adding an event that allow us intercept events #9538

Closed

Uh oh!

[FrameworkBundle] Added events for CLI commands #6124

[FrameworkBundle] Added events for CLI commands #6124

Uh oh!

Conversation

bamarni commented Nov 26, 2012

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lsmith77 commented Nov 27, 2012

Uh oh!

everzet commented Nov 27, 2012

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lolautruche commented Nov 27, 2012

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

DenisGorbachev commented Dec 8, 2012

Uh oh!

bamarni commented Dec 8, 2012

Uh oh!

stof commented Dec 8, 2012

Uh oh!

bamarni commented Dec 8, 2012

Uh oh!

lsmith77 commented Dec 8, 2012

Uh oh!

bamarni commented Dec 9, 2012

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bamarni commented Dec 9, 2012

Uh oh!

ghost commented Dec 29, 2012

Uh oh!

bamarni commented Dec 29, 2012

Uh oh!

bamarni commented Jan 6, 2013

Uh oh!

lsmith77 commented Jan 30, 2013

Uh oh!

attilabukor commented Jan 30, 2013

Uh oh!

rande commented Jan 30, 2013

Uh oh!

marcospassos commented Feb 2, 2013

Uh oh!

marcospassos commented Feb 2, 2013

Uh oh!

XWB commented Feb 5, 2013

Uh oh!

startupz commented Feb 6, 2013

Uh oh!

bamarni commented Feb 6, 2013

Uh oh!

startupz commented Feb 21, 2013

Uh oh!

XWB commented Feb 22, 2013

Uh oh!

bamarni commented Feb 22, 2013

Uh oh!

XWB commented Feb 22, 2013

Uh oh!

lsmith77 commented Mar 6, 2013