I understood your point the first time but my answer was not complete enough. And it's good you ask again because I thought again about it and changed my mind.
In fact, the behavior you talk about (automatic value for special fields like updated_at) is provided by the ORM (Propel or Doctrine) in the Model layer. Of course, the ORM is not aware of the view, and should not be. All it does is generating a value for special fields, but only when no value (even null value) is provided by the caller (the controller layer). Each field present in the form is mapped to the object sent to the ORM when the controller processes the form. So, the only way to let the ORM handle special fields for you is to remove them from the form with the unset function. I got this in mind when writing my previous answer and thought: the only way to provide the same behavior for a field which is not displayed than for a field which is unset is to automatically unset it in the generated controller. But I think I was wrong when I said that it was not possible. At first sight, I thought it would imply to unset the fields in the generated form. This is not possible because this form is shared by all views. But in fact it could probably be done in the generated actions which are aware of the views. For example the generated *executeCreate* method could unset all fields which are not displayed in the *new* view. My opinion now is that it could be worth opening a ticket for enhancement and see what the symfony team thinks about it. There could be some other problem that I missed. Damien 2008/12/30 Jonathan Franks <jonat...@ifranks.com> > > Perhaps i'm not being clear. Some yaml... > > edit: > display: > "item details": [ stocknumber, description, price ] > > My form also has several fields that are not displayed. For instance > 'updated_at'. I would expect that the symfony automagic update_at > field would still work properly with the above generator.yml but it > actually writes a null value to the database. In order to get the > 'updated_at' field working properly, I have to unset that field in the > form class. In fact, all fields that are not included in the display > option (excluding id) get written to the database with a null value > unless I unset them in the form class. > > To my mind, not including the field in the display option should have > the same effect as unsetting it. > > Do you see what I mean now?? > > > On 29 Dec 2008, at 22:51, Damien Lepage wrote: > > > Hi, > > > > I think there is a good reason: the form is shared between different > > views and you have different levels of configuration for them. For > > example, it does not make sense to unset a field because it is not > > displayed in the list view. It does not make sense either to unset a > > field because it is not displayed at the form level because the > > display option could be overriden for the edit or new view. > > > > Damien > > > > > > > > 2008/12/29 Jonathan Franks <jonat...@ifranks.com> > > > > Yes, it is the behavior but is it the intended behavior?? > > > > I can't think of any reason why the generator.yml display option > > behaves like this. To me, it seems like a bug. But i'm wondering if > > there is a good reason that I've missed?.... > > > > > > > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 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 -~----------~----~----~----~------~----~------~--~---
