Yes, phtml is pure HTML with PHP alternative syntax: http://php.net/manual/en/control-structures.alternative-syntax.php
--- Victor On Tue, Oct 9, 2012 at 5:26 PM, Bernhard Posselt <nukeawh...@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 <nukeawh...@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@kde.org > >> https://mail.kde.org/mailman/listinfo/owncloud > >> > >
_______________________________________________ Owncloud mailing list Owncloud@kde.org https://mail.kde.org/mailman/listinfo/owncloud
