[Owncloud] Problems with the current template engine

Frank Karlitschek frank at owncloud.com
Tue Oct 9 14:42:54 UTC 2012


Guys,


templating is our smallest problem at the moment.
Out current templating is not fancy but works fine. I´m against replacing it with something that generates a huge amount of new work and introduced new bugs and performance problems instead of working on topics that are important for our users like bugs and feature requests on bugs.owncloud.com


Frank


On 09.10.2012, at 16:26, Bernhard Posselt <nukeawhale at gmail.com> wrote:

> Hi Viktor,
> 
> Yeah, HAML is great :)
> 
> Could you provide a link to your templating engine, I dont find any
> information on that on Google. Or do you mean PHP in general (phtml as
> in the extension)?
> 
> 
> On 10/09/2012 04:20 PM, Victor Dubiniuk wrote:
>> Hi Bernhard,
>> 
>> I have a long experience with Smarty and tried a couple of other template
>> engines. Most of them is nothing but PHP written in PHP.
>> There are some brilliant exclusions like Slim and Haml in Ruby but both are
>> not implemented in PHP completely.
>> I consider phtml to be the best option for templates.  One can say it is
>> weird for designers but any other non-HTML syntax is weird for designers
>> either.
>> It's just my humble opinion.  :)
>> 
>> ---
>> Victor
>> 
>> On Tue, Oct 9, 2012 at 5:06 PM, Bernhard Posselt <nukeawhale at gmail.com>wrote:
>> 
>>> Hi guys,
>>> 
>>> I've ran into multiple problems with the current template engine setup.
>>> 
>>> * Lack of documenation:
>>> Since these are only used by Owncloud, we have to maintain the
>>> documentation on the template engine. Using a third party engine would
>>> simplify documentation since we only would have to document how this is
>>> built into Owncloud. Not to mention that there isnt actually any
>>> documentation about the current templating engine at all from what Ive
>>> found (http://api.owncloud.org/classes/OCP.Template.html)
>>> 
>>> * Lack of template inheritance:
>>> Currently we can only organize templates by splitting them into
>>> different parts and including them in a Top-Down like fashion. Template
>>> inheritance solves this kinds of problems (an example:
>>> 
>>> https://docs.djangoproject.com/en/dev/topics/templates/#template-inheritance
>>> )
>>> 
>>> * Weird and unsafe XSS escaping:
>>> Most important topic for me. We currently escape values when they're
>>> assigned to a template like $tpl->assign('var', $var). If you dont want
>>> to invoke the XSS protection on the variable, you use
>>> $tpl->assign('var', $var, false) which is really weird and non obvious.
>>> Also: What do we escape? IIRC variables and arrays, but what about
>>> objects? We at the news app pass an array with objects to the template
>>> layer. Are the properties escaped? If they are, this could lead to
>>> potential weird behaviour, not to speak of the performance impact
>>> (reflection). As you see, theres no sane way to do XSS escaping when
>>> passing values to the template layer.
>>> 
>>> The solution? Easy: escape the values when they are printed to the
>>> template. Most template engines forbid you to use PHP in the templates
>>> (which is a good decision) and provide their own print statements like
>>> Django's {{ variable }} or Rail's <%= variable %>. All printed values
>>> are automatically escaped by default! If you want to prevent escaping
>>> you just use a filter like {{ var|safe }}. The word safe alone gets me
>>> thinking: why is it called safe? What are the risks?
>>> 
>>> * Allowing PHP code in templates:
>>> This is not only a security problem stated by the previous point, but
>>> also an invitation to code mess. Allowing PHP code in the template
>>> tempts people to disregard the MVC principles (like for instance doing
>>> database queries in the templates, we have that problem too, I admit),
>>> which makes your templates really inflexible and really hard to change.
>>> Everytime I try to clean up our templates or adjust them, I give up in
>>> frustration because I'd have to adjust all templates, some of which are
>>> generated in a recursive way and thus also very complicated to understand.
>>> 
>>> Coming from Django I've looked at two similar engines:
>>> 
>>> http://www.h2o-template.org/
>>> http://twig.sensiolabs.org/
>>> 
>>> Both have good documentation, Twig doesnt do autoescaping but theres a
>>> block for that. I'm curious about other suggestions, and it would also
>>> be fine if they could be reviewed from a security context.
>>> 
>>> PS: Sorry for the long post, here's a potato
>>> http://efr0702.files.wordpress.com/2012/03/potato-b.jpg
>>> 
>>> Cheers
>>> 
>>> Bernhard Posselt
>>> 
>>> _______________________________________________
>>> Owncloud mailing list
>>> Owncloud at kde.org
>>> https://mail.kde.org/mailman/listinfo/owncloud
>>> 
> 
> _______________________________________________
> Owncloud mailing list
> Owncloud at kde.org
> https://mail.kde.org/mailman/listinfo/owncloud





More information about the Owncloud mailing list