cotonti.com : Twig: modern template language

Trustmaster

Ср, 15 Вер 2010 02:09:32 -0000

Make sure you have global $cfg['xtpl_cache'] = true and the appropriate cache folder. Without this, Co/Xtemplate performance can be really poor.

GHengeveld

Ср, 15 Вер 2010 01:38:04 -0000

Well, as long as the client isn't requesting any more weirdness (having a meeting with him tonight), all will be fine. I'm likely going to implement an html caching mechanism to make it all even faster (this particular project doesn't use Cotonti, just the XTemplate class from Cotonti).

Trustmaster

Пн, 13 Вер 2010 21:12:56 -0000

I did benchmarks on sed-light/genoa and nemesis/trunk, apart from the particular feature tests. But it has been recently reported that at some tpls it fails to render correctly. Tpl files to test on would be appreciated for fixing bugs.

BTW, I still do not recommend using too much of IF logics where traditional blocks can be used. Blocks are better structured and controlled from PHP code, they are still faster than conditionals too. For people who want IF blocks alone, I'd recommend using PHP as template engine itself.

GHengeveld

Пн, 13 Вер 2010 16:14:04 -0000

Did you do any performance testing? I've got one site running so many conditional blocks that I'm running against the limit. If I include one more IF block it just stops working.
FYI I'm using a TagFactory class which loops over a multidimensional array and assigns tags and parses blocks. That's why there's so many.

Trustmaster

Сб, 11 Вер 2010 04:27:52 -0000

Well, you don't have to rebuild anything and it acts pretty same way as before except for a few things:

You can put logical IF/ELSE/ENDIF blocks inside of other logical blocks. And normal BEGIN/END blocks inside of logical blocks. And combine them how you want.
You can pass template variables through PHP functions using callbacks a.k.a. extensions or pipes. Just like this: {FORUMS_TOPIC_TITLE|str_replace('Twig', 'FooBar', $this)|stripslashes}.

Other details are more technical, like a better template compiler which eliminates any parsing at render-time. I think nobody here truly realizes what he'd need nested logical/begin-end blocks for. I just made a different architecture which makes it possible.

ez

Сб, 11 Вер 2010 01:46:19 -0000

This all looks very promising... (and Cotonti has the first hybrid !!!!)

I hope there will be some good documentation about all new/all features.
I want to know everything

thnx T, and the rest for all these good ideas

urlkiller

Сб, 11 Вер 2010 01:44:40 -0000

so if i understand this correct that cotemplate thing will give us more blocks in the existing templates or does it mean that we have to rebuild all templates/plugins that uses tpls (more or less) ?

Trustmaster

Сб, 11 Вер 2010 00:29:07 -0000

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.

Kort

Вт, 07 Вер 2010 18:27:56 -0000

ODDEVEN is available throughout the basic package and in properly made plugins. Adding it is a matter of 1 min. Alternating row colors is about BEGIN/END blocks which is, again, plugins. Having 3 or more row colors in a table is the last thing that'll come to any mind. Maybe there are more nice things that can be done with it, otherwise adding such stuff is nonsense and waste of time.
CONTAINS/HAS makes much more sense to me.

GHengeveld

Вт, 07 Вер 2010 16:33:03 -0000

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:


You are a member of the 'moderators' user group.

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.

Kort

Вт, 07 Вер 2010 15:18:10 -0000

In my opinion this is another extremity. Right now the balance between templates and plugins is ok. What cannot be done in tpl can be done in php and both capabilities are sufficient.
I do not see any reason why I should determine odd/even using the modulo with sed_build_oddeven. CONTAINS/HAS is also somewhat redundant and it seems like it is not needed at all. And I also do not think that adding stuff like nested operators improves overall performance and makes Cotonti more agile.
To me it looks like what happened to the forums: somebody just needed some features for some reason, brought them in and left it like that: ugly and inefficient.
Right now we've done one good thing: made Cotonti templates feature-rich to the extent that keeps it user-friendly. Although there are still a lot of questions regarding the use of IF/ELSE/ENDIF, these are mainly caused by the lack of documentation. But if you keep moving like this, the templates would get overloaded with the stuff that is normally pluginmaker's domain. So keep the balance please and do not rock the boat.

Trustmaster

Нд, 05 Вер 2010 01:54:27 -0000

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.

GHengeveld

Сб, 04 Вер 2010 20:53:37 -0000

Great, it looks like I started something here, which was my intention entirely

I noticed the Trac tickets. I'll take a look at the modulo operator. If I get it to work I'll backport it to the Genoa branch as well.

The piping system that Twig uses should be fairly simple to implement, but we'd have to make a decision as to what functions to implement.

I'd prefer the name CTemplate, but that is also the name of a Template language for C. By the way, are you keeping an eye on the improvements/updates done by the XTemplate team? (Although their latest commit was almost 2 years ago)

Added 1 hour 8 minutes later:

I'm looking into the modulo operater, but it's not exactly a 2 minute deal. The difficulty lies in having XTemplate look for an operator twice, since we want to be able to do this:

(1,4,7,10,13 etc)

Added 2 hours 12 minutes later:

After fiddling around with this all day I've finally got it. It turned out to be easier than I though.

This did it:

case '%': eval("\$res = $val % $val2;"); break;

Along with adding the % sign to the preg_match list.

It's not so nice because it uses eval() which is potentially unsafe. I'll add a check so only integers are allowed.

Added 32 minutes later:

Okay, I've committed the changes to trunk and I've backported them to the Genoa branch as well. See changeset 1315.

Templates will now support the modulo operator (% sign) like the example above. A simple odd/even check can be written like this: (note the spaces)

evenodd

A while ago, I added two other operators as well, namely CONTAINS and HAS. These are now backported to the Genoa branch as well. CONTAINS will check if one string is contained in the other. HAS will check if an array has a certain value. They can be used like this:

Username contains 'Kora'
The array has this value

Trustmaster

Сб, 04 Вер 2010 17:07:06 -0000

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.

ez

Сб, 04 Вер 2010 16:11:30 -0000

The IF Else statement is used more frequently (by me anyway)... and other programmers will pick it up soon i think. i love Xtemplate.

For the nested IF.. maybe we could use an identifier or some sort.. (label like) ???
So label functional blocks a bit different ?

What are these extensions ???? I would love to know..

greetings from sunny Italy

Trustmaster

Сб, 04 Вер 2010 13:54:29 -0000

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.

GHengeveld

Сб, 04 Вер 2010 08:08:33 -0000

I completely understand not going with Twig. Actually I have to say I wouldn't do it myself either, because it will simply be much more work to build this in, instead of improving on what we already have. I was merely trying to start a discussion.

One thing that I would like to see in XTemplate is support for the modulo operator (usable for odd/even for example) and the option to use regular blocks (BEGIN...END) within IF/ELSE blocks (nesting). Also having an ELSE for BEGIN...END blocks would be nice (parsed when there are no items in the loop, for messages like "No records found"). There's some more interesting things listed here (see Built-in Extensions).

Actually I could probably build this in myself, but I'd like to get some approval before I go there.

Kort

Сб, 04 Вер 2010 07:10:02 -0000

IF-logic is where Cotonti really shines. Conditions in templates remove plugin requirements and overall complexity in around 90% cases. I do not understand how commercial and free websites differ in xTemplate usage, but with Cotonti I handle most tasks using it leaving very few things to plugins. Normally you should avoid plugins as much as you can, and this is only possible with xTemplate. So if you do simple stuff or prefer plugins, it doesn't mean anything.

urlkiller

Сб, 04 Вер 2010 04:29:04 -0000

as far as i see it really less ppl use the ctemplate completly... if and else etc. all that features are barely used... commercial version i cant tell but the free versions here dont use all that nicey dicey stuff.

Trustmaster

Сб, 04 Вер 2010 04:20:59 -0000

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

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.
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.
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.

urlkiller

Сб, 04 Вер 2010 03:35:32 -0000

looks nice but i would make that on the bottom of every todo-list you devs have...

if the xtemplate skins would be 100% compatible iam in helping out with that...

GHengeveld

Сб, 04 Вер 2010 03:08:49 -0000

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.