So what do you see as the purpose of a templating engine?
I’d say it’s a method of separating paradigms and abstracting the backend. Some engines enforce this by implementing their own minimal set of directives, others seem to follow the idea of restricting use, yet implement a vast amount of directives. Take Cheetah for example. Others just allow you to drop code in wherever and however you like.
It would be far less complicated to simply allow inline code, but then there is the argument that if developers are allowed to mix up the paradigms, they probably will.
So when it comes to writing your own engine, do you simply allow inline code, implement just a handful of directives or implement a huge set? If you implement just a handful, people may say “well look at engine XYZ, it has 3 times more features”, if you go for straight inline code, people will say it’s insecure and mixes up the paradigms. Yet I look at Cheetah’s list of directives and can’t help but think it’d so much simpler to just allow inline code. Note that Cheetah as more than enough directives to royally screw up the paradigm.
So at this point I’m thinking I’d rather get rid of the templating engine all together. One solution could be XSLT. XSLT has all the conditional and looping goodness you’d ever have needed from a templating engine. With a simple script to convert Python data structures into XML and XPath to access them, you’re all set. XSLT is a damn sight more complex than your average templating engine syntax though, and this would deter many developers who’d never used it before.
So what’s the solution to all of this? I don’t know, though there are 2 methods I prefer.
The first method is just simply allow inline python code, and then try to encourage developers not to mix up the paradigms and restrain themselves to using only the most basic of code in the templates.
Method #2 is to use a series of regular expressions to restrict usage.
However, I don’t believe in restricting what developers can do. There are after all plenty of other places the developer could screw up the paradigms.
I was hoping this post would help me make my mind up and pick a solution, though really I’m non the wiser.
It’d be great to hear peoples thoughts on this.
I tend to agree with the thought that simply allowing inline code tends to be best (i.e. giving developers the freedom to tackle problems no one thought would ever come up). That said, if you’re looking at XSLT – it might be worthwhile to look at some of the “front-end” syntacies (is that really the plural of syntax???). I’ve been working on one (but it’s not very good – namley because it is VERY heavyweight :)). Here’s two I’ve tripped across:
NiceXSL
XSLScript
Just pick one that doesn’t mess up your editor’s syntax highlighting and be done with it.
Love,
Pythonhead
My own thoughts on this are as follows. I have (mostly) implemented my own XHTML construction system. a.k.a “templating system”. It is written in Python. The primary philosophy is the believe that since HTML is a mark-up language, like Postscript is a page description language, the programmer and/or user should never have to see it at all. In my framework you deal purely with Python code. You construct pages in a manner very similiar to GUI toolkits like tkinter or pygtk. That is, you use a variety of add*() methods to add component objects to others. The top level is a Document object. The object library is built directly from the DTD using the dtd2py utility. Actually, this framwork works for building any XML that has a DTD. Therefore, for web pages, only XHTML is supported.
So, for doing conditional or looping things, just use normal Python. The whole thing looks just like a Python program, anyway.
P.S. The framework also does network managment and QA automation.