Philosophically I think this is a great solution. I hope the performance issues can be finessed. My understanding is that templates are a lot faster in 2.0...
On Mon, Sep 13, 2010 at 11:11 AM, Fabien Potencier <[email protected]> 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/d2103908cbb5fa32da87c40c7f491dff4f7e67d7/src/Symfony/Component/Form/CheckboxField.php). > > Instead, I have added a FormHelper class that provides a way to render a > form based on templates > (http://github.com/fabpot/symfony/blob/d2103908cbb5fa32da87c40c7f491dff4f7e67d7/src/Symfony/Bundle/FrameworkBundle/Templating/Helper/FormHelper.php). > 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 > -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- 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
