I smell a PHP-to-Twig cross-compiler coming... :)

Sent from my iPhone4

On Nov 19, 2010, at 12:52 PM, Johannes <[email protected]> wrote:

> What if we only allow a subset of PHP to be used in templates; on par
> in functionality with what can be used in Twig, and only provide a
> compiler for that? The tokenizer is provided by PHP, and once we built
> an AST, we might be able to re-use the code from Twig.
> 
> This way we would get all the benefits of Twig plus developers would
> not have to learn a new templating language. It would also allow us to
> make calls to helpers via functions thus no change from what we did in
> symfony 1.x without sacrificing any functionality.
> 
> The only disadvantage I see is that you do not have the full arsenal
> of PHP at your disposal, but then again in templates you probably
> should only use a small subset.
> 
> Your thoughts?
> 
> On 18 Nov., 23:08, Fabien Potencier <fabien.potenc...@symfony-
> project.com> wrote:
>> Summary
>> -------
>> 
>> The output escaping component for PHP templates does not work very well
>> and I think it cannot be "fixed". So, I want to remove its support in
>> Symfony2 entirely. This means that we won't have automatic output
>> escaping if you use the PHP templating engine in Symfony2.
>> 
>> I think that makes sense because we have decided to use Twig as the
>> default templating system (and Twig supports a much more robust
>> implementation of automatic output escaping -- still not finished yet
>> though.)
>> 
>> Rationale
>> ---------
>> 
>> If we support a feature in Symfony2, it should work as advertised,
>> especially when we talk about security. But the truth is that automatic
>> output escaping does not work very well.
>> 
>> I've been fighting with the output escaper and its integration in the
>> PHP templating system for months now and I'm still not satisfied with
>> its current state; and I don't see how we can fix all the issues.
>> 
>> I won't list all the problems I've encountered, but just three of them
>> to illustrate the discussion.
>> 
>> The first problem is that it's quite impossible to garantuee that
>> everything will be escaped. For instance, static method calls cannot be
>> escaped (we can argue that this is not a good practice but we cannot
>> force people not to use them.)
>> 
>> Then, some weeks ago, I fixed double-escaping problems. I then fixed
>> some bugs, and now, the current implementation is better as it escapes
>> "more" but now... but it escapes too much. For instance, if you pass a
>> safe variable by wrapping it with a SafeDecorator object, all method
>> calls on it should be considered safe. But if you pass the result of a
>> method call to another template from a template, it will be escaped,
>> which is not expected:
>> 
>> // in a controller
>> $var = new SafeDecorator($object);
>> 
>> // in the template
>> $view->render('...', array('var' => $var->getFoo());
>> 
>> The 'var' variable in the render() call should not be escaped but it
>> will be as the escaper removes the SafeDecorator when passing $var to
>> the template.
>> 
>> Last but not the least, the fact that we need to wrap all variables has
>> also a lot of drawbacks. Main ones are:
>> 
>> * It's slow;
>> * The wrapped objects do not act as the original objects (many native
>> PHP functions for instance work for arrays but not for ArrayAccess objects;)
>> * People expect object from a given type but what they have is different
>> (it means that sometimes you cannot use type hinting;)
>> 
>> Cheers,
>> Fabien
>> 
>> --
>> Fabien Potencier
>> Sensio CEO - symfony lead developer
>> sensiolabs.com | symfony-project.org | fabien.potencier.org
>> Tél:+33 1 40 99 80 80begin_of_the_skype_highlighting              +33 1 40 
>> 99 80 80      end_of_the_skype_highlighting
> 
> -- 
> 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

Reply via email to