[Owncloud] Problems with the current template engine

Tue Oct 9 14:55:49 UTC 2012

Well, I used to the way MVC is implemented in the world of Magento. Block:
<?php
class MyApp_Some_Block extends Mage_Core_Block_Template{

public function getSmth(){

return array('cucumber', 'onion');

}

}

Template:
<?php $data = $this->getSmth(); ?>
<?php if (count($data)): ?>

<?php foreach ($data as $item): ?>

Item is <?php echo $item; ?>

<?php endforeach; ?>

<?php endif; ?>

where  MyApp_Some_Block::getSmth() is responsible for escaping the values
it provides.
But OC is completely different as it doesn't use direct inheritance. It's
the world of abstract fabrics :)

I'd agree with Frank that there are too much other work to do currently.

---
Victor

On Tue, Oct 9, 2012 at 5:42 PM, Frank Karlitschek <frank at owncloud.com>wrote:

> 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/owncloud/attachments/20121009/f33d0256/attachment.html>