Where would you register the listener? If it is registered in the form action, this would only be an elaborate extension of the controller logic: instead of creating the Client object and afterwards the User object directly in the controller, I would register a listener in the controller that gets called if a Client is created just in this controller action, which is the same.
If I register it in an application config class, this would lead to inconsistent behaviour, because if I create a Client object in app1, a User object would be created, and in app2 not. This would mean it would have to be registered in the project config. And there it would be triggered by the doctrine:data-load task again (resulting in double users, see my other post) Georg Stéphane schrieb: > The controller isn't responsible for application logic. > It must be in your model (if you can...). > > For this kind of case, I would prefer playing with events. > For example, when user is created just dispatch an event like > "users.user.new" or whatever sounds like. > Then "connect" the app-logic method that add admin-role to user using > eventdispather.connect( 'users.user.new', your class method); > This way the method of creating the user is strictly "limited" to its > area : creating a user; > Then somewhere else (in a dedicated class), write the method which will > add admin-role to the newly created user (which will be the subject of > the event). > Check the doc for more info (event system). > > Before Printing, Think about Your Environmental Responsibility! > Avant d'Imprimer, Pensez à Votre Responsabilitée Environnementale! > > > On Mon, Nov 30, 2009 at 9:37 PM, Bernhard Schussek <bschus...@gmail.com > <mailto:bschus...@gmail.com>> wrote: > > Hi Georg, > > Why don't you just override the save() method of the Client class? You > could, for example, check whether any user is associated with the > client and, if not, do it manually before calling parent::save(). > > I personally would prefer to put this logic into the form for creating > the Client though, because "magic" save-methods can lead to tricky > problems. Is this an option for you? > > Bernhard > > -- > > You received this message because you are subscribed to the Google > Groups "symfony users" group. > To post to this group, send email to symfony-users@googlegroups.com > <mailto:symfony-users@googlegroups.com>. > To unsubscribe from this group, send email to > symfony-users+unsubscr...@googlegroups.com > <mailto:symfony-users%2bunsubscr...@googlegroups.com>. > For more options, visit this group at > http://groups.google.com/group/symfony-users?hl=en. > > > > -- > > You received this message because you are subscribed to the Google > Groups "symfony users" group. > To post to this group, send email to symfony-us...@googlegroups.com. > To unsubscribe from this group, send email to > symfony-users+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/symfony-users?hl=en. -- You received this message because you are subscribed to the Google Groups "symfony users" group. To post to this group, send email to symfony-us...@googlegroups.com. To unsubscribe from this group, send email to symfony-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/symfony-users?hl=en.
