I hope, its better to use the config classes... Its more flexible. I hope, all these config.php files should be removed in SF1.3. I cant see the reason, why use them... V.
On Oct 4, 6:19 pm, 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 -~----------~----~----~----~------~----~------~--~---
