Fabien POTENCIER wrote: > I never use the per-action classes and I think there is never a good > reason to use them. > > The execute() or executeXXX() method for an action always contain very > little code (... if not, then you probably need to refactor your code > and move some parts to the model or to helper classes). So, it makes > sense to only have one action class for all methods. > > My point is: do we really need to keep them around (except for BC > reasons)? What about deprecating the per-action classes support for > symfony 1.1 and remove them in 1.2?
We use them for a reasonably good reason. We deploy a symfony application to a client, and allow him to write his own action classes, and override ours - this is achieved via the patch I posted to the list a few days ago (look for subject 'RFC'). This means we deploy into /usr/share/our_app, and they can just drop in classes into their own 'overlay' directory. This allows them to provide their own implementation of actions, override config settings , override templates etc. The per-action classes make this far easier for us. -- Ian P. Christian ~ http://pookey.co.uk --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
