On 08/26/2011 01:10 PM, James Cammarata wrote:
> If you like the Django template language (I do :) ), then jinja2
might
> be an alternative. It was based around the same syntax and extended.
I've been playing with a few, and I really like both mako and jinja2.
The main problem I see with mako is it's damn near impossible to stop
people from importing random python modules. I tried some preprocessor
hooks to strip imports out, but it's messy. Jinja2 is much better, and
you can enable "line syntax" which makes the syntax more cheetah-like:
{% for foo in bar %}
{{ foo }} {# comment that won't show up in the output #}
{% endfor %}
{% include "some_other.tmpl" %}
can become:
#for foo in bar:
{{ foo }} ## comment that won't show up in the output
#endfor
#include "some_other.tmpl"
There is a small issue when you do it this way - it tries to interpret
any line starting with # as a python commands. I've gotten around that
by using #: as the character combo to indicate python lines. So it's
not exactly like cheetah, but it's still very easy to read and write:
#:for i in test:
# comment will show up
variable is {{ i }} ## comment won't be output
#:endfor
#:include 'test2'
The code to render this is very simple:
from jinja2 import Environment, FileSystemLoader
env = Environment(
loader=FileSystemLoader(['/var/lib/cobbler/snippets',]),
line_statement_prefix="#:",
line_comment_prefix="##")
template = env.get_template('test')
print template.render({'test':[1,2,3]})
Note that the FileSystemLoader() class can take multiple directories,
so we could easily add the feature allowing multiple snippet
directories.
So, overall, if I had to pick a templating language today it would be jinja2.
> I was considering (in my less-than-copious free time) hacking the
> templating engine parts to be modular, or attempting to. That would
> allow the testing of different engines.
> Dunno how hard that would turn out to be though.
I don't know if it's worth the effort to modularize this - it's
something we shouldn't be switching out that often. It would make it
easier to switch out if at some point the new language we choose
starts slipping on support the way cheetah has, but how likely is
that?
unlikely, I agree.
The modularization was for me more than anything. I like choice.
I see the cobbler end as a means of defining system (etc) parameters and
passing them to a templating engine.
I'd quite like the templating engine to be up to me :)
Besides, the more modular the better - the same applies to the (already
modularised) backends.
cheetah's rather twisted use of the octothorpe has always irked me a little.
Stuart
_______________________________________________
cobbler-devel mailing list
cobbler-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/cobbler-devel