Twig as Template Parser

178 views
Skip to first unread message

Silent Works

unread,
Nov 18, 2012, 8:24:21 PM11/18/12
to silverst...@googlegroups.com
I would like to see the Template Parser implemented as drivers and have a Twig driver for those who are already familiar with this Templating syntax rather than learning a whole new one for SS. Others might want to create templates in Smarty and other Template Parsers, so an implementation as a driver would make it easier to switch between which to use.

Sam Minnée

unread,
Nov 19, 2012, 3:47:45 PM11/19/12
to silverst...@googlegroups.com
At some stage, AJ Short started a patch to the template system to allow for multiple template parsers.  However, I think it conflicted with the parser rewrite that Hamish did and it never got off the ground.  Or perhaps it got to the "80%, looks good, few more things to do" and stopped there.  I can't remember the details, sorry.

AJ (or perhaps Marcus) where did that get to?

In general, support for alternative template engines is unlikely to ever be a core use-case for SilverStripe Framework, and you will wind up losing some of the "free stuff" that using .SS templates provides.  However, as an exercise in reducing coupling, making the template engine less mandatory seems okay.

Hamish Friedlander

unread,
Nov 19, 2012, 4:22:06 PM11/19/12
to silverst...@googlegroups.com
A big issue you'll run into when looking at abstracting the template engine is value injection & type inference / conversion.

SilverStripe templating is tightly coupled to ViewableData, and uses a pull based mechanism where the compiled template asks the current active context for the value in a certain form (XML, etc).

Many other templating libraries expect to be handed all the possible variables up front, rather than access them in a pull based manner. They also handle type conversion differently.

These issues can be overcome - I know of a couple of projects where people have replaced SilverStripe templates with another engine - but the result always ended up a bit frankenstein-ish. I'd be interested in any work anyone did in this area. As Sam said, it'd be good to try and decouple SSViewer from ViewableData.

I think if someone came up with a patch that implemented an elegant way of using multiple template engines we'd definitely consider merging it, as long as it didn't impact on the ease of using the default SilverStripe template engine. We're unlikely to put any development effort into this ourselves though. SilverStripe templates will I'd imagine remain the "preferred" templating engine for the foreseeable future, although if there is a specific feature from another templating language you find lacking in SilverStripe templates, I'd be keen to hear it.

Hamish Friedlander

Uncle Cheese

unread,
Nov 20, 2012, 1:15:17 PM11/20/12
to silverst...@googlegroups.com
I think the reason you don't see a whole lot of support for this is because it's not in the best interest of the framework to just become a hodgepodge of thirdparty products. The differentiator in the SilverStripe framework versus Zend, Symfony, et al, is all of the home-baked goodies you get with it. I happen to think the SS templating language, especially in 3.0, is light years better than Twig, and I see it as a major selling point of the framework. Yes, it's a learning curve, but I think if Twig were a realistic option for SilverStripe, you might as well bolt on Doctrine and/or Propel to bypass the native ORM, and sooner or later the product starts to lose its identity in the noisy, crowded room of PHP frameworks.

Silent Works

unread,
Nov 20, 2012, 1:27:58 PM11/20/12
to silverst...@googlegroups.com
Sorry if my reply comes across a bit blunt, but what a narrow mind of a developer you seem to be, I would like to know why you think Twig was written for Symfony, plus Symfony is component based so not a full on framework and why would you not want to improve the PHP eco-system rather than creating your own all over again. In terms of light years ahead, I am not sure how or even where this applies, I am likely to think you don't have a full understanding of Twig for such an answer. No one is asking for your ORM to be changed, or even your Template Parser to that fact. If the product claims to be a Framework then it should be agnostic of ORM and Template Parser, allowing a developer to bolt on what they like.

Please be more constructive with replies rather than slagging off another product.

Uncle Cheese

unread,
Nov 20, 2012, 10:02:07 PM11/20/12
to silverst...@googlegroups.com
Hi, Silent,

Thanks for your reply. I was just sharing my opinion on the issue, since this topic comes up a lot. I thought I was quite civil and objective, so I'm sorry if it offended you.

Silent Works

unread,
Nov 21, 2012, 4:24:06 AM11/21/12
to silverst...@googlegroups.com
Hi Uncle Cheese,

Everyone has a right to their opinion, but I think as a prominent member of the community you are, I was looking for a more constructive opinion piece. Maybe as you said this has popped up before numerous times, I was not aware of this, I tweeted the suggestion to the Silverstripe handle and I was directed to raise it in here. Yet again, I wasn't meaning to be harsh, would have just preferred a more constructive opinion.

I was not offended, just a bit shocked, as it seems more and more opensource communities seem rather closesource than anything.
Reply all
Reply to author
Forward
0 new messages