On Mar 5, 2009, at 8:30 PM, Jan Markmann wrote:
> > > > On 5 Mrz., 18:17, "J.Philip" <[email protected]> wrote: >> I also have this ticket <http://trac.symfony-project.org/ticket/ >> 5014> pending for 1.3 to allow for custom generator classes to be >> used by the build-forms and build-filters tasks so that we can >> customize the generation process. > > That is half way possible. sfGenerator used to have an attribute > "theme" which was there from the very beginning of symfony. > So the generator itself can take different themes into account when > generating what ever you need generated today, but most of the cli > tasks dont take a theme option they could pass to the generator. > So most of the time the generator only uses one single theme the > "default" theme. > I dont think custom generators are needed since the one generator can > use custom themes of that option would be available in tasks (would be > easy to patch the option into all tasks using sfGenerator). > > >> From: [email protected] [mailto:[email protected] >> ] On Behalf Of Thomas Rabaix >> Point 1 : >> I think symfony generates to many classes : Form and Filter. I will >> prefer to generates this class only when required, having less >> class cannot be bad. > > Some options with the tasks would be nice again to specify what forms > should be generated, give it some model classes to generate forms for > or generate for all classes. Just like propel:data-dump. > >> Point 2 : >> Next, It is bad to generate project wide form/filter classes as >> depends on the application validation maybe changes : admin can >> have more control over the form. So the generator have to generate >> 3 files >> >> * BaseYourModelForm.class.php : file with the basic widget >> definition as now >> * SharedYourModelForm.class.php : the dev can globally >> overwrite definition from BaseYourModelForm (acts like the current >> YourModelForm) >> * YourModelForm : inside the application lib > > NO! > symfony has to generate a project wide form., If you want have forms > that differ from each other create forms extending the project wide > ones. You can extend the project wide form for each application, > module or use case. I should have read the full contents of my mailbox before replying. You make an excellent point here Jan:-) > I dont see any general usecase the extending forms should be generated > for. You can not know if some usecase needs 3 extending forms for one > application or 1 extending form per application or no extending form > at all or even forms extrending the extending forms =) > Just extend the YourModelForm soon enough and use YourModelForm only > for changes that should be common to all its extending variants. > > >> >> Point 3 : >> Model Form should have a method to define which fields we want to >> use. This will avoid bugs when adding new field into the model, as >> the base form will use them on update. >> >> -- >> Thomas Rabaixhttp://rabaix.net > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
