The approach is rather different from that of said other template engine, but the driving principle is the same: bytecode-compilation. The design is much less ambitious, however. We use TAL as the template language and there's no abstraction layer to allow other languages. The upside is that the package is much smaller and the code is easy to read.
In a nutshell:
- Templates are bytecode-compiled
- Only python-expressions are supported
- Depends only on lxml
Internationalization support is still on the to-do, as is a macro implementation. We currently aim at implementing macro-support within a single template only. If you need a macro to be available from several templates, simply define it as a separate template.
6 comments:
Malthe ..... roockkkxxs my Plone world!!
Have you considered going the other way - instead of all-python expressions, have TALES-like syntax but without the (expensive) security (all templates are trusted code) and too much magic (invent a slightly more precise syntax so that you can distinguish between key access and attribute access)?
I think this would be more interesting because it promotes simple, clean templates where display logic is kept in view component (in the MVC sense).
I have considered implementing a TALES-like syntax, but I'm also experimenting with allowing dictionary access using attribute notation.
Although this would introduce a bit of magic, it'd allow for a cleaner syntax.
Cool!
While "JIT" sounds cool, it doesn't look like a JIT any more though than that ZPT's implementation looks like a JIT. I'd avoid using this word if you don't want to get into marketing problems at some point If people go around claiming that this language is JITed someone is going to call them on their claim eventually.
In a JIT compiler, compilation of
individual *parts* (such as functions or methods) of the code happens during executing of that code, informed by what the actual variables that go into this
block of code.
See here: http://en.wikipedia.org/wiki/Just-in-time_compilation
In your code, if I read it correctly, a whole page template is compiled to Python code once during the cook procedure. This is very similar to how ZPT translates its templates to cooked internal ZPT representation. Or to how Kid (predecessor to Genshi) worked.
Generating code on the fly doesn't automatically mean JIT.
Anyway, besides that quibble, it's a cool effort!
Did I say JIT? (rushes to correct the mistake).
As a response to Martins comment, I can announce that as of version 0.2 the package now supports attribute-access to dictionary entries in the expressions.
This removes a lot of verbosity from the expressions in the case that the view is providing data in dictionaries.
Post a Comment