Allow Templates to Affect Textarea

This was moved from Bugs:Item2914 to facilitate discussion.

In TWiki:TWiki.TWikiApplications, users often apply view templates that separate what is visible in a topic but yet should not be user editable, from material that should be edited in the textarea. Some material is thus migrated from the textarea to areas in the template preceding or following the space for the text.

Note that the text is rendered separately from other parts of the template. Usually this is not a problem, except when the material put outside of the text should affect how the text is rendered. For example, users who try to put the <editsections /> tag into the template, hoping that then the topic will get sectioned by TWiki:Plugins.SectionalEditPlugin are in for a disappointment, as when the text is rendered, the tag is not seen.

To solve this dilemma, in our installation I have introduced a template tag %TEXTSTART% . Any material in the template after that tag will be rendered together with the text, but will not be seen during edit. Material that would affect the rendering of the text, such as above tag, or variable definitions, etc., but which should not be visible during edit should go here.

The following simple patch to lib/TWiki/UI/View.pm does the trick:

*** /e/www/twiki-dakar-4.0.2/lib/TWiki/UI/View.pm~   Fri Mar 31 23:44:35 2006
--- /e/www/twiki-dakar-4.0.2/lib/TWiki/UI/View.pm   Thu Aug 17 09:53:26 2006
***************
*** 285,290 ****
--- 285,297 ----
      } else {
          my @args = ( $session, $webName, $topicName, $meta, $minimalist );
  
+    # Add pre-text area to text
+    my @starts = split( /%TEXTSTART%/, $start );
+    if ( $#starts ) {
+      $start = $starts[0];
+      $text = $starts[1] . $text;
+    }
+ 
          $session->enterContext( 'header_text' );
          $page = _prepare($start, @args);
          $session->leaveContext( 'header_text' );

What do you guys think?

-- Contributors: ThomasWeigert- 17 Oct 2006

Discussion

I really, really don;t want to do this, for a couple of reasons. Firstly, it introduces yet another special tag into templates; there are already far too many undocumented special tags scattered about. Secondly, I think this sort of thing should be done by splitting up the template into macros that can be instantiated; viz

%TMPL:DEF{before_text}%....
%TMPL:DEF{text_body}%...

These are IMHO easier to document and if used consistently, are more flexible as a single text_body might be used in several templates. And they can be parameterised via %TMPL:P parameters.

CC

---

The template approach is already present in pattern skin.

AC

---

CC, you got to give me more than "I don't want to do this". I don't understand what you are saying above in terms of suggestion.

Same for AC, what are you saying?

Sorry for being dense, but I absolutely need a way of pushing material into the template in a way that it can affect the textarea. E.g., for TWiki:Plugins.SectionalEditPlugin, when we want to hide the section tag outside of the textarea.

I don't mind to use a different approach, but you guys got to give me something to work with.

Personally, I don't see anything wrong with the above approach, as it is consistent with what other things are being done with templates, in particular, in the pattern skin. -- TW

---

I do not find this %TEXTSTART idea very attractive either. The tag itself does not really give much clue about how to use it. You would need an extensive documentation to explain it to normal users.

If this was a proposal for a feature to my Motion program I would give it a Nerdometer score of round 8. So I sure hope there is a more generic and logical way to implement what you need.

I understand the need itself. But it also has to be logical and intuitive. The template language in TWiki is geeky enough already (a 4 or 5 on the unscientific Nerdometer scale). So a more logical implementation which is in line with how we already build templates would be preferred.

I hope CC and AC can come up with a solution for you. I may even be interested in it myself because what you describe is something I may pick up myself.

-- KennethLavrsen - 17 Oct 2006

I have updated PatternSkin documentation. See I want to insert text outside of the topic content (example refers to revision 11748).

-- ArthurClemens - 17 Oct 2006

Arthur, you misunderstand what this feature is discussing. This is not a problem of wanting to show text that is not in the text area. This feature discusses how to place text into a template that affects what is rendered in the text area. As I discussed above, there are examples of TWiki markup that enable certain features or plugins. But we may not want to show these in the text area as we may not want to allow them to be edited. But without these, that markup cannot affect the rendering of the text. This is a critical feature for twiki applications. There is currently no way of building such applications. Please review the example of the SectionalEditPlugin, but there are many other such examples, e.g., FormQueryPlugin.

The solution above is cheap and consistent with what is done in the template language. Just because that is an esoteric feature of TWiki does not make it useless. In fact, the template language is critical in TWiki. I agree it is poorly documented, but that has nothing to do with this request.

If you have another way of solving this problem, I gladly utilize it. But I cannot accept not being able to implement an important feature of TWiki applications. (Ken, you can look at my Saydo web at the my internal Motorola site to see what I mean...)

-- ThomasWeigert - 18 Oct 2006

Ah. So:

• the new text (AppText) should be part of the topic text
• should not be seen during edit

Still not sure if that cannot be reached using the current templates. I probably need an app to check this.

-- ArthurClemens - 18 Oct 2006

Almost. Let me explain in more detail...

What is seen when a twiki topic is rendered is the result of

• the view template
• the text that a user typed into the edit box earlier, and
• expansion of tags in either of these.

So you can make things show up in the rendered topic by either typing it into the edit box or by placing it into the view template (or somewhere where the view template uses it).

Now it turns out that the twiki rendering algorithm is such that the text that a user typed into the edit box is rendered separate from the other material that is pulled into the template.

As a consequence, there is no way to have text in the template that affects the text that comes from the edit box.

For example, you might want to define a set of queries from the FormQueryPlugin that should be executed for every topic, and the result is then rendered in the text area. Or you might want to put a tag enabling the SectionalEditPlugin into the template, and consequently the text in the text area is rendered in sections. There are many more such examples.

However, this is not possible due to the separate rendering. This could be solved in two ways: We could render the whole topic at once, but there is probably a good reason why twiki does not do it this way. Or we could do what is suggested above, namely split the template into text that is rendered with the text area, and text that is not, as previous. The latter is the least impactful approach.

It can be implemented in various levels of impact: (i) Just adjust the code in TWiki::UI::View so that if the template is segmented as described, the code in the text area is affected, but do not actually change the template. Impact is one if statement. (ii) Add the segmentation into the template also. Impact: One if statement, one split, one substitution. I would be fine with (i).

I see this capability an essential aspect for TWiki applications and believe that it should be supported somehow. An alternative solution is most welcome.

-- ThomasWeigert - 18 Oct 2006

I understand Thomas' need and I think it is a valid need. I am just not happy with the %TEXTSTART tag as I stated above.

Any other implementations or specs that can be proposed which gives us the needed feature and is not too hard to understand?

-- KennethLavrsen - 23 Oct 2006

The only other alternative would be to render the whole topic in one go (the various portions of the template together). Probably no performance impact, but different from today. Any other solution seems more convoluted.

The proposed %TEXTSTART% tag is consistent with how other aspects of templates work, as e.g., in the search template. In addition, the change is only 5 short lines, see above..., and 100% backwards compatible...

-- ThomasWeigert - 23 Oct 2006

Here is a simple example that again motivates this feature:

Say you want to put a Table of Content automatically into every topic that is affected by a given template.

There is no way to achieve this. If you put the %TOC% tag into the template, it will not return anything, unless there are actual headers in the template. It will not look at the text that was entered at the white board.

Unless somebody can propose an alternative, please don't hold me up here. We using this feature in many of our topics. I don't mind going with an alternative approach, but the general capability must be supported...

-- ThomasWeigert - 29 Oct 2006

I did not feel that anyone had a doubt about the need. It was the mysterious TWiki Variable used TEXTSTART that seems to trigger the worry. I would have hoped the guys that are into the details of plugins would have proposed a syntax that was more in line with the already existing syntax.

I cannot help thinking - isn't there a need for a TEXTSTOP also for stiff added after the main text areas? And why not STARTTEXT - STOPTEXT? And why would it still work without any of them?? - would a newbie ask.

Maybe by adding a type or action parameter to or %TMPL:DEF{type="render" somename}% would be more logical and more flexible for further extension of template features. Just brainstorming here.

-- KennethLavrsen - 29 Oct 2006

The use of a separating word (let's call it a pseudo-tag, as it is not really a twiki tag) in the template (the particular word does not matter, I just happened to use %TEXTSTART%) is a style that is used throughout the templates.

For example, look at form.tmpl where you find the pseudo-tag %REPEAT% to show where there is a repetition of lines (this is used in several other templates to indicate repetition). In addition, there is %ROWEXTRA% and %ROWVALUE%.

Or look at search.tmpl, and its use of again %REPEAT%, %TEXTHEAD%, and, of course, %SPLIT% (the latter is used in a number of other templates releated to search to indicate where to break a template into pieces.

Basically, templates use two kinds of pseudo-tags throughout:

1. to indicate a special place where the template is split, or repeated, etc.
2. to indicate a place where something has to be inserted into the template

I am using %TEXTSTART% to achieve (1).

I believe such usage is consistent with the way templates are written. Again, I don't care about which word is used, I was thinking about using %SPLIT% as in the search templates, but am worried about a conflict. If that is a prefered alternative, as the word is already used, I will investigate whether there is an opportunity for conflict. (I don't think so, but would like to study this some more.)

As an aside: I don't know whether plugin developers are aware of the wide proliferation of such tags in templates. These are not documented anywhere, but could clash with tags used in plugins.

-- ThomasWeigert - 01 Nov 2006

I must say that the use of SPLIT is a pain in the ass to work with, it costed me at least 10 times the effort to get the output right because of unexpected renderings (template logic is assumed from a lib file but not documented anywhere, for instance what is the string before SPLIT and after SPLIT). Use of named sections would be much better.

-- ArthurClemens - 01 Nov 2006

We can totally redo how our templates are done, but given that there is a system today, it might be better to stick with the existing system rather than cooking up a new one for just one feature.

I think that if we change the way of handling templates, that must be done systematically.

Currently, "named sections" (I assume you refer to the TMPL fragments) are not manipulated in the code except for being expanded, while the pseudo-tags are used to split or repeat sections.

I absolutely agree that templates need to be documented other than be analyzing the code.

-- ThomasWeigert - 01 Nov 2006

It depends on how you define "system". SPLIT is still not documented, and gives me 1 hit in TWiki web: TWiki.TWikiTemplates (as a user question: When I sneak under the covers and look at the templates/*.tmpl files, there are some interesting-looking bits that aren't documented here, such as %REPEAT% and %SPLIT%. It would be nice if they could be documented.)

Could we use a similar system as includes, like %STARTTEXTSECTION{"topic"}%%ENDTEXTSECTION{"topic"}% ?

-- ArthurClemens - 01 Nov 2006

Maybe in the future. Not in the next 6 weeks. But you need to understand %SPLIT% and friends if you want to build a template that works with TWiki (as you won't be able to do searches without it). This is a tangent, though... I am asking for supporting an essential feature in TWiki by using an existing feature in TWiki (namely the pseudo-tags in templates). Can we get back to this topic?

-- ThomasWeigert - 01 Nov 2006

Well the problem with using 1 'split' tag is that you need to define the functionality in detail. Would it be the only tag, shouldn't there be more (as Kenneth wrote)? While a "named section" approach would leave more room for later changes and additions.

-- ArthurClemens - 01 Nov 2006

But this does not matter at this point. Nobody is proposing to rewrite existing templates to change %SPLIT% to named sections. That is a nice idea for 4.2. Thus, the existing approach is the consistent with existing TWiki style. Introducing named sections just for this particular item would be introducing inconsistencies.

-- ThomasWeigert - 08 Nov 2006

Here is an example use of the proposed solution to this requirement: Say you want to have a TOC on every topic. You might do something like the following.

• In a template, put:

  %TMPL:DEF{"textcontent"}%<div class="patternTopic">%BROADCASTMESSAGE% %TEXTSTART% %TOC% 
  %TEXT%</div><!-- /patternTopic-->%TMPL:END
        

• The core code change required to make this work is shown on top of this page (5 NCSLOC).

-- ThomasWeigert - 08 Nov 2006

I have a proposed solution that requires no new syntax:

[22:36]    SvenDowideit   a META setting
[22:37]    SvenDowideit   setting HIDDENPRE and HIDDENPOST
[22:37]    SvenDowideit   and the view tmpl contains %HIDDENPRE% %TEXT% %HIDDENPOST%
[22:37]    SvenDowideit   did i just solve it with zero code?
[22:37]    PeterThoeny   sven, i do not follow
[22:37]    Lavr   Neither do I
[22:37]    SvenDowideit   ok, you know how you can set topic variables from the 'more topic actions'
[22:37]    SvenDowideit   and they go into %META:SET or something
[22:38]    SvenDowideit   topic templates can define them, and they get carried over to the created topic (i did this a few months ago)
[22:38]    SvenDowideit   then those variables can be used in the view.tmpl
[22:38]    SvenDowideit   and when they are not set, they are ''
[22:38]    ArthurClemens   sounds like a good proposal to put forward
[22:38]    SvenDowideit   "Edit topic preference settings" on oops more
[22:38]    SvenDowideit   this presumes i've understood his requirements
[22:38]    SvenDowideit   ok - i'll add it to the topic
[22:38]    Lavr   I still do not see how this enables what Thomas needs.
[22:39]    PeterThoeny   i understand the hidden topic settings, stored as META:SETTING, but i do not see the connection to _where_ in the text you want to start edit the content
[22:39]    SvenDowideit   it makes it possible to have topic text that is rendered in view, that is _not_ in the edit textarea
[22:39]    SvenDowideit   which is what i understand the topic to say
[22:39]    Lavr   I have the understanding that Thomas want to use a template doc for certain topics that adds some default 

-- SvenDowideit - 13 Nov 2006

I cannot see how the topic-specific preferences meet my needs. Please address the following use case:

• In a topic specific view template, add a %TOC% tag to the top of every page, but outside the text area, so that it cannot be edited.
• When viewed, that tag should expand in a table of content for the whole topic

Again, I don't care of what the mechanism is but this must be doable. I have proposed (and used in our installation) a mechanism that is consistent with the TWiki templating mechanism. If there is a better suggestion, I gladly use it, but I need something.

Also, Sven is not correct in that the preferences just show up magically in the text. They are just preference settings. There must be something in the text that leverages them (I have implemented them, so I am certain of that).

Ken's interpretation of what I want is correct. The above use case is a good example. I use topic specific templates extensively in TWiki applications as they keep everything users should not monkey with out of sight and reach.

-- ThomasWeigert - 14 Nov 2006

1. edit your topic specific template to contatin %PREAMBLE% %TEXT% %POSTAMBLE%
2. then Set %PREAMBLE% to %TOC%
   • the META:SETTINGS are hidden from the standard edit, and are accessible via the 'more topic actions'

this can also be done on a per web basis, or on a TWiki wide basis

-- SvenDowideit - 14 Nov 2006

Sven. If I follow your method, define a template with these extra twikivars, then it also means that

• Anyone can goof up the template by changing the settings in More
• If I later want to improve the layout on my template and this requires the definition of another twikivar, and I already have 2000 topics that uses this template, then it also means that I have to edit 2000 topics and via their More... settings - as I understand it. Which is in practical not feasible at all.

I think I understand Thomas' usecase. I am personally only objecting to the syntax because TEXTSTART intuitively

• Does not really say what it does. STARTRENDER might be more descriptive.
• Intuitively triggers a normal mind to think that there is a corresponding STOP tag. Ie. you think that there must be a TEXTSTOP tag but there isn't.

So there are TWO different issues to address.

• Those that THINK there is an existing functionality that does the job. I am still not convinced that there is a feasible way.
• Those that just have a problem with the syntax. THAT must be possible to address by simple means.

-- KennethLavrsen - 14 Nov 2006

I'm a bit puzzled by all this. The discussion seems to have lost sight of the original requirement. Seems to me there are two possible requirements expressed above:

1. Support embedding uneditable text anywhere in a topic. The uneditable text must not appear in the text editor.
2. Support embedding editable text into the middle of uneditable text (so that the editable text is framed by static text)

I can't see a simple solution to the first requirement, as it would imply that anchors would be required in the edit, or the edit broken into a series of textareas, or similar. Yucky.

The second approach is trivially addressed by Sven's proposal. Another approach would be to embed %INCLUDEs in the view template; for example

%INCLUDE{"HiddenPreText" warn="off"}%
%TEXT%
%INCLUDE{"HiddenPostText" warn="off"}%

so that the HiddenP*Text topics get included per-web. These topics could clearly affect the rendering of the topic. Alternatively, you could use %TMPL:INCLUDE if the pre/post text were intended to be skin-specific.

Note that neither the variable solution or the %*INCLUDE solutions imply any additional code. As I read Thomas' original requirement, any of these approaches address the problem with zero extra code, as Sven said.

-- CrawfordCurrie - 14 Nov 2006

Crawford, so sorry but neither of your points are my requirement. I may be very poor in expressing myself, but my requirement is that it is possible that

• designated text in a template which rendered jointly with the text from the textarea but precedes the text from the textarea.

I'll examine Sven's preamble suggestion. Ken got it right. I don't care about the name, but I do care about the functionality.

As a reminder, here is the sample use case cited again:

• In a topic specific view template, add a %TOC% tag to the top of every page, but outside the text area, so that it cannot be edited.
• When viewed, that tag should expand in a table of content for the whole topic

-- ThomasWeigert - 14 Nov 2006

Analysis of Sven's suggestion.

I believe Sven is suggesting the following: Create some variable, say %PREAMBLE% and insert it through a template into the topic. Then assign a value to this variable via the site-level preferences.

Of course, it is possible to have in the topic a variable %% and then the following meta

First note that this is no different of just inserting %TOC% into the text. There is no value whatsoever to go through the %PREAMBLE% variable.

But more importantly, this still does not address the requirement that

• the editable text area does not have access to this variable and
• the TOC reflects the text in the text area.

If you look into the rendering code in TWiki::UI::View, the key section is the following:

    # extract header and footer from the template, if there is a %TEXT% tag marking the split point
    my( $start, $end );
    if( $tmpl =~ m/^(.*)%TEXT%(.*)$/s ) {
        $start = $1;
        $end = $2;
    } else {

and

            $page .= _prepare($text, @args);

The text is rendered in _prepare.

As you can see, only what is in the $text variable will be rendered together. But the $text variable is (unless it comes from the url parameter) the text in the topic (minus the meta). Whatever is in the template before or after the %TEXT% tag will not be rendered together with the topic text.

So Sven's suggestion does not solve my problem.

-- ThomasWeigert - 15 Nov 2006

no, I get the feeling you have not understood what Crawfrod and I are suggesting.

1. insert a variable into the rendering template - NOT a topic template. (or as Crawford suggests, an INCLUDE{}
   • this variable is thus NOT accessible via editing that topic
2. then define that META variable or INCLUDE to suite your needs.

i realised after Crawford mentioned it, that I've been doing the INCLUDE version for many many years, thus forcing all topics in a web to start with a level one header (topicname) and a TOC - which are only editable via the INCLUDED topic.

-- SvenDowideit - 15 Nov 2006

I understood, assuming by rendering template you mean view.pattern.tmpl. There is no way you could have a TOC without something being visible in the text, as you can see from the code in TWiki::UI::View::view (excerpted above).

If you don't mind, can you post your template that you think does this. I cannot see how it could work.

By the way, as you can see from the above code, even the standard template uses exactly the same mechanism that I am proposing: there is a pseudotag %TEXT% which is used to split the template, just like the %TEXTSTART% (or whatever else you want to call it) pseudotag proposed here.

-- ThomasWeigert - 15 Nov 2006

Just as an FYI... an approach I tried earlier but which did not work was the following:

In the topic template, put

%TMPL:DEF{"textcontent"}%<div class="patternTopic">%BROADCASTMESSAGE% 
%META{"formfield" name="Preamble"}%
%TEXT%</div><!-- /patternTopic-->%TMPL:END%

and then have a hidden form field named "Preamble" where I put the text that should be placed in the topic (here "=%TOC%="). The hope was that the %TOC% would be rendered together with the rest of the topic when the formfield was evaluated. However, that is not the case, and thus this attempt fails for the same reasons that just putting %TOC% into the textcontent template section fails.

One more thing, as I said, I don't care about the syntax. I hope that either the string %TEXT or TEXT% can be in the pseudo-tag, so that it is most efficient to handle (can use a single split in TWiki::UI::View::view.

It is also fine to have a parallel trailing stop construct after the text, as suggested by Ken, albeit there is nothing I know that would benefit from this capability. But I don't think it would slow down the system if it was available as a capability.

-- ThomasWeigert - 16 Nov 2006

mmm, I just did as Crawford suggested

1. add %INCLUDE{"ShowAToc"}% to the view.skin.tmpl i use
2. create ShowAToc, and add all sorts of TML to it, and that is what you see above the topic.

what surprised me, is that TOC is still special, and is the only? TML that is not expanded there - if you said this somewhere here, i didn't notice it, i'm sorry.

So. the generic solution requires no new tag, except to workaround a problem in TOC? that does not seem reasonable to me.

so... to facilitate non-editable rendered parts of the output HTML, it Still is the most sensible thing to use the rendering templates, as thats what they are designed to provide. You have however highlighted an important use case that shows that TOC being SMELLY is bad

-- SvenDowideit - 16 Nov 2006

Yes, I am not surpirsed as that is what I described above over and over again. This is, by the way, not unique to %TOC%. Any tag that needs to analyze the full topic in order to do its work cannot go into the template unless the feature discussed here is supported.

• or if we fix this problem at the root cause - by fixing those tags to work as a user would expect - anywhere in a template

That is a big hole in our offering....

-- ThomasWeigert - 16 Nov 2006

Per Kenneth's comment I suggest to allow optionally a %STARTTEXT% followed by some text to precede %TEXT% in the view templates, and to allow optionally some text followed by %STOPTEXT% to follow it. As before, %TEXT% is replaced by the text from the text area, but it is rendered jointly with the optional text before it and the optional text after it, rather than these being rendered in three separate passes (as currently the case).

-- ThomasWeigert - 17 Nov 2006

whereas I suggest that we realise this is a bug in how those tags are rendered, and think about fixing the bug, rather than putting in a limited workaround, which most users won't realise to look for when they encounter the problem

-- SvenDowideit - 17 Nov 2006

Let's understand first who is the user here. The only people who would know about these tags are the template designers. No ordinary TWiki user would ever see these tags. These are the same people who need to know about %SPLIT%, %TEXT%, etc., as existing already.

Secondly, there are only two ways I can see of handling this:

1. The approach discussed in this topic which allows to render a small additional portion of the template together with the text.
2. Rendering the whole template once after all tags have been instantiated instead of rendering it in pieces.

I have lots of worries about about (2) as the impact of such is hard to understand. (1) is a much smaller impact change.

I can make one additional offer to give you piece of mind: I volunteer, for the next release, to better document all templates for these hidden pseudo-tags, as well as the template language.

-- ThomasWeigert - 17 Nov 2006

and approach 3&4 and i'm sure there are many others possible

1. fix TOC and the others to render at a specific time in the process (presuming there is a TOC tag), then keep it in memory, and use it later -
2. do as Crawford suggested, make TOC a plugin that is handled at an appropriate place, so that it works corretly

just because you can only htink of 2 options, does not mean fixing TWiki is not a better option.

-- SvenDowideit - 17 Nov 2006

There is nothing broken with TOC. Making it a plugin won't change this situation.

To be honest, I am finding it difficult to relate to your comments as when I look at the TWiki rendering algorithm I do not see how they could be realized other than using again (1) and (2).

Whatever you do, you have to give the rendering routine the preambles and postambles together with the topic text to the TOC and to the plugins. If you don't, any tag that needs access to all the text won't be able to work.

-- ThomasWeigert - 17 Nov 2006

Checked in version using Ken's suggested pseudo-tags and provided test case.

-- ThomasWeigert - 20 Nov 2006

shrug. Seems to me that going from, "Feature as proposed not accepted but it may be with different syntax." to, "Checked in version" is not necessarily the desired colaboration process.

-- SvenDowideit - 20 Nov 2006

I may be confused about the process here. In another topic Ken told me that it could not be reviewed until checked in. My understanding is that the merge process sorts these things out. Please advise.

-- ThomasWeigert - 20 Nov 2006

I am not a decision maker. My Role of customer advocate is

• Monitor feature proposals, raise concern
• Bring forward features with proposals to release meeting

It is the release meeting that make decisions. Unless there is no voices against the feature. Then it it the 14 day rule. And in this cases there was plenty of concern raised.

The decision for this proposal at EdinburghReleaseMeeting2006x11x13 was:

• Meeting participants agreed that we do not like the %TEXTSTART% syntax as proposed.
• Sven D adds a proposal to meet Thomas actual need with existing features.
• Thomas should evaluate and see if this meets his need.
• Kenneth proposed STARTRENDER - STOPRENDER as simpler alternative.
• All need to give Thomas more feedback.

Ie. no acceptance of the proposal based on the assumption that there was an alternative way.

Since then the status is that - Sven D was not able to propose a working solution that would eliminate the need of the feature. And neither has anyone else. Many developers keep on claiming that it can be done but noone has spent the time needed to give a serious tested work around. So I understand Thomas' frustration.

But Sven is right that the feature was not accepted because Sven convinced us that there was another way within existing feature set. But this turned out to not be true.

Thomas implemented my proposal - but that was just a proposal to address the syntax concern and not a decision that was voted for.

There is only one way to close this one.

• We vote at next release meeting - maybe an extraordinary meeting with just this point. If accepted it stays. If rejected we revert the code and Thomas will have to patch his own TWiki or move the feature to an extension.

If rejected the next natural step should be to follow up on Sven's claim that there is a bug to be fixed. But it seems to be a totally new proposal that needs work on the spec first.

The item where the decision for the feature was reached through concensus (noone against) but the implementation was open for discussion was TemplatePathIsCounterintuitive which I will not discuss here. Just mention it because Thomas refered to it

-- KennethLavrsen - 23 Nov 2006