Actually, it looks very nice and very ASP.MVC inspired (this is why it is great !). Dennis sumited the idea of naming the template wich is very great.
The idea of overriding the default template is good, can we also consider override a default template for a specific module ? It is no big deal, but I always like the idea of cascading templating. Veryf nive improvement from sf1 to sf2 :) On 13 sep, 08:23, catchamonkey <[email protected]> wrote: > This looks like a big step forward and I like the way it looks at this > stage. > Good work! > > Chris Sedlmayr (catchamonkey) > > On Sep 13, 4: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
