Hi devs,

I was thinking about the way the `generator.yml` could work in sf 1.2
for the customization of the edit forms and of the filter forms. These
forms can be overridden in the generated class, and the
`generator.yml` should be able to do pretty much the same as what the
sfForm API offers.

Maybe a good way is to add a 'widgets' and a 'validators' key for the
'edit' and 'filter' keys, and all the parameters set there would
override the ones generated by symfony based on the schema.

Let's use an example. Here is the schema (one Author has many Articles):

    [yml]
    // config/schema.yml
    propel:
      article:
        id:           ~
        title:        { type: varchar(255), required: true }
        slug:         { type: varchar(255), required: true, index: unique }
        content:      longvarchar
        is_published: { type: boolean, required: true }
        author_id:    { type: integer, required: true, foreignTable:
author, foreignReference: id, OnDelete: cascade }
        created_at:   ~

      author:
        id:           ~
        first_name:   varchar(20)
        last_name:    varchar(20)
        email:        { type: varchar(255), required: true, index: unique }
        active:       boolean

Symfony generates the following BaseArticleForm code:

    [php]
    // in lib/model/form/base/BaseArticleForm.php
    class BaseArticleForm extends BaseFormPropel
    {
      public function setup()
      {
        $this->setWidgets(array(
          'id'           => new sfWidgetFormInputHidden(),
          'title'        => new sfWidgetFormInput(),
          'slug'         => new sfWidgetFormInput(),
          'content'      => new sfWidgetFormTextarea(),
          'is_published' => new sfWidgetFormInputCheckbox(),
          'author_id'    => new sfWidgetFormPropelSelect(array('model'
=> 'Author', 'add_empty' => false)),
          'created_at'   => new sfWidgetFormDateTime(),
        ));

        $this->setValidators(array(
          'id'           => new sfValidatorPropelChoice(array('model'
=> 'Article', 'column' => 'id', 'required' => false)),
          'title'        => new sfValidatorString(array('max_length' => 255)),
          'slug'         => new sfValidatorString(array('max_length' => 255)),
          'content'      => new sfValidatorString(array('required' => false)),
          'is_published' => new sfValidatorBoolean(),
          'author_id'    => new sfValidatorPropelChoice(array('model'
=> 'Author', 'column' => 'id')),
          'created_at'   => new sfValidatorDateTime(array('required' => false)),
        ));

        $this->validatorSchema->setPostValidator(
          new sfValidatorPropelUnique(array('model' => 'Article',
'column' => array('slug')))
        );

        $this->widgetSchema->setNameFormat('article[%s]');

        $this->errorSchema = new sfValidatorErrorSchema($this->validatorSchema);

        parent::setup();
      }

      public function getModelName()
      {
        return 'Article';
      }
    }

If I don't do anything, an admin module based on the `Article` model
will use the ArticleForm in the `edit` view. But what if I need to
customize this form via the `generator.yml`? For instance, if I want
to use a `plain` type for the `id` field, customize the `content`
textarea size, and add a `unique` validator in the `slug` column? I
suggest a YAML syntax looking like this:

    [yml]
    # in apps/myapp/modules/article/config/generator.yml
    generator:
      class:              sfPropelFormAdminGenerator # or whatever its name
      param:
        model_class:      Article
        theme:            default

        edit:
          widgets:
            id:      { type: plain }
            content: { attributes: { size:  20x5 } }
          validators:
            slug:
              type: and
              validators:
                - { type: string, max_length: 255 }
                - { type: propel_unique, model: Article, column: slug }

The contents of the `widgets` and `validators` keys would override the
default definition, not replace it. To remove a widget, use an empty
value for the widget value. Or, we could still use the `display` key
to choose which fields to show, and in which order.

Partial and component fields could be a special type of widget (`{
type: partial, source: article/_foo }`). And the same could apply to
the filter form.

Incidentally, this syntax is the same that I propose for quick form
definition (http://redotheweb.com/2008/09/27/chapter-10-forms/). I
think it makes sense to have a unique syntax for form
definition/customization, with or without the admin generator.

Thoughts?

Cheers,

François

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

Reply via email to