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):

1. The TWiki topic web.topic if the template name can be parsed into web.topic
2. The TWiki topic web.SkinSkinScriptTemplate for each skin on the skin path
3. The TWiki topic web.ScriptTemplate
4. The TWiki topic TWiki.SkinSkinScriptTemplate for each skin on the skin path
5. The TWiki topic TWiki.ScriptTemplate
6. templates/script.skin.tmpl for each skin on the skin path
7. 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

1. 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"
2. 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