Ian P. Christian wrote: > 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. >
That's a great use case, indeed. So, we need to fix it ;-) Do you have a patch? Fabien --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
