>From a familiarity standpoint, I know that Django developers would
appreciate this change as Jinja2 is similar to the Django Template Language
and we recently added native support for Jinja2 in Django.
On Thursday, February 4, 2016 at 8:14:52 PM UTC-5, cboos wrote:
>
> 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.
