Forums / Cotonti / Development / Twig: modern template language

Recently I stumbled upon a project called Twig. It's a template engine for PHP. It's recently become part of the Symfony PHP framework.

Looking at the features and documentation I'd say this would make a pretty good replacement for our old XTemplate system. The documentation is very good. It's possible to customize the syntax, so we can keep the XTemplate syntax for backwards compatibility with existing skins.

I'm aware that the XTemplate system is very much tied in with the Cotonti core, to such extent that it will require modifying pretty much every core file. In my opinion though, its features would be a big improvement to the possibilities that we have in customization of templates. At the very least its worth taking a good look at.

I can name a few reasons why we should not move to Twig:

1. Twig is view-driven. XTemplate is controller-driven. Twig blocks are absolutely different things rather than XTemplate blocks. Twig blocks are hierarchic structure elements. XTemplate blocks are parsing logic elements as well, still driven by controller - which is pretty unique to XTemplate, despite the fact that it is still push-based like most MVC template engines. This means that you cannot replace XTemplate with Twig without rewriting the controller logic completely.
2. XTemplate2 was built in KISS spirit, just less than 500 lines of code which do the job. But a hundred classes in 250kB of code means no simplicity of this kind.
3. Do we really need that complexity in TPL files?

For me point 1 is the showstopper, the rest 2 are more or less acceptable in some circumstances. In addition, compiled templates don't always mean speed, in case speed claims make you choose Twig.

Modulo operator is not a problem, a 2 minute deal

Nested logic blocks is a bit of a problem. The difference between blocks (BEGIN...END) and logic blocks (IF...ELSE..ENDIF) is not just the condition on which they are parsed.

XTemplate2 renders templates from TPL into HTML in 2 runs. On the 1st run it analyzes TPL structure and parses TPL file into serialized PHP objects (stored in datas/cache/templates), so it doesn't need to parse the template on following runs. On the 2nd run it pushes the block tree (unserialized PHP objects) with real-time data into the actual HTML output.

Traditional blocks are structurally parsed on the 1st run and are represented as Xtpl_block objects, because they are pushed by the controller at a run-time. Logical blocks are pulled at run-time by run-time variables, that's why they are not represented in the tree structure generated on 1st run.

If I manage to find a way of parsing them into Xtpl_logic_block objects at "compile-time", then nested blocks within logic will be possible. Then I'd need an expression "compiler" as well. Because logic blocks is the slowest thing in XTemplate2 currently.

Another reason why I was against nested blocks is complexity. Imagine templates full of nested IFs, up to 3 or 5 levels of nesting. Mixed with traditional blocks. Or no traditional blocks at all (in this case it'd be just usual Smarty stuff). If we have nested logic blocks, then the responsibility of keeping the templates neat lies completely on markup coders.

Extensions is quite easy to implement. It actually exists in original XTemplate. I did not implement it for 2.0 because nobody really used this feature till then.

I think these features have been requested quite often for now, so I'll open tickets to implement them all.

I've got some ideas about nested blocks, will implement it soon and make our compiling XTemplate more compiling. BTW, I think we should rename our XTemplate to CoTemplate because it is not very fair and correct to the original XTemplate.

Twig's extensions are also know as callbacks or pipes or processors. A construct like {MY_VAR|strtoupper|htmlspecialchars} gives a hint what they are.

Yep, CTemplate is a registered trademark by Google That's why I said CoTemplate. Yes, I'm aware of what the guys in he XTemplate did 2 years ago.

eval() is a kind of evil() not just for security but also for speed. But for the new version of CoTemplate I'm implementing an expression compiler, it should solve the problem of more complex expressions and their speed.

Well, modulo operator is something that is available in pretty much every template language, and its not hard to see why. Modulo is just much more flexible than assigning a tag named ODDEVEN, because you are not limited to odd/even. What if you want to have 3 different colors alternating in your table rows instead of two? Also, I've noticed that the ODDEVEN tag isn't always available.

I can agree to the CONTAINS/HAS argument; they probably wont be used as much. Main usage would be to see if a user is member of a usergroup:

<!-- IF {PHP.subgroups} HAS 'moderators' -->
You are a member of the 'moderators' user group.
<!-- ENDIF -->

As to performance, it won't matter much, since the code is only executed when actually used. If the other devs want them taken out I can live with that, I say its their call.

I hope you guys have noticed changes in r1318 and 1319. Now you've got the only hybrid structure/logical block template engine in the world.