it seems that when Thomas redid the readTemplateFile, the recursion prevention code was accidently made too agressive, preventing chaining of tmpl files

eg twiki.custom.tmpl could not succeffully TMPL:INCLUDE{'twiki'} (allowing multiple levels of twiki.SKIN.tmpl files to progressivly refine the skin.

This is needed to enable addins like WebPermsissionsPlugin and ZenGarden etc to work through

Set SKIN=localcustom,zengarden,webpermissions

(where there is a twiki.localcustom.tmpl file that might over-ride one element in any of the twiki.SKIN.tmpl files. )

---

If I understand you right, this is a new use case that I don't think the TWiki templating system ever was meant to support.

When you include TMPL:INCLUDE{'twiki'}, that gets one and only one twiki template, whichever you got to first by the template instantiation algorithm.

That was the case in the past as well. Neither could you do things like: TMPL:INCLUDE{'twiki'} inside of twiki.myskin.tmpl, so this is not really like a super call... although it might be a good idea to have something like TMPL:INCLUDE:SUPER, which would always include the default skin.

We would have to really analyze the consequences of allowing, for example, twiki.localcustom.tmpl, twiki.zengarden.tmpl, twiki.webpermissions.tmpl, and twiki.tmpl, to be included.

Changing this to Enhancement which it is. -- TW

---

No Thomas, you are wrong. Its in the 4.0 releases. and has been in use for quite some time. This is one of those examples of why I am not happy with your changes - you still have not worked out all the functionality that is in use.

--SD

---

The 4.0 release did not have the recursion prevention in it. However, somebody, not me, added that to the Templates.pm file, I assume for good reason. (I cannot get at the SVN right now, so I cannot check the history.)

There should be a possibility of discussion so that those who added the code can explain.

My latest rewrite tried to preserve what was there as much as possible.

I think you probably should also show what you are trying to do, with a detailed example, so we can all analyze the use case. -- TW

---

r10674 | SvenDowideit | 2006-06-23 03:10:35 +0200 (Fri, 23 Jun 2006) | 2 lines

Item2530: recursion prevention

at the time $name meant something different from what it does now.

so that would be 4.0.3?

as far as explaination - see TWiki:Plugins.WebPermissions , mmm, some Joomla work, um, the commits i made to TWikiSkins and TWikiTemplates, the blog posts on http://blog.wikiring.com

but more importantly, ITS existing functionality that you broke, and other people rely on.

this bug was initially reported in http://twiki.org/cgi-bin/view/Codev.TemplatePathIsCounterintuitive around 22 Nov 2006, but i presumed that TW had used the heads up i gave him, rather than waiting for me to have time. I now have time, and have fixed the one issue I know about, but there could be more, as the test cases are way too trivial to show anything like real usage.

-- SD

Well, the test cases in http://twiki.org/cgi-bin/view/Codev.TemplatePathIsCounterintuitive regarding your example did not demonstrate the problem and you have never produced a test case showing the problem... so this was somewhat difficult to fix, isn't it....? -- TW

I see your new test case... that does explain your use case well... don't think that was meant to work like that, but it is pretty slick... -- TW

Yes, it was designed, intentionally, by me that way! I've used a variation on that functionality for at least 3 years (ie 2 fully time workplaces ago)

At no stage did it make sense to me to hard code a dropping to the default tmpl, when I want to customise existing skins.

SD