Yes, that's exactly right. I had forgotten about that BC detail. This should definitely be noted in the documentation.
Thanks, Kris On Oct 4, 2009, at 9:19 AM, Tom Boutell <[email protected]> wrote: > > Vojta, thank you for the clue! > > The issue is this: > > 1. plugins/pluginNamePlugin/config/config.php does NOT run in a task. > > 2. But plugins/pluginNamePlugin/config/ > pluginNameConfiguration.class.php::initialize() > DOES run in a task. > > I am now successfully extending project:permissions. > > I will add a note about this and close the related ticket in trac. > > I think config/config.php is mostly there just for backwards > compatibility, so I guess this makes a certain amount of sense: old > Symfony 1.0 code would assume there is always an application and an > environment. > > config/config.php is still used by common plugins like > sfDoctrineGuardPlugin. Should that change? The limitations of > config/config.php need to be documented somewhere. > > On Sun, Oct 4, 2009 at 9:48 AM, Vojta <[email protected]> wrote: >> >> As I know, sf tasks (in 1.2, in 1.0 not) does not load app >> configuration, only project configuration. >> But tasks have a dispatcher, so you can use events inside the task. >> Plugins are loaded when you initialize the ProjectConfiguration (or >> App) - and thats done, when you are running a task. So, plugins are >> loaded in tasks and also can use events. >> Maybe Im missing something... >> Best regards, >> V.J. >> >> On Oct 3, 6:00 am, Tom Boutell <[email protected]> wrote: >>> I'm trying to take advantage of the command.post_command event, >>> which >>> is posted by all tasks after they complete their business. The goal >>> was to extend project:permissions to handle an additional folder. >>> >>> I couldn't figure out why registering a handler for this event from >>> the config.php file of a plugin had no effect. >>> >>> Finally I tried putting blatant typos (things that should produce a >>> PHP parse error) in the config.php file of a known-good plugin, >>> sfDoctrineGuardPlugin. >>> >>> I found that Symfony tasks still didn't fail. While 'php >>> web/frontend_dev.php' did fail. >>> >>> By doing a bit of testing on web/index.php, I determined that >>> require_once(dirname(__FILE__).'/../config/ >>> ProjectConfiguration.class.php'); >>> doesn't load >>> the plugin configuration classes and config.php files. That doesn't >>> happen until we get to: >>> >>> $configuration = >>> ProjectConfiguration::getApplicationConfiguration('frontend', >>> 'prod', >>> false); >>> >>> It appears that the sfCommandApplication class used for tasks never >>> does the equivalent. So no plugin configuration code is ever run by >>> tasks. >>> >>> Is this a bug in Symfony 1.2.9-DEV? If not, is there any way for a >>> plugin to register an event handler so that it can do something >>> useful >>> with events posted by a task? >>> >>> Thanks! >>> >>> -- >>> Tom Boutell >>> P'unk Avenue >>> 215 755 1330 >>> punkave.com >>> window.punkave.com >>> >> > > > > -- > Tom Boutell > P'unk Avenue > 215 755 1330 > punkave.com > window.punkave.com > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en -~----------~----~----~----~------~----~------~--~---
