Last Wednesday we met and he told me that his current codebase is a single file holding all the classes without much documentation or error handling, but he is continuously working on it and once it’s becoming mature enough he will publish his work. He is also still waiting for a more detailed response from Fabien Potencier since we want the new forms system to become a part of the framework and thus Fabien’s opinion is important.

Conceptually, the form is only a collection of fields, but not their presentation. The presentation is handled by the widgets, the formatters and (finally) the template. So any presentation logic belongs there, the form is just the glue to keep all the objects together.

I’ll come back at some more of your points in my next post.

$group_user_stuff = $this->addGroup('user_stuff', 'Personal information');
$group_user_stuff->addField('name')
                 ->setWidgetAttributes(array('max_length' => 15))
                 ->setValidatorOptions(array('max_length' => 15))
                 ->inGroup('user_stuff');

Would be my solution.

You’re right with the grouping, I thought so too. In fact we would even have to go one step further and define some kind of ordering of the fields allowing things like:

$this
  ->addField('name')
  ->inGroup('user_stuff')
  ->before('email');

or

$this
  ->addField('name')
  ->inGroup('user_stuff')
  ->atPosition(2);

As for the separators: one could easily implement this using “dummy” label widgets with a custom formatter. If it becomes widely used in that way, there should be an easy accessor to it, because it will be used anyway but could be more comfortable for the programmer. But seen that way it is a minor issue anyway and not important for now, so perhaps it’s better to leave it out.

It’s quite difficult where to draw the line between form and template. Even the input widgets contain code that could be seen as template related, and it’s the same for the formatters. Perhaps the solution could be to replace the formatters with something like partials, but on the other hand this creates new ties between the form component and the templating framework.

  $this->addGroup('user_stuff', 'Personal information');
  $this->addField('name')
       ->setWidgetAttributes(array('max_length' => 15))
       ->setValidatorOptions(array('max_length' => 15))
       ->inGroup('user_stuff');

Or

  $this->addGroup('user_stuff', 'Personal information', array('name', 'email'));

Both could be supported by the way (even your method could be supported to, but it could be a bit confusing).

For all the other stuff, I’d say +10 to I18N injection, field formatters, submit buttons, +1 to help texts, submit buttons, and required marks, and finally a -1 to separators.
Everything is already a bit messed up in sfForm : we cannot clearly get what is view, what is controller, what is model. And with this we add a little more mess…

Though, there is clearly a flaw about this rendering thing. I’d think more about a template implementation, or a formRenderer with smart markers :

class myFormRenderer
{
  protected $format = '%fields[name]% %separator% %fields[email]% %separator[anotherSeparatorFormat]% %fields[*]%';
}

Well, that’s far from perfect but the information about how fields must be arranged in the view must be in a view, or at least in a “renderer”.