Edgewall Software
Modify

Opened 4 years ago

Last modified 3 years ago

#9683 new enhancement

Make htdocs_location more useful

Reported by: cboos Owned by:
Priority: normal Milestone: next-major-releases
Component: web frontend Version: 0.13dev
Severity: normal Keywords: htdocs_location static chrome
Cc: osimons
Release Notes:
API Changes:

Description

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.

Attachments (1)

htdocs_location_prefix-r10214.patch (6.6 KB) - added by cboos 4 years ago.
web: htdocs_location can now be made more general, by using htdocs_location_prefix.

Download all attachments as: .zip

Change History (6)

Changed 4 years ago by cboos

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

comment:1 follow-up: Changed 4 years ago by osimons

  • Cc osimons added

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.

comment:2 Changed 4 years ago by cboos

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.

comment:3 in reply to: ↑ 1 Changed 4 years ago by cboos

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.

comment:4 Changed 4 years ago by cboos

  • Keywords chrome added
  • Milestone set to next-major-0.1X

comment:5 Changed 3 years ago by 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)?

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as new The ticket will remain with no owner.
as The resolution will be set. Next status will be 'closed'.
The owner will be changed from (none) to anonymous. Next status will be 'assigned'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.