> -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Thomas Moschny > Sent: Wednesday, April 14, 2010 7:33 AM > To: [email protected] > Subject: Re: Towards Jinja2 (was Re: [Trac-dev] Which genshi version > for Trac 0.12?) > > 2010/4/14 Christian Boos <[email protected]>: > > [ ... ] but those trying for example to modify each row of a > > rendered source file will no longer work [ ... ] > > Yet something like this is most interesting e.g. for a plugin > implementing a VCS backend/UI with needs to tweak the source and > changelog browsers. > > >> However, depending on Trac > >> development for available hooks would be a big step backward, > > > > Not sure; as I've pointed out earlier and others have noticed as > well, not > > having explicit hooks is also quite fragile. Suddenly, after a > seemingly > > innocent change in the template, the xpath selectors of some plugin > stop > > working... > > Yes, but I can fix that in my plugin and release a new version of it > within a very short time frame, whereas getting a new hook or slot (or > whatever technique will be used) into main Trac will take at least the > time until a new release is made, if not longer, or forever if I > cannot convince you of its usefulness. > > In the end this is may be a reasonable trade-off anyway: having an > actively maintained template engine with decent performance, vs making > life harder for some plugin developers.
There is also more than one way to offer this kind of system. I suppose the most basic version would be to have a post-render callback that gets the full text of output and can run regexes. Thats probably yet more fragile, but it offers the same kind of crazy. --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.
