See TWiki:Sandbox.IncludeTestParamIncl, which includes TWiki:Sandbox.TestParamIncl three times, once without a paramter, once with NAME="Jane", once with NAME="Jim" parameter. The included topic has these bullets - with behaviour:

• is %IF{ "defined NAME" then="%NAME%" else="undefined" }% - bug : this returns always undefined. It should return the value of %NAME% if defined
• is %IF{ "$ NAME='%NAME%'" then="%NAME%" else="undefined" }% - this always hits the then part (not sure if this is spec)
• is %IF{ "$ NAME='Jane'" then="Jane" else="not Jane" }% - works as expected

Because of the first behaviour it is not possible to check for existence of a parameter. This prevents useful TWiki apps with parameterized includes, as discussed for example in TWiki:Plugins/EmbedPluginDev.

-- PTh

Test data from BugItem2880Test

%INCLUDE{"LitterTray.BugItem2880Test"}%

%INCLUDE{"LitterTray.BugItem2880Test" NAME="Jane"}%

%INCLUDE{"LitterTray.BugItem2880Test" NAME="Doe"}%

Added unit test to Fn_IF that illustrates broken behaviour, and fixed it.

CC

Hi Peter I have added following to If.pm at line 129

        return 1 if( $twiki->{SESSION_TAGS}{ $eval } );

so my if defined sub will look as:

$defOps{defined} =
  { name => 'defined',
    prec => 5,
    type => 0, # unary
    exec => sub {
        my( $twiki, $a, $b ) = @_;
        my $eval =  $b->evaluate($twiki);
        return 0 unless $eval;
        return 1 if( $twiki->{SESSION_TAGS}{ $eval } );
        return 1 if( defined( $twiki->{cgiQuery}->param( $eval )));
        return 1 if( defined( $twiki->{prefs}->getPreferencesValue( $eval )));
        return 0;
    }
   };

I am not sure if I have done it the right way, but it works Please check it.

-- TWiki:Main.ThomasFreudenberg - 19 Sep 2006

Thanks Crawford for the super fast fix!

Thomas: This is the code change Crawford did:

Modified: twiki/branches/TWikiRelease04x00/lib/TWiki/If.pm
===================================================================
--- twiki/branches/TWikiRelease04x00/lib/TWiki/If.pm   2006-09-18 23:41:54 UTC (rev 11526)
+++ twiki/branches/TWikiRelease04x00/lib/TWiki/If.pm   2006-09-19 00:14:25 UTC (rev 11527)
@@ -128,6 +128,7 @@
         return 0 unless $eval;
         return 1 if( defined( $twiki->{cgiQuery}->param( $eval )));
         return 1 if( defined( $twiki->{prefs}->getPreferencesValue( $eval )));
+        return 1 if( defined( $twiki->{SESSION_TAGS}{$eval} ));
         return 0;
     }
    };

-- PTh

Hi together,

that's pretty cool, I mean its nearly the same fix I did, so I was not wrong, so I am happy . Just one question left for the patch of Crawford and that's why I guess my patch ist right.

If you include a page and use IF with some new created given params like %INCLUDE{ "bla" FOO="Jane" } and you will test it inside with %IF{"defined FOO"} then I guess it should be at first test the value from the additional params. This is needs following order for tests: SESSION_TAGS, cgiQuery and at last prefs.

What do you think about this ?

-- TWiki:Main.ThomasFreudenberg - 20 Sep 2006

Hi, sorry its me again. My last message is nonsense. It is not important in which order a defined param is tested. Sorry for silly question.

But working with that, a new question is left: Shouldn't it be possible to check if a param is given ONLY by param through INCLUDE. For example: Someone has Set a global Var insinde WebPreferences with name WIDTH. To make sure that I test only WIDTH given by Param insinde the INCLUDE area I have to make sure that the param Name is unique like %INCLUDE{ "MyTopic" MyTopic_WIDTH="bla" }. It could also be done if we would have a test like "defined" but only for the params given by SESSION_TAGS.

What do you think about a additional operator in If.pm for tests like:

• %IF{ "has_param WIDTH" then=... else=... }

Wouldn't this be easier to handle, espacially when you use %INCLUDE's ? I am not sure, if "has_param" is the right name, maybe you have a better idea.

-- TWiki:Main.ThomasFreudenberg - 20 Sep 2006

That could be a useful enhancement, although by convention one can use use unique names less likely to clash with prefsrences settings. If inclined, create a change proposal in the Codev web at TWiki.org.

-- PTh

4.1.0 released

KJL