Making %VAR capable of seeing VAR values on Topics, as well as on Webs.

Presently VAR{} is only useful at the web-level, for querying what has been set in WebPreferences. The following suggests that VAR should be capable of returning variable values from the topic-level too, by a natural extension of the syntax. It provides an implementation and contrasts this simple extension against the Query Search mechanism introduced in 4.2.0 .

From VarVAR:

VAR{"NAME" web="Web"} -- get a preference value from another web

• Syntax: %VAR{"NAME" web="Web"}%
• Example: To get %WEBBGCOLOR% of the Main web write %VAR{"WEBBGCOLOR" web="Main"}%, which expands to #FFEFA6
• Related: WEBPREFSTOPIC

I have modified a client's 4.1.2 to permit the retrieval of any variable on any topic, syntax as follows:

Example, replaces VarVAR documentation

VAR{"NAME" web="Web" topic="Topic"} -- get a preference value from another web and (optionally) topic

• Syntax 1: %VAR{"NAME" web="Web"}%
• Example: To get %WEBBGCOLOR% of the Main web write %VAR{"WEBBGCOLOR" web="Main"}%, which expands to #FFEFA6
• Syntax 2: %VAR{"NAME" web="Web"  topic="Topic"}%
• Example: To get %ALLOWTOPICVIEW% of the Main.%USERSTOPIC% topic write %VAR{"ALLOWTOPICVIEW" web="Main" topic="%USERSTOPIC%"}%,
• Related: WEBPREFSTOPIC

Supercedes

In 4.1.2 the closest you could get is as follows

(11:37:03 PM) Peter Thoeny: what you try to do does not work since $pattern only catches topic text, excluding meta data
(11:38:04 PM) Peter Thoeny: doc: A regular expression pattern to extract some text from a topic (does not search meta data; use $formfield instead)
(11:33:55 PM) martinrjcleaver: %SEARCH{ "TOPIC" regex="on" scope="text" web="Sleep1" nonoise="on" header="| *Topic* | *VIEWABLE BY* | *CHANGEABLE BY *|" format="| $topic | $pattern(.*?* Set ALLOWTOPICVIEWs*=s*([^s]*).*) <br/> $pattern(.*(PREFERENCE.*).*) | $pattern(.*?* Set ALLOWTOPICCHANGEs*=s*([^s]*).*) |"}%
in 4.2: preferences[name='FOOBAR'].value

Request for 4.2.x

As Peter says, in principal, TWiki04x02.QuerySearch supports access of a VAR on a Web.Topic. Yet I'd like the change to go into the core because it is a natural extension of both the existing facility and syntax, and (AFAIK) it doesn't break anything.

1. In principal, do you support this change?
2. In practice, do you approve if the implementation?

To encourage transition to the query style where appropriate I also think we should add the following to the documentation for VAR in 4.2:

Note (to go into VarVAR documentation)

TWiki.QuerySearch (introduced in TWiki 4.2) provides a mechanism to retrieve not just variables on webs and topics but also to enquire into the number and type of attachments and filter by form field values. You will likely find that facility more useful for any complex queries, but for simple variable value retrieval VAR is fine and may be quicker.

References

• Original conversation - http://koala.ilog.fr/twikiirc/bin/irclogger_log/twiki?date=2007-10-10,Wed&sel=42#l38
• Explanation of getWebPreferencesValue - http://twiki.org/cgi-bin/view/Codev/AccessControlsVersusPreferences and http://twiki.org/cgi-bin/view/TWiki/TWikiPrefsDotPm#TWiki04_ObjectMethod_get_WebPref

Application

I use the following embedded in an administrator-only skin. It shows current effective permissions for the current page (contrast with SitePermissions, which shows effective permissions at the web level, and http://twiki.org/cgi-bin/view/Plugins/WebPermissionsPlugin which shows declarations, rather than effective permissions at the web level.

%SEARCH{ "TOPIC" regex="on" scope="text" web="%WEB%" nonoise="on" excludetopic="%EXCLUDETOPICS%
" header="| *Topic* | *VIEWABLE BY* | *CHANGEABLE BY*|" format="| $topic <br> $percntICON{lock}$
percnt <a href='%SCRIPTURL{oops}%/$web/$topic?template=topicacls'>ACL</a>  <a href='%SCRIPTURL{m
anage}%/$web/$topic?action=editSettings'>Settings</a> | $percntICON{choice-yes}$percnt $percntVA
R{\"ALLOWTOPICVIEW\" web=\"$web\" topic=\"$topic\"}$percnt <br>$percntICON{choice-no}$percnt $pe
rcntVAR{\"DENYTOPICVIEW\" web=\"$web\" topic=\"$topic\"}$percnt | $percntICON{choice-yes}$percnt
 $percntVAR{\"ALLOWTOPICCHANGE\" web=\"$web\" topic=\"$topic\"}$percnt <br>$percntICON{choice-no
}$percnt $percntVAR{\"DENYTOPICCHANGE\" web=\"$web\" topic=\"$topic\"}$percnt |" }%

Implementation (TWiki.pm, diffed against 4.1.2)

*** 2730,2749 ****
      my( $this, $params ) = @_;
      return $this->{templates}->tmplP( $params );
  }

  sub _VAR {
      my( $this, $params, $topic, $inweb ) = @_;
      my $key = $params->{_DEFAULT};
      my $web = $params->{web} || $inweb;
      # handle %MAINWEB%-type cases
      ( $web, $topic ) = $this->normalizeWebTopicName( $web, $topic );
      # always return a value, even when the key isn't defined
!     return $this->{prefs}->getWebPreferencesValue( $key, $web ) || '';
  }

  sub _PLUGINVERSION {
      my( $this, $params ) = @_;
      $this->{plugins}->getPluginVersion( $params->{_DEFAULT} );
  }

  my $ifFactory;
--- 2730,2790 ----
      my( $this, $params ) = @_;
      return $this->{templates}->tmplP( $params );
  }

  sub _VAR {
      my( $this, $params, $topic, $inweb ) = @_;
      my $key = $params->{_DEFAULT};
      my $web = $params->{web} || $inweb;
+     my $differentTopic = $params->{topic};
+     my $warn = $params->remove('warn') || '';
+ # TODO: clean up $warn param
+ # TODO: consider use of param variables in the included topic
+ # TODO: consider an equivalent of INCLUDEWARNING for VAR
+
      # handle %MAINWEB%-type cases
      ( $web, $topic ) = $this->normalizeWebTopicName( $web, $topic );
      # always return a value, even when the key isn't defined
!     my $value;
!
!     unless( $this->{security}->checkAccessPermission(
!                     'view', $this->{user}, undef, undef, $differentTopic, $web ))
!            {
!             return $this->_includeWarning( $warn, 'access_denied', "$web.$differentTopic" );
!          }
!
!
!       if ($differentTopic) {
! #          TWiki::Func::writeDebug("1. $web.$topic trying TopicPreferencesValue for $web.$dif$
!         $value = $this->{prefs}->getTopicPreferencesValue( $key, $web, $differentTopic );
!
!         unless (defined $value) {
! #          TWiki::Func::writeDebug("2. $web.$topic trying TextPreferencesValue for $web.$diff$
!               my( $meta, $text ) =
!                  $this->{store}->readTopic( undef, $web, $differentTopic, undef );
!                  $this->{store}->readTopic( undef, $web, $differentTopic, undef );
!               $value = $this->{prefs}->getTextPreferencesValue( $key, $text, $meta, $web, $di$
! #          TWiki::Func::writeDebug("3. value = $value");
!         };
!
!         unless ($value) {
!               if ($params->{warn}) {
!                  # we could even let them write the warning message
!                  $value = "%RED%no value for %<nop>$key% on !$web.$differentTopic%ENDCOLOR%";
!               } else {
!                  $value = ''; # must be set to something
!               }
!         }
!       } else {
!         $value = $this->{prefs}->getWebPreferencesValue( $key, $web ) || '';
!       }
!         TWiki::Func::writeDebug("4. topic = $differentTopic web = $web value = $value");
!
! #     die "topic = $differentTopic web = $web key = $key value=$value";
!       return $value;
  }

-- Contributors: MartinCleaver - 05 Mar 2008

Discussion

Is it true that VAR does not fall back to the global settings if there is none defiend in the level above? ie,

%!VAR{"FAVICON" web="Codev"}% only resolves if FAVICON is actually set in Codev's WebPreferences??

• Test ==

this seems somewhat less than optimal too

-- SvenDowideit - 19 Mar 2008

Good point. That does seem contradictory to expectations.

-- MartinCleaver - 20 Mar 2008

This VAR syntax pulls in the capability http://twiki.org/cgi-bin/view/Plugins/TopicVarsPluginDev - undoubtedly the mechanisms overlap and should be merged. Further, harmonising with the search SQL syntax would be beneficial.

-- MartinCleaver - 25 Mar 2008

Changed the ProposedFor to GeorgetownRelease (5.0)

No new features will be added to patch releases. Only bugfixes.

-- KennethLavrsen - 30 Mar 2008

Martin you have raised concern against your own proposal and no progress since March.

What do you want me to do with it? Park it. Reject it? Or bring it up at next release meeting for decision?

-- KennethLavrsen - 29 May 2008

Bring up for next release meeting please.

-- MartinCleaver - 02 Jun 2008

I am OK with that.

But people need to know what detail you want people to decide.

What is the concern about? What are the alternatives?

Will you be at the next meeting yourself? At the last release meeting we were 3 people only.

-- KennethLavrsen - 02 Jun 2008

Again a meeting without the proposer. I am not going to take this serious. I am parking the proposal

-- KennethLavrsen - 10 Jun 2008

My client's intranet project is starting up again so I am back on the case.

After some discussions this proposal was accepted in principal at today's meeting.

-- MartinCleaver - 18 Aug 2008

Yes accepted at GeorgetownReleaseMeeting2008x08x18. Next step is that you create an enhancement Item on develop.twiki.org

You should only check this feature into trunk as the target release will be 5.0.

-- KennethLavrsen - 18 Aug 2008

Is there extra work beyond checking in what is presented above?

Is there a related test harness that needs to be updated?

Thanks, M.

-- MartinCleaver - 18 Aug 2008

You will make a lot of people happy if the enhancement if VAR is followed up with a couple of unit tests that verify the enhanced syntax.

If you have trouble with this I am sure both Sven and Crawford will guide you on #twiki.

-- KennethLavrsen - 18 Aug 2008

Changing to Parked. Needs developer to adopt.

-- GeorgeClark - 19 Nov 2015

Commenting is disabled while not logged in