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
