My first set of recommendations will be as follows:
1)Make sure user of the framework can’t access widgetSchema or validatorSchema from sfForm.
2)Add methods, that user will call on widgetSchema or validatorSchema, to the form class itself. Examples are setLabel, setLabels, setOption, setOptions, setAttribute, setAttributes etc.
3)May be we should not even have a setPostValidator method. Its syntax is unnecessarily complex. Instead add a method to the form class named postValidate.
4)Add addField method to sfForm which takes the name of the field and returns an sfFormField which can be customized. See example below.

If we create a new class everytime we want to customize a form field, we might end up creating many small classes in our application. This may or may not be a problem depending on the number of classes you will have to create and maintain. However, I see that method chaining is a great idea. I would propose something like this which I have used in other (nonPHP) frameworks:

$this->addField( ‘first_name’ )
->setWidget( new sfWidgetInput() )
->setOption( ‘required’, true )
->setOption( ‘max_length’, 50 )
->setAttribute( ‘columns’, 20 )
->setAttribute( ’style’, ‘background:grey’ )
->addValidator( … )
->addValidator( … );

$this->addField( ‘last_name’ )
->setWidget( new sfWidgetInput() )
->setOptions( array( ‘required’=> false, ‘max_length’ => 20) )
->setAttributes( array( ‘columns’ => 20, ’style’ => ‘background:grey’ ) )
->addValidators( … );

- Indra

this->addField(’name’, new sfFieldString())
->setMaxLength(15);

Since addField returns the new sfFieldString() object you can call methods on it that are specific to its purpose.

Two really simple (and aesthetic) suggestions:

1) Personally I prefer to use “readonly=true” rather than “editable=false”. It just reads better.

2) I find the “final” in setFinalValidator no better than “post”. It still makes me think. Why not realise that what you are saying is that there are two kinds of validators: field validators that are specific to individual fields and form validators that are for the form as a whole? The only reason one needs to have “post” or “final” on the front of this method call is because at the moment all the validators are conceptually stored in the form. With your new sfField objects holding their own validators you can just have a setValidator method on the sfForm class or maybe setFormValidator if you must.

It could look like this:
$this->addField(‘name’, new sfFieldString())
->setOption(‘max_length’, 15)
;

sfFieldString would then parse the generic option and set the appropriate Options for widget and string.

What about yaml form configuration ?

I am not arguing for a 100% coverage of form config via yaml — that’s possibly impossible and definitely a wast of effort.

However, for most forms, I’m pretty sure that the degree of customization is mostly a matter of reconfiguring the order of fields, possibly re-arranging them in groups, etc. All of which is simply a recombination of existing framework constructs: fields, formatters, layouts, widgets, etc. A yaml config file would then be perfectly suitable. More complex form customization could of course still be handled by extending classes, etc.

I would think therefore that allowing form definition via a yaml config file would be beneficial in quite a large number of situations. While this feature is not definitely not a must-have initially, I tend to think that its feasibility would also provide a strong validation of your concepts. If it’s easy enough to configure in the code, then a yaml configuration should really just be a layer above that logic.

But some of it i am all for