The current search order for template files won't find per web overrides using the web topic formalism unless all of the default templates are removed, which seems a bit extreme.
For example, I would like to override the view template for a web using the
topic override formalism of web.SkinSkinScriptTemplate (e.g.
Sandbox.PatternSkinViewTemplate
).
According to the standard (non-deprecated) search order specified in
TWikiTemplates and implemented in
TWiki::Templates::_readTemplateFile
, the only way that the topic will be used is if both
templates/view.pattern.tmpl
and
templates/view.tmpl
are non-existent. This implies that I'd have to delete the default templates and implement web specific templates for
all of the webs in order to override the templates for a single web.
I think the order should be like this (cribbing a bit from
TWikiTemplates):
- The TWiki topic web.topic if the template name can be parsed into web.topic
- The TWiki topic web.SkinSkinScriptTemplate for each skin on the skin path
- The TWiki topic web.ScriptTemplate
- The TWiki topic TWiki.SkinSkinScriptTemplate for each skin on the skin path
- The TWiki topic TWiki.ScriptTemplate
- templates/script.skin.tmpl for each skin on the skin path
- templates/script.tmpl
I'm marking this as Urgent, as I think the current behavior pretty much renders the functionality unusable.
DiabJerius
I've attached a patch against
Templates.pm
which implements the above search order and simplifies the search code so that less work is done. Not a big optimization, but it may help a bit.
DiabJerius
Granted that overriding with a topic might seem desireable. However the order is the way it is for two good reasons:
- Compatibility with earlier TWiki releases, in the event that users have a topic named such that it would override a template, the search order has minimum "FUD impact"
- It is far more efficient to look up templates than topics
I do not think we should change this now; it is high risk. Discarding.
CC
With the deprecation of the previous method of per-web overrides, this marks a step
backwards in usability. It's now more difficult to specialize webs, and there is a much larger barrier to the creation of new applications. There's a greater chance that things will break during an upgrade, which is a painful enough process.
DiabJerius