Hello,
Inspired by some recent discussion seen on Trac-Users ("Genshi
question"), I decided to revisit this old topic and the last 2 weeks I
tried to get a feel of what it would take to migrate our template engine
from Genshi to Jinja2.
The results are very encouraging, as we can expect a 5x to 10x speedup.
I posted some numbers there:
http://trac.edgewall.org/wiki/TracDev/Proposals/Jinja
But the gain in speed and memory usage is only one thing (though a major
one), other aspects are important as well, like the ease of developing
the templates, the support for all the features we got used to (i18n in
particular). Without getting yet in the details, my initial experience
also makes me very optimistic for these points.
I've pushed the current rough state of my experiment in the jinja2
branch on t.e.o. It's nowhere near finished, but I hope it's in a state
which can be interesting for others to play with or simply look at, to
make up their mind.
I started by migrating an "easy" template, the search page, then
followed with the report view (#11185 in mind) and then with the browser
and the changeset views. Oh yes, I actually started with Kajiki, not
Jinja2, While the speed of the former was more than adequate (seems to
beat Jinja2 by a narrow margin), it's nowhere near as mature as Jinja2
is, and the error reporting is very lacking. This, plus other glitches
(see the commit messages for 7acf61b and 7d4b6f8), and the fact that
despite the surface similarity with Genshi you needed to adopt the
Jinja2 approach anyway (extends and blocks), meant that it was worth
going with the real thing.
And I actually like going away from an all-XML template markup, the
templates are much more readable this way, I think, at least with the
Jinja2 notation I picked: use line statements for the most part and
block statements only exceptionally. I also kept the familiar ${}
notation for the embedded expressions.
To somewhat compensate for the loss of the well-formedness guarantee
that Genshi provided for the template and the generated content, I
developed a little tool (contrib/jinjachecker.py) that will separate the
Jinja2 markup from the HTML content, and verify both separately (proper
nesting for the Jinja2 control structures, validation of the HTML using
lxml).
As for the next steps, besides starting to get feedback, document the
migration process and advocate that move, I'll continue with a few more
modules to be sure that all the remaining aspects get covered (the form
token handling, the late scripts and such little details). Ideally, I
hope that this could be the big thing for 1.3dev with in sight an
all-Jinja2 Trac 1.4 ;-)
Feedback welcomed!
-- Christian
--
You received this message because you are subscribed to the Google Groups "Trac
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to trac-dev+unsubscr...@googlegroups.com.
To post to this group, send email to trac-dev@googlegroups.com.
Visit this group at https://groups.google.com/group/trac-dev.
For more options, visit https://groups.google.com/d/optout.
