> -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Remy Blank > Sent: Wednesday, April 07, 2010 3:35 PM > To: [email protected] > Subject: Re: Towards Jinja2 (was Re: [Trac-dev] Which genshi version > for Trac 0.12?) > > Whoa, activity on trac-dev! :) > > > I agree that adoption of Jinja2 should be considered, it's become a > > very solid templating solution, and comes with both more momentum and > > better performance than Genshi. > > It's already a good sign that nobody has anything *bad* to say about > Jinja2. Still, is this the only reasonable alternative? Are there other > contenders out there, and what are the pros and cons of each solution? > > I'm not trying to work against Jinja2, just to keep the view broad > before making a choice. > > > But I'm not sure how a gradual transition could work. > > (snip) > > > If there's going to be another template engine switch, I think it's > > going to hurt. But it might just be worth it. > > I'm a bit wary of how this could work out. Let's say (for the sake of > argument) that we switch to Jinja for 0.13. This is a large internal > change, but mostly invisible to end-users (except for better speed, > which may or may not have a significant impact). Besides, we either > break most of the existing plugins (if we don't transition gradually) > or increase the work significantly (if we transition gradually). > > So, we get a new release where: > > - a big chunk of work is barely visible to end-users > - plugins stop working for no (user-understandable) reason > - themes and style customizations stop working
I'm biased given how much work I've put in on ThemeEngine, but I think this is the kind of thing that we should try to ask users what they want. It seems like uptake on ThemeEngine (and other large-scale changes to the trac UI) is near zero, so even though it kills me a little inside maybe this isn't a big feature to lose. CSS-only changes to the UI (and the big system in ThemeEngine for generating them) would still work as-is. The same goes for streamfilter plugins. What plugins out there are making good use of this? I know TagsPlugin relies on a stream filter for injecting the tag display into wiki pages. Also, could make something like stream filters (not talking about API compat, just functional similarity) the same way 0.10 injected XSRF tokens (render the full page and then parse it out again)? Maybe that will still be enough of a performance win to justify the added slowdown? --Noah -- You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
