Hi all, I keep seeing the example of the mailer as a dependency of an action, but in reality, aren't dependencies often conditional? For example, sending a mail often depends on whether, say, a form validates. By passing the mailer into the constructor or the method directly, we would "always" instantiate it, even though it's only "sometimes" needed. Having read about the DI container, I was under the impression that it's lazy loading abilities were supposed to fix just that problem, that the mailer is only instantiated when I really (!) need it, not "potentially" need it. Also, isn't the whole point of a DI container configured via yml or xml that I can easily compose one for test scenarios? Maybe I'm thinking too sf1.4 for this discussion, but there we configure different factories for testing purposes as well.
So, in sum, I'm still pretty comfortable with passing the DI container to the constructor as a whole. Daniel On Mar 21, 8:31 am, Lukas Kahwe Smith <[email protected]> wrote: > On 21.03.2010, at 15:29, Fabian Lange wrote: > > > Hi Lukas, > >> hmm not sure how this is superior to just injecting the services into the > >> constructor? seems quite verbose and i am not sure for what gain. > > > there is no big difference. The main one is that you do not need it > > while constructing the object instance. This can be good or bad, > > depending on what you want to do and how you want to use your > > instance. > > Being able to reset could be a use case people might want to use to speed up > unit testing, but there might still be all sorts of other stuff that could > need to be reset for that use case. I still think its insanely verbose so I > would want to see more reasons to favor this approach over injecting into the > constructor (and no I am not counting potentially really long constructor > method signatures as a good enough reason either). > > But this gives me an idea for how to solve the optional method specific > dependencies situation: There could be optional for a [actionname]Setup > method that if defined is called before the action method. At that point its > probably best to then use the approach of matching services names to the > variable names in the method signature. This again would also help in making > it fairly easy to check for what dependencies an action class has (look at > the constructor and any *Setup() methods. > > So just for illustration an action that uses the service "mail" to send a > mail with the email as the request parameter "mail". > > public function showSetup($mail) { > $this->mailer = $mailer; > > } > > public function showAction($content, $mail) { > $this->mailer->setContent($content); > $this->mailer->setTo($mail); > $this->mailer->send(); > > } > > So basically before calling showAction(), there would be a check if there is > a showSetup() and if so the method signature would be introspected to find > variables that match service names and probably throw an exception if > something cannot be matched to a service name. > > Now sure I like my proposed naming convention. I sort of followed the > structure of the "showAction" naming, but I would prefer "setupShow()" since > it starts with "set". But then I would also favor "actionShow()". Hmm .. > > regards, > Lukas Kahwe Smith > [email protected] -- 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.
