You are here: Foswiki>Tasks Web>Item10907 (05 Jul 2015, GeorgeClark)Edit Attach

Item10907: Whitespace effecting delayed CALC in search results unexpectedly.

pencil
Priority: Normal
Current State: Closed
Released In: 2.0.0
Target Release: major
Applies To: Extension
Component: SpreadSheetPlugin
Branches:
Reported By: TimotheLitt
Waiting For:
Last Change By: GeorgeClark
Here is some bizarre behavior that I can't explain. I think it's wrong (hence the task), but I'd at least like an explanation.

I have a %SEARCH that finds a couple of topics and displays links. With it formatted for readability, none of the macros are expanded except the SEARCH; one gets an ugly mess. But the same SEARCH - exactly - with the end-of-lines removed works. Here is a version - minimally changed so it finds items instead of calendars. Note that in the failing case, I changed the search to just 1 digit - that's so this topic doesn't take several minutes to display. It's not the trigger for this behavior.

  • Version 1 - no end-of-lines. I know items aren't calendars, but it will find a couple that match.
<sticky>%CALC{$SET($ThisYear,$EVAL(%DISPLAYTIME{"$year"}%+0))}% 
%CALC{$SET($NextYear,$EVAL(%DISPLAYTIME{"$year"}%+1))}%</sticky>
   * Current Family Calendars <sticky>%<nop>SEARCH{   "Item\d\d\d\d$"   web="%WEB%"   scope="topic"   regex="on"   nonoise="on"   casesensitive="on"   reverse="off"   separator=" "    nofinalnewline="on"   format="$percntCALC{\"$IF($OR($EXACT($GET($ThisYear),$VALUE($REPLACE($topic,1,$EVAL($LENGTH($topic)-4)))),                                                     $EXACT($GET($NextYear), $VALUE($REPLACE($topic,1,$EVAL($LENGTH($topic)-4))))),                                              [[$web.$topic][$REPLACE($topic,1,$EVAL($LENGTH($topic)-4))]], <nop>)\"}$percnt"
 }%</sticky>

  • Current Family Calendars %SEARCH{ "Item\d\d\d\d$" web="Tasks" scope="topic" regex="on" nonoise="on" casesensitive="on" reverse="off" separator=" " nofinalnewline="on" format="$percntCALC{\"$IF($OR($EXACT($GET($ThisYear),$VALUE($REPLACE($topic,1,$EVAL($LENGTH($topic)-4)))), $EXACT($GET($NextYear), $VALUE($REPLACE($topic,1,$EVAL($LENGTH($topic)-4))))), $REPLACE($topic,1,$EVAL($LENGTH($topic)-4)), )\"}$percnt" }%

  • Version 2 - would be a whole lot easier to maintain - but look at the mess! (Imagine (or try) it with all 4 digits :-()
<sticky>%CALC{$SET($ThisYear,$EVAL(%DISPLAYTIME{"$year"}%+0))}%
%CALC{$SET($NextYear,$EVAL(%DISPLAYTIME{"$year"}%+1))}%</sticky>
   * Current Family Calendars <sticky>%<nop>SEARCH{
   "Item\d$"
   web="%WEB%"
   scope="topic"
   regex="on"
   nonoise="on"
   casesensitive="on"
   reverse="off"
   separator=" "
   nofinalnewline="on"
   format="$percntCALC{\"$IF($OR($EXACT($GET($ThisYear),$VALUE($REPLACE($topic,1,$EVAL($LENGTH($topic)-4)))),
                                 $EXACT($GET($NextYear),$VALUE($REPLACE($topic,1,$EVAL($LENGTH($topic)-4))))),
                                                [[$web.$topic][$REPLACE($topic,1,$EVAL($LENGTH($topic)-4))]], <nop>)\"}$percnt"
 }%</sticky>

  • Current Family Calendars %SEARCH{ "Item\d$" web="Tasks" scope="topic" regex="on" nonoise="on" casesensitive="on" reverse="off" separator=" " nofinalnewline="on" format="$percntCALC{\"$IF($OR($EXACT($GET($ThisYear),$VALUE($REPLACE($topic,1,$EVAL($LENGTH($topic)-4)))), $EXACT($GET($NextYear),$VALUE($REPLACE($topic,1,$EVAL($LENGTH($topic)-4))))), $REPLACE($topic,1,$EVAL($LENGTH($topic)-4)), )\"}$percnt" }%

-- TimotheLitt - 21 Jun 2011

Hi Timothe, this is most likely due to the fact that CALC is warty as a warty thing smile

It (ab)uses commonTagsHandler quite severely. So, try enabling its registerTagHandler equivalent ('SSP'), uncomment these lines:

diff --git a/lib/Foswiki/Plugins/SpreadSheetPlugin.pm b/lib/Foswiki/Plugins/SpreadSheetPlugin.pm
index a2a4bca..28b98c8 100755
--- a/lib/Foswiki/Plugins/SpreadSheetPlugin.pm
+++ b/lib/Foswiki/Plugins/SpreadSheetPlugin.pm
@@ -38,16 +38,16 @@ sub initPlugin {
     # CALC but in a tag handler instead of in commonTagsHandler. That means
     # you can't use table references, but you can rely on the execution order
     # relative to other macros.
-#    Foswiki::Func::registerTagHandler(
-#        "SSP",
-#        sub {
-#            my ( $session, $attributes, $topic, $web ) = @_;
-#            require Foswiki::Plugins::SpreadSheetPlugin::Calc;
-#            $Foswiki::Plugins::SpreadSheetPlugin::Calc::rPos = 0;
-#            $Foswiki::Plugins::SpreadSheetPlugin::Calc::cPos = 0;
-#            return Foswiki::Plugins::SpreadSheetPlugin::Calc::doCalc(
-#                $attributes->{_DEFAULT});
-#        });
+    Foswiki::Func::registerTagHandler(
+        "SSP",
+        sub {
+            my ( $session, $attributes, $topic, $web ) = @_;
+           require Foswiki::Plugins::SpreadSheetPlugin::Calc;
+            $Foswiki::Plugins::SpreadSheetPlugin::Calc::rPos = 0;
+            $Foswiki::Plugins::SpreadSheetPlugin::Calc::cPos = 0;
+            return Foswiki::Plugins::SpreadSheetPlugin::Calc::doCalc(
+                $attributes->{_DEFAULT});
+        });
 
     # Flag to skip calc if in include
     $skipInclude =

Of course, the SSP macro won't be useful in a TML table, but many CALCulations (such as yours) aren't table related anyway.

I'm a big fan of spacing out macros like this (in fact I tried to space-out most of our macro usage in the default Foswiki topics/documentation), so I can relate to your frustration.

So, I try to avoid CALC at all costs, and I do this by:

Unlike CALC, all these macros behave predictably and can be delayed safely because they are using registerTagHandler instead of commonTagsHandler to register their macros.

-- PaulHarvey - 22 Jun 2011

Sorry for the slow response, I've been stretched a bit thin.

It turns out that there's a simple, if undocumented solution found by reading code...

If the CALC lines are continued with \ (backslash) before newline, the problem disappears!

It's not obvious why CALC doesn't just assume the \ (after all, the string is quoted). But I decided to accept success...

Unless someone has a good reason for why CALC requires the \, it would be good to remove the requirement for it. Otherwise, perhaps this could be documented smile

I'm not sure how I could solve my actual problem without CALC - I didn't see an operator for "this year +1".

The more interesting case is where I build a list of links to all the the calendars I can find that are not this year or next. That uses a similar CALC to filter out this year and next, and to create the short links by extracting the last 4 chars of the topic names.

I guess beauty has its price...

-- TimotheLitt - 28 Jun 2011

"this year + 1" - can done without SSP using (trunk-only):
%QUERY{"%SERVERTIME{"$year"}% + 1"}%

Test: 2012

QuerySearch only has a fraction of the operators which SpreadSheetPlugin provides, so you won't always find what you want. But the basics are there, which is usually enough.

I'm loathe to changing the SSP code, because honestly I avoid using it. Better leave this to some other brave soul who has time to thoroughly use & test the change (I note there aren't (m)any? tests for CALC's obscure rendering behaviour).

-- PaulHarvey - 29 Jun 2011

I think that this can be marked closed for 1.2. %CALCULATE macro is now enabled. That plus Timothe's backslash find should be enough to mark this fixed.

-- GeorgeClark - 04 Jan 2015
 

ItemTemplate edit

Summary Whitespace effecting delayed CALC in search results unexpectedly.
ReportedBy TimotheLitt
Codebase 1.1.3, 1.1.3 RC1, 1.1.3 beta1, 1.1.2, 1.1.1, 1.1.0, 1.1.0 beta1, 1.0.10, 1.0.9, 1.0.8, 1.0.7, 1.0.6, 1.0.5, 1.0.5 beta1, 1.0.4, 1.0.3, 1.0.2, 1.0.1, 1.0.0, 1.0.0 beta3, 1.0.0 beta2, 1.0.0 beta1, trunk
SVN Range
AppliesTo Extension
Component SpreadSheetPlugin
Priority Normal
CurrentState Closed
WaitingFor
Checkins
TargetRelease major
ReleasedIn 2.0.0
CheckinsOnBranches
trunkCheckins
masterCheckins
ItemBranchCheckins
Release01x01Checkins
Topic revision: r8 - 05 Jul 2015, GeorgeClark - This page was cached on 29 Jun 2016 - 12:52.

The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. See Copyright Statement. Creative Commons License