Item12070: too many calls to renderTML

Rendering the TML should actually be one of the very last steps in the pipeline. This is important as Foswiki::Meta::renderTML() performs autolinking at that stage and thus needs to respect <literal> as well as <noautolink>.

Alas, renderTML is called within code that will later on receive noautolink and/or literal wrappers on the run. So these can't protect from autolinking/rendering as renderTML is called too early when the complete code hasn't been generated yet.

We need to review the places when renderTML is called and rationalize this.

I can to this finding looking at the way formfields are rendered. There are currently two formfield types that do a renderTML of their own: label and date. So I can't protect code inside label formfields from autolinking. Not sure why there's a renderTML in Foswiki::Form::Date but that's wrong as well most probably as well.

Looking further Foswiki::Form too does a renderTML on its own part of renderForEdit. I have the deep feeling that this is not required as well.

Basically, we need to agree when exactly renderTML is required. It should definitely be somewhere very close to taking out the literal and noautolink blocks ... and nowhere else.

Should be faster as well.

Here are the diffs:

Index: test/unit/RenderFormTests.pm
===================================================================
--- test/unit/RenderFormTests.pm        (revision 15357)
+++ test/unit/RenderFormTests.pm        (working copy)
@@ -435,7 +435,9 @@
 <tr><th>Issue Name</th><td align="left"><input type="text" name="IssueName" value="_An issue_" size="40" class="foswikiInputField" /></td></tr>
 <tr><th>State</th><td align="left"><table><tr><td><label><input type="radio" name="State" value="none"  title="none" class="foswikiRadioButton"/>none</label></td></tr></table></td></tr>
 <tr><th>Issue Description</th><td align="left"><input type="hidden"
-name="IssueDescription" value="---+ Example problem"  /><div class="foswikiFormLabel"><nop><h1 id="Example_problem"> Example problem </h1></div></td></tr>
+name="IssueDescription" value="---+ Example problem"  /><div class="foswikiFormLabel">
+---+ Example problem
+</div></td></tr>
 <tr><th>Issue 1</th><td align="left"><select name="Issue1" class="foswikiSelect" size="1"></select></td></tr>
 <tr><th>Issue 2EXTRA</th><td align="left">SWEET</td></tr>
 <tr><th>Issue 3</th><td align="left"><table></table><input type="hidden" name="Issue3" value="" /></td></tr>

Index: lib/Foswiki/Form/Label.pm
===================================================================
--- lib/Foswiki/Form/Label.pm   (revision 15357)
+++ lib/Foswiki/Form/Label.pm   (working copy)
@@ -17,8 +17,7 @@
     # Changing labels through the URL is a feature for Foswiki applications,
     # even though it's not accessible for standard edits. Some contribs
     # may want to override this to make labels editable.
-    my $renderedValue =
-      $topicObject->renderTML( $topicObject->expandMacros($value) );
+    my $renderedValue = $topicObject->expandMacros($value);
     return (
         '',
         CGI::hidden(

Index: lib/Foswiki/Form/Date.pm
===================================================================
--- lib/Foswiki/Form/Date.pm    (revision 15357)
+++ lib/Foswiki/Form/Date.pm    (working copy)
@@ -62,7 +62,7 @@
     $value .=
       CGI::span( { -class => 'foswikiMakeVisible' }, ' ' . $button );
     if ($topicObject) {
-        $value = $topicObject->renderTML( $topicObject->expandMacros($value) );
+        $value = $topicObject->expandMacros($value);
     }
     else {

-- MichaelDaum - 07 Sep 2012

This can't be changed in 1.1.6 - its not a patch type thing. I also think its too late to change for 1.2 - so would have to wait until we've branched for 2.0 development to start.

-- SvenDowideit - 26 Sep 2012 - 05:43

I am separating out the issue reported in the patch above so that things get done in Item12174.

-- MichaelDaum - 22 Oct 2012

The status on this is unclear, so I'm marking it waiting for Michael.

-- CrawfordCurrie - 24 Oct 2013

Michael, The fixes are all for JSCalendarContrib. Is this fixed in Foswiki 1.2 core, or is this just an extension fix. Do we need a 2nd task to leave open against core?

-- GeorgeClark - 15 Mar 2015

The bulk of the problem has already been solved in Item12174. I'll file a new task in case I come across the issue again.

-- MichaelDaum - 18 Mar 2015

Commenting is disabled while not logged in