Thomas Rabaix wrote: > > > > > > From: [email protected] > <mailto:[email protected]> > [mailto:[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 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. > > > Let's say you have a Comment Model, on the frontend you will have a > FrontendCommentForm, with only half of the fields are going to be used > (I supposed the comment is linked to a registered user and the comment > is moderated). On the backend side, you will have a BackendCommentForm > with maybe only the moderated status. > > Let's have another example, maybe some form will be used only in the > frontend or in the backend. Having all classes shared in the same > folder, this looks odd (not bad). > > > > > > 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. > > Instead of doing unset to field that we don't want, the form should set > only field required. Let's say you have a form BackendCommentForm, your > client want a new field on the form ( and so on the model), the > FrontendCommentForm will have the new field (as your dev will be not > aware of the FrontendCommentForm). The FrontendCommentForm will be able > to save the new field. > > Now in your configure method you can call a method like this : > > public configure() > { > > $this->useOnly(array('name', 'email', 'message'); > > } > > the useOnly method will remove all other fields. It is far better than > doing : unset($this['user_id'], $this['moderated_status'], ....);
I think there is a ticket on the subject. If not, feel free to open one for symfony 1.3. Fabien > > > > > -- > > Thomas Rabaixhttp://rabaix.net <http://rabaix.net> > > > > > -- > Thomas Rabaix > http://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 -~----------~----~----~----~------~----~------~--~---
