Keep in mind that your BaseForm or BaseFormDoctrine class can extend a class in a plugin. This means you can write a single base class to be extended by all of your applications (and perhaps those of others as well).
On Fri, Dec 11, 2009 at 5:41 PM, ashton honnecke <[email protected]> wrote: > At the risk of sounding dense, why can this not be added at this point? > > (Adding logic to BaseFormDoctrine is the way that I solve this currently.) > > On Fri, Dec 11, 2009 at 3:27 PM, Kris Wallsmith > <[email protected]> wrote: >> I would recommend you add logic to BaseFormDoctrine that unsets these >> fields. The other option is to use the form.post_configure event, but that >> seems too complicated for this case. >> The solution some of you are asking for would involve the Timestampable >> behavior listening to the form.post_configure event and removing the *_at >> fields, but this obviously can't be added to the symfony core at this point. >> Thanks, >> Kris >> >> -- >> Kris Wallsmith | Release Manager >> [email protected] >> Portland, Oregon USA >> http://twitter.com/kriswallsmith >> On Dec 11, 2009, at 2:06 PM, ashton honnecke wrote: >> >> The admin generator could simply not add widget or form for >> "created_at" or "updated_at" (in BaseObjectForm). If one wanted that >> behavior, it could be added in ObjectForm. >> >> On Fri, Dec 11, 2009 at 2:59 PM, Alex Gilbert <[email protected]> wrote: >> >> Is that something that could possibly be controlled by the >> >> Timestampable behavior? Does that even make sense to try and implement >> >> - Doctrine behaviors being able to influence how the objects' forms >> >> are created? Is that being done somewhere already? I feel like I've >> >> seen it before. >> >> On Fri, Dec 11, 2009 at 4:55 PM, ashton honnecke <[email protected]> >> wrote: >> >> So you are suggesting that I edit the generator.yml for every admin module? >> >> I think that following "convention over configuration" it seems wrong >> >> that I should have to jump through the same hoop every time I generate >> >> an admin module. >> >> Unless there are a bunch of people that want to edit created_at out there? >> >> On Fri, Dec 11, 2009 at 12:20 PM, Lukas Kahwe Smith <[email protected]> >> wrote: >> >> On 11.12.2009, at 19:47, Richtermeister wrote: >> >> Hey Felix, I believe the reason is that the admin generator is the >> >> wrong place to hide those fields.. >> >> Not displaying the fields doesn't remove them from the form, so in >> >> effect you'd be submitting empty values for those fields. >> >> Could be wrong, but I believe that's one of the issues.. >> >> Daniel >> >> >> On Dec 10, 1:45 pm, Felix Ebert <[email protected]> wrote: >> >> It's a miracle for me why ticket 6836 got closed. I thought that >> >> Symfony is a framework with the principle "convention over >> >> configuration" - and I don't see any usecase of displaying the >> >> created_at and updated_at fields in the auto-generated forms by >> >> default. >> >> >> for a solution have a look here: >> >> http://trac.symfony-project.org/ticket/5296 >> >> regards, >> >> Lukas Kahwe Smith >> >> [email protected] >> >> >> >> -- >> >> 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. >> >> >> >> >> -- >> >> 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. >> >> >> >> >> >> >> -- >> >> Alex Gilbert >> >> P'unk Avenue >> >> 215-755-1330 >> >> [email protected] >> >> -- >> >> 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. >> >> >> >> >> -- >> >> 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. >> >> >> >> -- >> >> 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. >> > > -- > > 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. > > > -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.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.
