Small follow up: I've just implemented internationalization for labels and errors in the fields_as_templates branch. The patch is trivial (really just two small changes in the templates -- http://github.com/fabpot/symfony/commit/f68fc2fe5df36dd3782c5d2ddaeadd965ed4826a). To do the same with the current implementation (master branch), it would be more complex, and less flexible.
Fabien On Sep 13, 5:11 pm, Fabien Potencier <fabien.potenc...@symfony- project.com> wrote: > Hi all, > > A few days ago, I've worked on a proof of concept to replace the current > form field rendering (->render() methods in Field classes) by proper > templates. > > If is far from finished yet, but as I let the cat out of the bag in a > few emails and because some people talked about that exact same topic on > the mailing-lists recently (about symfony 1), I have pushed my code in a > branch on Github for evaluation/early feedback from the community: > > http://github.com/fabpot/symfony/tree/fields_as_templates > > The idea is to provide a cleaner/easier way to override the default > rendering of fields (widgets in symfony 1 speak) by developers and web > designers. Instead of hardcoding the HTML in a render() method for each > Field class, the proof-of-concept moves the HTML for fields in > templates. It means that the Field classes have no knowledge of their > HTML representation anymore (see the code for the CheckboxField class > instance:http://github.com/fabpot/symfony/blob/d2103908cbb5fa32da87c40c7f491df...). > > Instead, I have added a FormHelper class that provides a way to render a > form based on templates > (http://github.com/fabpot/symfony/blob/d2103908cbb5fa32da87c40c7f491df...). > From a usage perspective, the code is quite similar to what we already > have: > > Before: > > <form action="#" method="post" enctype="multipart/form-data"> > <?php echo $form->render() ?> > <input type="submit" value="Update" /> > </form> > > After: > > <?php $f = $view->get('form')->create($form, 'table') ?> > <form action="#" method="post" enctype="multipart/form-data"> > <?php echo $f->group() ?> > <input type="submit" value="Update" /> > </form> > > Note: The first line is ugly but this is a quick way to hook everything > together for now and it will probably disappear if the code were to be > integrated into Symfony2 core. > > You also have the flexibility of doing things your way: > > <table> > <?php echo $f->row('gender') ?> > <?php echo $f->row('object') ?> > </table> > > <table> > <?php foreach ($f as $field): ?> > <?php if ($field->isHidden()) continue ?> > <?php echo $f->row($field) ?> > <?php endforeach; ?> > </table> > > <table> > <?php foreach ($f as $field): ?> > <?php if ($field->isHidden()) continue ?> > <tr> > <th><?php echo $f->label($field) ?></th> > <td> > <?php echo $f->error($field) ?> > <?php echo $f->field($field) ?> > </td> > </tr> > <?php endforeach; ?> > </table> > > etc... > > So, what are the main advantages? > > * First, it lets you override the default rendering very easily by just > overriding a template. The default templates for fields are stored in > FrameworkBundle:Form:field/*.php templates. To change a field > representation for a whole project (all input fields for instance), just > create a template in the main views/ directory of your project. To use a > different template for just one field of a form, pass the template name > as an argument: > > echo $f->field($field, array('class' => 'foo'), > 'BlogBundle:Form:InputField') > > * Using templates means you can leverage template layouts, slots, > actions, and the whole templating framework for that matter; > > * You can provide Twig support quite easily (with smarter tags too): > > {% form product_form %} > {% error title %} > {% field title %} > {% endform %} > > * This mechanism (the FormHelper) is orthogonal to the Form framework; > so you can implement your own way of displaying fields very easily if > the default one does not fit your need; > > * Having different rendering based on the doctype (HTML4, XHTML1 and > HTML5) should be easier to implement (I'm not sure of the best way to do > that yet though -- see the current code for some starting points); > > * No more the need to declare Form instances as safe for the output > escaper (as all the template code is done in templates); > > * Much better separation of concerns (MVC wise); > > * Probably many others I don't remember right now ;) > > One downside I see right now is performance as it involves quite a few > templates to be rendered for a given form. But let see if this things is > a good idea or not first as the performance problem can probably be > solved later. > > Feel free to discuss this approach as much as you want in this thread as > I need feedback before working more on the prototype. And if you want to > help me refine the prototype, you are more than welcomed. > > Fabien > > -- > Fabien Potencier > Sensio CEO - symfony lead developer > sensiolabs.com | symfony-project.org | fabien.potencier.org > Tél: +33 1 40 99 80 80 -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com 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
