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 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
-~----------~----~----~----~------~----~------~--~---
