On Sun, Mar 21, 2010 at 12:36 PM, Lukas Kahwe Smith <[email protected]> wrote: > > On 21.03.2010, at 11:45, Marijn <[email protected]> wrote: >> Personally I don't see why we should try to make this problem more >> complicated than it is. >> By using a one class per controller approach we can have this >> implemented in no time without any new magic. > > that does solve the issue at hand. for smaller projects this might be the > best approach even especially if you follow the fat model approach. but for > larger projects i think this will become a bit painful to manage. > > this however is another argument for the constructor way along with some > solution to deal with heavy optional dependencies.
I would also favor the services in constructors, and keeping routing args in methods. From my experience on our Okapi2 project that passes the services in the constructor, I would say in most cases, all your methods end up using all the same services, except for the optional mailer one, or a very rare extra helper class that is needed. For those cases, a solution that I would see is defining a variable naming convention where, say, if you name a method arg $svcMailer (or $_Mailer?) you would get the mailer service. This would avoid naming issues with routing args, and seems fairly straightforward. If you go this way please prevent the definition of any route variable matching this, to avoid all conflicts. The other approaches, which would basically be up to the users to implement are: - build a small wrapper class that does nothing but lazy-load the expensive (i.e. mailer) lib, fairly easy to do but should we have to? - just live with it if it's in a not too stressed out part of your application, you can't really rely on that being the case always - split it up in another controller, feasible but inconvenient because it adds separation in actions that logically belong together Cheers, Jordi -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.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 To unsubscribe from this group, send email to symfony-devs+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
