Hi Jordi,
On 9/21/10 11:04 PM, Jordi Boggiano wrote:
Heya,
I would like to start a discussion on whether we should adopt Twig as
the *default* Renderer for Symfony2 instead of PHP templates.
Thanks for bringing this up. That's something I've been wanting to
discuss here for a long time, but this is much better when it comes from
the community.
My view of it is this:
- PHP templates are a great default since PHP is obviously always there,
but Twig seems to have become a first class citizen already, so it
wouldn't be too problematic, and it can always be removed if someone
doesn't like it.
The Symfony2 Templating Component has two different purposes:
* Add some features on top of PHP to make it "better" as a templating
engine (template inheritance, slots, ...);
* Provide a common entry point for other templating libraries (so that
you can for instance mix several different templating engine in the same
page -- which is something you want to avoid of course).
Switching to Twig for the default is really a no-brainer from a
technical point of view as it's just a matter of defining 'twig' as the
default templating engine instead of 'php'. But then, I would like to
propose to go one step further if we decide to use Twig as the default:
removing the usage of the Templating Component altogether. It will not
bring enough value to justify the overhead. And as a side effect, the
Output Escaper Component won't be needed anymore (and man, just because
of this, I would like to use Twig). Speaking of output escaping, one
nice benefit (which is rather counter-intuitive at first) is that Twig
templates are faster than PHP ones (because of the overhead of the
output escaping).
Another thing to keep in mind is that I think Twig is much better as a
templating system for the admin generator. So, even if we don't use Twig
as the default templating engine, I think we will still use Twig for the
admin generator.
- In my experience PHP templates encourage not-so-MVC-conscious
developers to put too much logic in their views, because it's very easy
to do so. Twig provides a context switch that help people make a
distinction, and also makes it harder/impossible to code complex logic
in templates.
Amen.
- Twig with the custom tokens provides much more fluent and clean
interfaces to the template helpers, not to mention shorter. e.g.:
{% route 'blog_post' with ['id': post.id] %}
<?php echo $view['router']->generate('blog_post', array('id' =>
$post->id)) ?>
And as you can create tags and filters pretty easily (I still need to
make it even simpler), you can tweak/choose the syntax you think is
better (you are free to create the DSL you want). If we go down this
route, we should probably write a best practice guide to ensure a
coherent experience for the end-user.
- The Twig syntax with dots to access properties and all looks and feels
like javascript, which imo is great for frontend developers to be sort
of in the same environment no matter if they work in templates or in js
code.
The dot syntax also abstract properties/methods calls.
- On the downside, I guess Twig has a bit of a learning curve, but then
again people must learn the symfony "keywords" anyways, like
$view['router'], that aren't especially obvious to a non-sf developer.
So it's not like PHP templates are completely straightforward, and Twig
syntax is quite simple and well documented.
I think this is quite the opposite. Sure, for a developer, Twig is
something new. But for web designers, I think they can learn Twig must
faster than PHP (HTML designers at Sensio now use Twig instead of PHP
and they love it).
Fabien
Thoughts?
Cheers
--
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 symfony-devs@googlegroups.com
To unsubscribe from this group, send email to
symfony-devs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en
