In TWikiTemplates, several load paths are marked as deprecated (those in templates/web.

While I have no problems with removing those load paths, without in addition changing the order of load paths it will not be possible to selectively change templates on a per web basis. The note in the doco says to "store web-specific templates in TWiki topics". However, twiki topics are loaded after templates, so you cannot just put, say, PatternSkinViewtoolbarTemplate.txt into your web and hope that it overrides viewtoolbar.pattern.tmpl. It won't.

The suggestion to deprecate is a good one, but it needs to be accompanied by putting the templates directory last. Of course, that means checking a lot of directories while most templates will be in templates anyway. However, now we seem to be checking these directories already (why is this done, by the way?).

Marked as Requirement, as a curently available feature is being removed.

---

I don't understand your point here. You are not losing anything moving to a flat directory.

For example, let's say I have a web, WebA, where I want to override the edit template. I create an edit.weba.tmpl in the templates directory. Then in WebA.WebPreferences, I write:

• Set COVER = weba

or

• Set SKIN = weba,pattern

End of story. Or am I missing something?

CC

Originally, I would not have to do anything in a web to get a web specific template. Requirinng that one now sets either cover or skin is a change in spec.

To be more consistent, we could search

• <templatename>.<webname>.tmpl
• <templatename>.<webname>.<skinname>.tmpl

also.

Or we could make the whole thing much simpler and get rid of many of the possible paths and just have two locations, in tmpl and in data/. But I don't see why we should remove the capability of naming a template so that automagically it is used, without having to set a cover or skin, if we keep all the other search paths.

However, I am find with radically simplifying the template search path and moving most onto the cover/skin/VIEW_TEMPLATE settings.

-- TW

I would think there could be a small performance gain in only searching very few places. Ie. the simple search approach. Searching for the existance of a possible template topic much cost some file system type CPU cycles.

There is in principle a small compatibility problem. But as I understand - the corrective action for an upgrader from Cairo to 4.1 would be adding a setting in the WebPreferences. We are not trashing a million topics and many plugins because of such a simplification. And if we can improve performance from not searching for settings everywhere (like we have also started working on for Plugins) then it is worth such a small "price".

-- KJL

I just realize that this discussion has a Codev topic which needs to convert towards a conclusion.

TWiki:Codev.TemplatePathIsCounterintuitive which is also listed on TWiki:Codev.WhatIsIn04x01

-- KJL

Simplification in plugins search? CC just added a feature to configure to search every directory on @INC for plugins! It seems to me we are expanding where we are picking up plugins, not simplifying that... -- TW

---

Discussion moved to TWiki:Codev.TemplatePathIsCounterintuitive.

Other related discusssions in TWiki:Codev.TooManyTemplateLocations, TWiki:Codev.SkinSearchPath, TWiki:Codev.PatternSkinDoesNotSupportTemplateLoadingOrder, TWiki:Codev.ReadTemplatesFromUserTopics

---

Changed the name of the topic from "Deprecation of template load path is mistaken" as the discussion seems to have migrated to making the load path configurable. Not a "requirement" any longer...

-- TW

---

Discovered that there are two test cases that are failing in the existing implementation of the search path (one where the test case is purposefully incorrect to mask the error, and one where the test case is just incorrect).

---

Implemented configurable search path per the discussion in TWiki:Codev.TemplatePathIsCounterintuitive. Also fixes the two errors above. Waiting for feedback there....

-- TW

---

Checked in the code as there was a request to see the code. See test/unit/TemplatesTest.pm for test case. As the config options do not appear to be documented elsewhere, rely on documentation in lib/TWiki.spec.

-- TW

I reverted 11996 since it broke search.

-- PTh

---

Found the problem: In templates/search.pattern.tmpl, there is a line

%TMPL:INCLUDE{"view.pattern"}%

From the spec it is not clear that this should actually work. It would be just as good to have just view here, as the pattern extension would be found anyway due to the skin. The specification is unclear here, but it seems to me to be a mistake in the template, not the code.

This use of a strange include parameter is in

backlinks.pattern.tmpl
changes.pattern.tmpl
editform.pattern.tmpl
edittext.pattern.tmpl
moveattachment.pattern.tmpl
renamewebbase.pattern.tmpl
search.pattern.tmpl
searchbookview.pattern.tmpl
searchformat.pattern.tmpl
viewnoleftbar.pattern.tmpl
viewnotopbar.pattern.tmpl

Does anybody have any idea on what the spec really wants here? -- TW

The way this is used in the current templates is that a skin, say, natedit, may call a template view.nat.tmpl, rather than getting view.tmpl, if view.natedit.tmpl is not present.

Note that this trick only works for templates ending in *.tmpl, as templates in user topics are examined for a web prefix and thus the dot notation will not be preserved.

However, this does not seem to be a good idea, as there will be no way of overriding such template in the user topics. -- TW

---

Implemented the undocumented feature leveraged by PatternSkin and NatSkin. I have my doubts about whether this is a good idea, but oh well. The documented way of forcing a skin is to use a name with .tmpl at the end. Added test case. -- TW

---

The recent changes in TWiki::Templates::_readTemplateFile() broke all of my TWikiApplications that make use of VIEW_TEMPLATE and EDIT_TEMPLATE where the value is a web.topic. The effect can be seen on the bugs web too as the normal whiteboard textarea isn't hidden anymore during edit.

• Unless this was recently added, there is no EDIT_TEMPLATE used on Bugs. Certainly not in this topic, as a view raw=debug can confirm.

This is because $web.$name isn't part of the template search path anymore. The current implementation only prunes the search if the template name is ending with .tmpl. Along the same lines a $web.$topic template name should not need any search at all.

... reopening this as urgent as this is a release blocker now.

-- MD Michael, when you are using, say,

% META:PREFERENCE{name="VIEW_TEMPLATE" title="VIEW_TEMPLATE" type="Set" value="Sandbox.Test"}%

are you using the topic Sandbox.TestTemplate or Sandbox.Test.

I believe the "spec" is that you must use the former, which works just fine. I guess one can interpret "parse $name into a web name (default to $web) and a topic name and looks for this topic" as either meaning:

• look literally for $web.$name, or
• in the following search, use $web and $name rather than what was given originally.

I interpreted this to mean the latter, but I guess you are interpreting this to mean the latter?

I had considered this to be a bug in the previous code... -- TW

---

I implemented a direct lookup for $web.$topic to support Michael's use case, but am not sure whether this is right.

We seem to be defining the spec once again based on a previous rewrite of a an earlier algorithm.

My interpretation of the actual spec is

1. templates/web/script.skin.tmpl for each skin on the skin path
2. templates/script.skin.tmpl for each skin on the skin path
3. templates/web/script.tmpl
4. templates/script.tmpl
5. Attempt to parse the template name into webName.topicName, and for the following set web = webName and Script = topicName
6. The TWiki topic web.SkinSkinScriptTemplate for each skin on the skin path
7. The TWiki topic web.ScriptTemplate
8. The TWiki topic %TWIKIWEB%.SkinSkinScriptTemplate for each skin on the skin path
9. The TWiki topic %TWIKIWEB%.ScriptTemplate

Legend:

• script refers to the script name, e.g view, edit
• Script refers to the same, but with the first character capitalized, e.g View
• skin refers to a skin name, e.g dragon, pattern. All skins are checked at each stage, in the order they appear in the skin path.
• Skin refers to the same, but with the first character capitalized, e.g Dragon
• web refers to the current web

which would not support that feature.

Anyway, this leaves the following questions, based on Michael's comments:

• if $web.$topic is interpreted as a direct lookup of $web.$topic without any further searches, if this topic is present, this would return null, even if another match could be found at the search path later, similar to when we directly look up a topic ending in *.tmpl.
  • Presumably, this is not what is meant
• does this get called in the middle of the search, or at the beginning, similar to *.tmpl to avoid any search, if possible?

In other words, say you are looking for sandbox.test with skin pattern, and the following are on the path:

• Sandbox.PatternSkinTestTemplate
• Sandbox.TestTemplate
• sandbox.test.pattern.tmpl
• sandbox.test.tmpl

but Sandbox.Test is not. Would you find these? -- TW

---

Added more test cases.

Please read again TWiki:Codev.TemplatePathIsCounterintuitive. I believe that in TWiki 4.0 we had a bug in the template lookup algorithm (does not follow the cairo spec, does not follow the dakar spec, and has an inconsistency in its pattern).

We seem to now turning that bug into part of the specification.

I do not agree but have implemented it anyway to stay consistent with the TWiki 4.0 code.

My personal preference would be to fix that.

I have fixed a bug in the 4.1 algorithm which was documented in the test cases before. -- TW

4.1.0 released

KJL