Make htdocs_location more useful

[Christian Boos]

At the occasion of the discussion on r10203 and r10204, osimons pointed me at the limitations of the htdocs_location and the fact that it was sometimes pretty useless as such, as it only coped with the core trac resources (those below common/).

You end up having to add rewrite rules in the web server if you want to serve the static resources of the plugins, those exported along with Trac core ones when using trac-admin <env> deploy <dir>.

This got me thinking if we couldn't enhance the htdocs_location internal rewrite mechanism so that it would take care of all the chrome/ resources (except for the site/ and shared/ ones).

By using a new setting, htdocs_location_prefix, we could control the restriction that we currently apply on resources starting with common/. So the default value for that new setting will be common/, but we would also support the empty value for serving everything but site/ and shared/ prefixes, and *, serving everything including site/ and shared/.

Testing here on demo-0.13, seems to work well, but OTOH, there are no plugins ;-) Feedback welcomed.

[Christian Boos]

web: htdocs_location can now be made more general, by using htdocs_location_prefix.

[osimons]

A very interesting approach. Plugin developers know that htdocs_location cannot be used, and stick with making href.chrome('myplugin', 'myfile') links for all needs. As I read the patch, this intercepts these references and maps them to correct location. Nice idea.

However, templates: Much of the template code use the same approach, outside add_<something>() context. That will still point to wrong location I presume, so that all plugins will need to update the call used?

Looking at a random Trac template, the common approach is something like src="${chrome.htdocs_location}python.png". Your approach will also need to redo all of these calls right? Seeing 'common' is not mentioned anywhere. In some of my plugins I also load common resources - like wiki and code formatting css files for rendering blog posts (they are visually very much alike). I'd need to work through the various calls I suppose.

[Christian Boos]

One alternative would be to use a new chrome_location setting, so there would be no ambiguity. Trac would rewrite all its $(htdocs_location)/… in templates to $(chrome_location}/common/… and templates could progressively use that (would also solve the case where they want to refer to their own resources directly in the templates instead of using add_stylesheet/script - those would be aware of chrome_location as well). And then, deprecate htdocs_location.

[Christian Boos]

Replying to osimons:

A very interesting approach. Plugin developers know that htdocs_location cannot be used, and stick with making href.chrome('myplugin', 'myfile') links for all needs. As I read the patch, this intercepts these references and maps them to correct location. Nice idea.

And btw., no the patch doesn't do that. But I could eventually do it, by sticking a call to get_chrome_url in a Href subclass that req.href and req.abs_href would use.

However, templates: Much of the template code use the same approach, outside add_<something>() context. That will still point to wrong location I presume, so that all plugins will need to update the call used?

You mean they also use href.chrome(...), right?

Looking at a random Trac template, the common approach is something like src="${chrome.htdocs_location}python.png".

That example favors leaving htdocs_location alone and introducing chrome_location. Or rather, deprecating htdocs_location in favor of chrome_location. If the latter is set, the former can be deduced.

[anonymous]

I thought at first, that all *.css files included in either htdocs or templates folder are included in Trac sites; but appearently this isn't the case. Thus I programmed a little plugin, which includes all *.css files with a specific pattern.

See Component ​CssTemplate in ​TicketNavPlugin for more details. The source code can be found in ​SVN repo.

Might this be helpful for Trac 0.13 (maybe as sample / optional plugin)?