Hi Stéphane, I don't understand what you mean.
To clarify: I would like to put the business logic in the model. The business logic states in my case that no "Client" object can be without a "User" object. Following this reasoning, I added a postInsert() method in the "Client" object, that creates a "User" object. IMO the only way to make sure that no "Client" objects without a defined state can exist (ie without a "User" object). This works like expected in my applications, the "Client" object and all related objects (ie it's "User" object, ...) are always in a defined state after creation, no matter where they are created. The problem starts when I try to reset my database for unit tests. If I use the task doctrine:data-load, an unwanted (at least by me ;-)) side effect happens. doctrine:data-load first inserts the "Client" object, and this triggers the postInsert() logic, creating a new "User" object implicitly. And then doctrine:data-load continues with inserting the "User" object that the "Client" object already had a the time when I created the fixture. The result is that the doctrine:data-load task changes the content of the database in one doctrine:data-dump and doctrine:data-load cycle (adding an additional "User" object). This means I am not able to unit test my model or to test any application logic, because I cannot load clean data in the database for each test. There is already a ticket for this: http://trac.symfony-project.org/ticket/5799 but it was set to invalid. I see the following solutions to get doctrine:data-load to work with my business logic. I am rather not a symfony expert, I hope I am missing something obvious, and I just didn't find it in the docs. This also explains the email's subject "Where to put the logic": * Move the business logic to the controllers: In this case doctrine:data-load would not trigger the creation of a "User" object for each new "Client" object that is saved, because it is not in the model. But I would have to make sure that the controller logic is the same everywhere a "Client" object is created. * Find a way to check in the postInsert method if I am running from a doctrine:data-load task, and in this case skip the business logic. IMO this would add controller logic in the model, but if I could identify the doctrine:data-load task, this would be my preferred approach. * To have an argument for the doctrine:data-load task, not to trigger the doctrine events. * Did I miss something obvious? Thanks for reading up to here (in case anyone sees this :-D) Georg Stéphane schrieb: > First, Hello (sorry) :-) > > I was assuming this was happening to one of your class; is this > happening to all/other classes ? > > Before Printing, Think about Your Environmental Responsibility! > Avant d'Imprimer, Pensez à Votre Responsabilitée Environnementale! > > > On Thu, Dec 3, 2009 at 10:53 PM, Georg Gell <geor...@have2.com > <mailto:geor...@have2.com>> wrote: > > 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 "User"s, 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 > > ""User"s."User".new" or whatever sounds like. > > Then "connect" the app-logic method that add admin-role to "User" using > > eventdispather.connect( '"User"s."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> > > <mailto: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 "User"s" group. > > To post to this group, send email to > symfony-"User"s...@googlegroups.com > <mailto:symfony-"User"s...@googlegroups.com> > > <mailto:symfony-"User"s...@googlegroups.com > <mailto:symfony-"User"s...@googlegroups.com>>. > > To unsubscribe from this group, send email to > > symfony-"User"s+unsubscr...@googlegroups.com > <mailto:symfony-"User"s%2bunsubscr...@googlegroups.com> > > <mailto:symfony-"User"s%2bunsubscr...@googlegroups.com > <mailto:symfony-"User"s%252bunsubscr...@googlegroups.com>>. > > For more options, visit this group at > > http://groups.google.com/group/symfony-"User"s?hl=en. > > > > > > > > -- > > > > You received this message because you are subscribed to the Google > > Groups "symfony "User"s" group. > > To post to this group, send email to > symfony-"User"s...@googlegroups.com > <mailto:symfony-"User"s...@googlegroups.com>. > > To unsubscribe from this group, send email to > > symfony-"User"s+unsubscr...@googlegroups.com > <mailto:symfony-"User"s%2bunsubscr...@googlegroups.com>. > > For more options, visit this group at > > http://groups.google.com/group/symfony-"User"s?hl=en. > > -- > > You received this message because you are subscribed to the Google > Groups "symfony "User"s" group. > To post to this group, send email to symfony-"User"s...@googlegroups.com > <mailto:symfony-"User"s...@googlegroups.com>. > To unsubscribe from this group, send email to > symfony-"User"s+unsubscr...@googlegroups.com > <mailto:symfony-"User"s%2bunsubscr...@googlegroups.com>. > For more options, visit this group at > http://groups.google.com/group/symfony-"User"s?hl=en. > > > > -- > > You received this message because you are subscribed to the Google > Groups "symfony "User"s" group. > To post to this group, send email to symfony-"User"s...@googlegroups.com. > To unsubscribe from this group, send email to > symfony-"User"s+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/symfony-"User"s?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.
