On 9/13/10 5:16 PM, Tom Boutell wrote:
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...
I have not done any serious benchmark. It is just a feeling I have. And
yes, templates are much faster in Symfony2.
Fabien
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
--
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
