+1 A very good idea to improve that. On 27 Jan., 17:22, Tom Boutell <[email protected]> wrote: > It's a common convention to handle overriding of actions classes in > plugins by laying out the plugin module in the following way: > > modules/ > foobar/ > actions/ > actions.class.php > lib/ > BasefoobarActions.class.php > > actions.class.php then says this: > > require '../lib/BasefoobarActions.class.php'; > > class foobarActions extends BasefoobarActions { } > > Application developers who want to override it then have to write this: > > require sfConfig::get('sf_plugins_dir') . > '/pluginname/modules/foobar/lib/BasefoobarActions.class.php'; > class foobarActions extends BasefoobarActions { } > > This is strange, knowing we have this cool modern thing called an autoloader. > (: > > May I suggest this: > > Keep the parent classes of the module actions and components classes > for the plugin in the lib/base folder of the plugin. > > I'm doing this with a forthcoming update of our plugins, and it works > well - the autoloader has no trouble finding it. > > Is there a reason why this isn't already common practice? It sure does > make it easier to override plugins! > > -- > 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.
