Well, I used to the way MVC is implemented in the world of Magento. Block:<div><?php</div><div>class MyApp_Some_Block extends Mage_Core_Block_Template{</div><blockquote style="margin:0 0 0 40px;border:none;padding:0px">
<div>public function getSmth(){ </div></blockquote><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>return array('cucumber', 'onion');</div>
</blockquote></blockquote><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>}</div></blockquote><div>}</div><div><br></div><div>Template:</div><div><?php $data = $this->getSmth(); ?></div><div><?php if (count($data)): ?></div>
<blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><?php foreach ($data as $item): ?></div></blockquote><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><blockquote style="margin:0 0 0 40px;border:none;padding:0px">
<div>Item is <?php echo $item; ?></div></blockquote></blockquote><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><?php endforeach; ?></div></blockquote><div><?php endif; ?> </div><div>
<br></div><div>where  MyApp_Some_Block::getSmth() is responsible for escaping the values it provides.</div><div>But OC is completely different as it doesn't use direct inheritance. It's the world of abstract fabrics :)</div>
<div><br></div><div>I'd agree with Frank that there are too much other work to do currently.</div><div><br></div><div>---</div><div>Victor<br></div><br><div class="gmail_quote">On Tue, Oct 9, 2012 at 5:42 PM, Frank Karlitschek <span dir="ltr"><<a href="mailto:frank@owncloud.com" target="_blank">frank@owncloud.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Guys,<br>
<br>
<br>
templating is our smallest problem at the moment.<br>
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 <a href="http://bugs.owncloud.com" target="_blank">bugs.owncloud.com</a><br>

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