As mentioned on IRC, one possibility for reducing the impact of this would be to have a users setting (either manually selected or have some kind of auto-detection) for using JS. This would let any macros that critically depended on JS (or having their CSS) to change their behavior.
--Noah On Oct 20, 2006, at 1:17 PM, Christopher Lenz wrote: > > Hey all, > > Back when I was involved with porting DrProject (a Trac clone for > academic use) to use the Kid template language, one thing that I > found to be beneficial to reducing general code complexity/volume was > that we moved the generation of wiki output into the templates. I.e. > instead of having the controller prepare the HTML formatted wiki > text, it'd just pass the wiki text itself, and the template would > invoke wiki_to_html() on that where necessary. > > Christian has attempted to do the same for Trac when Genshi was still > on a branch[1], but we found one problem: macros and processors in > wiki text are executed relatively late in the process, i.e. when the > page is already being generated. At that point, it is too late to add > things like style sheets to the <head> of the page, so that for > example the PatchRenderer wasn't able to tell Trac that it needed the > "diff.css" stylesheet to be rendered properly. At that point Trac > would already have rendered the <head> element, so obviously we can't > add anything to it. > > There is no 100% clean way to get around that problem, unfortunately. > But I think I found an approach that's good enough. The approach > requires javascript to load stylesheets after the fact, in particular > the $.loadStyleSheet method I've added to trac.js: > > <http://trac.edgewall.org/browser/trunk/htdocs/js/trac.js#L36> > > A macro/processor such as the PatchRenderer would call add_stylesheet > () as it used to, however, that function would now have a return > value: > > if req.environ.get('trac.chrome.rendering'): > # The template is already being rendered, so return a > javascript > # snippet that can be used to load the stylesheet from the > HTML body > return tag.script(type='text/javascript')( > '$.loadStyleSheet("%s", "%s")' % (link, mimetype) > ) > > And note that it only returns that if that particular stylesheet > wasn't already included in some way. > > In my current implementation, the macro/processor would be > responsible for checking whether the function returned a value, and > inserting that to its output stream in some way. But I'm going to > investigate whether Trac could just put any requried $.loadStyleSheet > () calls in the footer, meaning the return value wouldn't even be > needed, i.e. the implementation of add_stylesheet() might end similar > to the following: > > if req.environ.get('trac.chrome.rendering'): > req.environ['trac.chrome.extrastyles'].append(href) > > ... and the layout.html template would be responsible for pulling in > those "late" style sheets in via $.loadStyleSheet() after the content > has been rendered. > > Anyway, I suspect this whole technique may be somewhat controversial, > due to relying on javascript. However, please note that the reliance > on javascript is only for styling some kinds of content (such as > diffs, or maybe syntax highlighted source code snippets) that may > appear in wiki text. There's no missing functionality or content. The > markup is still as semantic as before, meaning that such content is > still accessible to those who don't have much use of visual styles > anyway (i.e. visually impaired users, text-browser using users, > search engines). And also accessible to anyone, just not as pretty or > colorful. I personally think that's an okay trade-off to make. > > Cheers, > Chris > > [1] http://trac.edgewall.org/attachment/wiki/ChristianBoos/ > wiki2x_in_templates.diff > -- > Christopher Lenz > cmlenz at gmx.de > http://www.cmlenz.net/ > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
