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.
