Tags:
create new tag
, view all tags

TopicVarsPluginDev Discussion: Page for developer collaboration, enhancement requests, patches and improved versions on TopicVarsPlugin contributed by the TWikiCommunity.
• Please let us know what you think of this extension.
• For support, check the existing questions, or ask a new support question in the Support web!
• Please report bugs below

Feedback on the TopicVarsPlugin

This is the place to discuss (hah!) the TopicVarsPlugin.

-- TrippLilley - 15 Nov 2001

Curious! Can you tell me what was your motivation for building this? Thanks!

-- MartinCleaver - 17 Nov 2001

wow, this is great! i just started using this on two twiki-systems that i have set up. i have been using it to automate project-status lists, and can provide some usage examples, if anyone is interested.

BugReport: this seems to be very unreliable when used in conjunction with ModPerl. pages with tags referencing variables in other topics would frequently not be interpreted at all (which seemed to change every time the topic was reloaded through the view script). i had previously been using modperl, and removed it, which resulted in this plugin working again. modperl was causing many other problems with twiki in general, and i'm not entirely certain where to begin investigating this.

-- SteveMokris - 23 Nov 2001

I'd be interested in some TopicVarsPluginExamples ....

Thanks.

-- MartinCleaver - 26 Nov 2001

Bug: Uninitialized Value Messages in Apache's error_log file

I installed this plugin and it works but when one makes a query to any TWiki page this message appears eight times per consulted page:

[Tue Jan 8 11:12:10 2002] view: Use of uninitialized value at ../lib/TWiki/Plugins/TopicVarsPlugin.pm line 131.

Environment

TWiki version: 01 Dec 2001
TWiki plugins: TopicVarsPlugin
Server OS: Red Hat 6.1
Web server: 1.3.9.4
Perl version: 5.00503-6
Client OS: Any
Web Browser: Any

-- PabloChamorro - 08 Jan 2002

Copied Pablo's bug report from Codev.UninitializedValueTopicVarsPlugin

-- PeterThoeny - 08 Jan 2002

Fix

The problem was this line:

  • &TWiki::Func::writeDebug( "- TopicVarsPlugin::do_var_from_topic $_[0]: [$var]" ) if $debug;
    The value of $var was known to be potentially undefined, which led to this problem.

Immediate fix is to replace with this line:

  • if (defined $var) { &TWiki::Func::writeDebug( "- TopicVarsPlugin::do_var_from_topic $_[0]: [$var]" ) if $debug; }

If TrippLilley doesn't apply this fix before around this time next week, I'll apply the patch and re-upload the plugin...

-- MichaelSparks - 10 Jan 2002

  • ALERT! Does this fix work fine? The test here says 01 Dec 2001, but on TopicVarsPlugin, it's still 01 Sep, and the zip hasn't been reuploaded? I'm trying it now. -- MikeMannix - 16 May 2002

This remains broken as of May 2003 in the version intended for distribution over on TopicVarsPlugin -- PaulReiber


Overriding - Precedence/Security

Its too bad this plugin doesnt allow overriding of variables from WebPreferences or TWikiPreferences (just for the current topic). Im sure it was due to some type of security precaution.

I was planning to attempt to use this plugin to allow me to modify the contents of HTTP_EQUIV_ON_VIEW for the WebSidebarIE so that I could have a mini page that automatically refreshed every 5 minutes. Oh well...

-- JohnCavanaugh - 15 Mar 2002

I am having a problem using a topic var in a %SEARCH{ "%VAR_NAME%"}% expression. Normal wiki variables work fine, but topic variables don't seem to get evaluated at the correct time to be used.

Has anyone else had problems with this?

-- AllenBierbaum - 29 May 2002

Yes. I have this problem. Here is simple example:

<!--
   * Set NAME = amd
-->

   * Click [[http://intranet.infodev.ca/twiki/bin/search/Transit/?regex=on&search=%5B.%5D*ProjectPerson%22+value%3D%22.*%28%NAME%%29.*%22%3B][here]] for all other Transit results.

%NAME%

The variable NAME is set properly because I can see it in the generated page, however it is'nt used in the search.

-- AlainMivilleDeChene - 24 Oct 2003


mod_perl support

I've made a few patches (attached) which make things work better in mod_perl. They introduce a bit of inefficiency, because a Preview'd topic should be handled different than one that's being stored, but I don't know how to determine when the code is in preview mode.

-- DiabJerius - 28 Jun 2002

I've made some further cleanups and have attached a distribution (TopicVarsPlugin_DJ1.zip)

-- DiabJerius - 06 Aug 2002

Does this fix the problem of the wiki spawning an infinite number (or until linux runs out of memory and just kills them) of processes to search for variables elsewhere? I should have reported the problem earlier, but our mod-perl enabled wiki literally crashed the webserver with this plugin installed. Unfortunately, we've seen decent speed improvements for almost everything we run using mod-perl, so simply turning it off for one plugin wasn't worth it.

If not, and someone would like to help me troubleshoot it, I'd be willing to poke around to get it fixed.

-- MikeMaurer - 07 Aug '02

I haven't seen that sort of behavior (on Solaris 2.8, Apache 1.3.26). We don't have a very heavily used wiki; maybe this happens with concurrent accesses?

-- DiabJerius - 15 Aug 2002

Beware

The aforementioned mod_perl DJ1.zip demonstrates a strange bug, where you lose the ability to use Site or Topic scoping. I was able to repair by patching getVarsFromTopic:
  • $topic = $_[1];
And the subsequent replacements where ever used.

I'm not using a mod_perl installation, so that may be the cause. So, if you are thinking about using this module, be sure to use the original, if you don't need the mod_perl behavior, as it works correctly in this respect.

-- KevinAthey - 15 Aug 2002

Oh the joys of Perl. It seems that the regexp backreference variables ($1, $2, etc) are dynamically scoped. Here's an example of the bizarre behavior that this leads to:


"foo" =~ /(.*)/;
b($1);

sub b
{ 
  print "$_[0]\n";
  "snack" =~ /(.*)/;
  print "$_[0]\n";
}

And the resulting output:

foo
snack

The attached distribution should fix this. TopicVarsPlugin_DJ2.zip

-- DiabJerius - 10 Jan 2003


I'm Not Dead Yet.

I'm back to using TWiki, at least for a while, and it's somewhat likely I'll even be using my own plugin smile That said, I'll try to make some time to review the various patches and fixes presented here and make a new distribution. I don't guarantee any time frame for this, nor even that it will happen, but I thought I'd at least let you know I'm alive and such.

As for some questions and speculation above about my motivations for certain decisions, I warn you not to ascribe to me more expertise than I had when I wrote this smile I wasn't familiar enough with TWiki and the TWiki codebase to have made decisions on any basis other than "is the value showing up on my page now?". Sorry to dissapoint frown

And to finally respond to MartinCleaver's repeated, patient requests for motivation, examples, etc., I offer some small insight.

I had two prime motivators: cosmetic shorthands and value shorthands.

Cosmetic Shorthands

Cosmetic shorthands are just a quick way for me to create shorthand text in one topic that I can include from other topics without worrying about the current value of the shorthand. That is, I wanted to be able to create a topic for a client, for instance, and in that topic provide background, contact info, etc., as well as variables that could be used from other topics to refer to that client and their info. So, for instance, the topic Clients.FooBar would contain a var called FullName with their full name (e.g., "The FooBar Corporation"), and maybe Abbv with short form of their name (e.g., "FooBar").

Then, in my other topics, I could easily inline the "canonical" name / location / etc. for FooBar with a call like %Clients.FooBar.FullName%.

Because the variables' right-hand sides can contain normal TWiki shorthand that gets expanded after shorthand expansion, it was pretty easy to set vars that contained, for instance, double-bracket topic references (e.g., * Set FullName = [[Clients.FooBar][The FooBar Corporation]]).

Value Shorthands

Using the same mechanism, but a different motivation, I wanted to be able to create variables that I could call from other topics for other-than-cosmetic reasons, like summarization, grouping, math, etc.

For instance, using the TopicVarsPlugin, I created a crude task estimation system in which I create a topic for each task wherein I set information about the task:


&lt;!--
      * Set NAME = Database Migration
      * Set LINK = [[Database Migration]]
      * Set DESCRIPTION = Migrate existing data from Monkey 1 database to Monkey 2
      * Set HOURS = 12
      * Set STATUS = __COMPLETE__
--&gt;

(yes, those comment bits are in the actual source of the topic)

And then underneath these declarations I present a nicely formatted copy of them, along with the more verbose explanation of the task, discussion space, etc.:

| *Name* | %NAME% |
| *Description* | %DESCRIPTION% |
| *Hours* | %HOURS% |
| *Status* | %STATUS% |

This is a fairly straightforward migration of the data in the existing
Monkey 1 database to the Monkey 2 / MiddleKit object store. This
should be a simple matter of some queries, and perhaps some code to
decompose or recompose data to match the new object model.

Then, on another page that summarizes all of my tasks, I created a table like the following that just extracts the variables from the pages, so the only time I touch this page is to add a new task. I wanted to write code to automatically mine the task topics and generate this page, too, so all I would need to do is create a new task, but I never got around to it smile

| *Hours* | *Task Name* | *Status* | *Description* |
| %PublishingRequirements.HOURS% | %PublishingRequirements.LINK% | %PublishingRequirements.STATUS% | %PublishingRequirements.DESCRIPTION% |
| %DatabaseMigration.HOURS% | %DatabaseMigration.LINK% | %DatabaseMigration.STATUS% | %DatabaseMigration.DESCRIPTION% |
|  *%[ PublishingRequirements.HOURS + DatabaseMigration.HOURS ]%*  | *Total* |||

(BTW: yes, I realize that math at the bottom is hideously manual, but I never got around to figuring out why I couldn't get TopicVarsPlugin and SpreadSheetPlugin to play together).

-- TrippLilley - 23 Jul 2003

When you say they don't work together, do you mean just within the tables, or if both are installed on a particulat TWiki system? I would really like to use the TopicVarsPlugin, but when I installed it, it kiiled TWiki stone dead - we got UNDEFINED for every topic we tried to view. I think this is coming out of the .pm file as a return. Are we missing a simple setting?

-- ChrisHogan - 29 Jul 2003

I mean that I couldn't set up a column of vars in a table, and then use the spreadsheet plugin to tally the resolved values of those vars. I know this is an artifact of the rendering / plugin resolution order, I just haven't dug deeply enough to figure out how to exert control over that and make sure TopicVarsPlugin runs before SpreadSheetPlugin.

BTW, I've uploaded a new version of the plugin that fixes the UNDEFINED / DEBUG error, finally.

-- TrippLilley - 06 Aug 2003

When you say they don't work together, do you mean just within the tables, or if both are installed on a particulat TWiki system? I would really like to use the TopicVarsPlugin, but when I installed it, it kiiled TWiki stone dead - we got UNDEFINED for every topic we tried to view. I think this is coming out of the .pm file as a return. Are we missing a simple setting?

-- ChrisHogan - 28 Jul 2003

If I set DEBUG to 0, it works? I must be missing something...

-- ChrisHogan - 29 Jul 2003


Okay, I've fixed the UNDEFINED bug described above. It now works both with and without DEBUG turned on. I've also changed the default DEBUG setting to off (0), and (hopefully) fixed the DOS-style line-endings issue with TopicVarsPlugin.txt.

-- TrippLilley - 06 Aug 2003


I'm going off topic now, sorry. But I have a question about that math you use and complain about. Is this normal TWiki behaviour or does TopicVarsPlugin provide that functionality? For a skin I'm currently creating I need to do some calculation (basically add/subtract) with preference variables () and template variables (%TMPL:P{"var"}%). Maybe someone can give me a hint on how to do that? The syntax used above doesn't work for me.

-- ThomasJachmann - 30 Jul 2003

I'm not certain this is the case, but I think I've narrowed it down. It seems that the older version of TWiki against which I originally wrote TopicVarsPlugin supported a crude variable math whereby the syntax %[ VARA + VARB + VARC ]% would expand into %VARA% %VARB% %VARC%, which TopicVarsPlugin could trap and expand, and then have the math applied by something else (presumably within TWiki).

I just did a test against my old 01 Sep 2001 installation (which has SpreadSheetPlugin installed, whereas my 01 Feb 2003 release does not, so maybe this is it), and the syntax above works both inside of and outside of table cells. I'll look into this a little more when I get a chance, since it's pretty fundamental to how I use TopicVarsPlugin, and I want to upgrade all of my TWikis to 01 Feb 2003 smile

-- TrippLilley - 06 Aug 2003

This plugin seems to be unstable on my twiki site. Refreshing a page causes variables on it to toggle between showing the value and the unresolved variable. This doesn't happen on the TopicVarsPlugin page, but other pages I've created in different webs. With the 15 Nov 2001 version it did the same thing except it would sometimes show the value of the variable from a previous revision.

-- SamHasler - 16 Sep 2003

I think it could be the same problem I have. I narrowed it to how the topic is named. If it is a non-WikiWord, the variable doesn't get resolved. If it is, it does. For Example %ETS2.VARIABLE% will not work. I have to call the topic EtS2 (for example) to get %EtS2.VARIABLE% to work.

I think the offending lines in the code are:

 $_[0] =~ s/%([A-Z]+[a-z]+[A-Z]+[A-Za-z0-9]*)\.([A-Za-z0-9_]+)%/&do_var_from_web($1, $2, $_[2])/geo;

    ## Handle fully-qualified var references (will look at webs/topics on this wiki)
    $_[0] =~ s/%([A-Z][^%]*)\.([A-Z]+[a-z]+[A-Z]+[A-Za-z0-9_]*)\.([a-zA-Z0-9_]+)%/&do_var_from_wiki($1, $2, $3)/geo;

so I changed them to:

## Handle topic-qualified var references (will look at topics on this web)
$_[0] =~ s/%([A-Z]+[A-Za-z0-9\-]*)\.([A-Za-z0-9_]+)%/&do_var_from_web($1, $2)/geo;

## Handle fully-qualified var references (will look at webs/topics on this wiki)
$_[0] =~ s/%([A-Z][^%]*)\.([A-Z]+[A-Za-z0-9_\-]*)\.([a-zA-Z0-9_]+)%/&do_var_from_wiki($1, $2, $3)/geo;

and it works fine, however, maybe I introduced an overgeneralization which will break something else. Notice that these lines don't search for the same thing. One of them has an underscore, and the other does not. Why? Omission? Purpose?

-- AlainMivilleDeChene - 11 Oct 2003

The SpreadSheetPlugin has now $SET() and $GET() funtions that offer similar functionality to the TopicVarsPlugin. It does not work across topics however (unless you INCLUDE another topic)

-- PeterThoeny - 25 Oct 2003

Why can't this plugin override a variable set in WebPreferences? This is a great miss. Is this indeed a TWiki precaution or can this plugin be improved?

-- ArthurClemens - 11 Jan 2004

That would be a security hole. For example, if ALLOWWEBMANAGE could be overridden, anyone could create a new web. A better approach is the enhance TWiki to scan also for preferences settings in topics. The implementation is very easy, more a question (and tests) if the performance is OK.

-- PeterThoeny - 12 Jan 2004

Does this allow for preferences set in WebPreferences to be overridden, or should preferences settings in topics have a new (unique) name?

-- ArthurClemens - 12 Jan 2004

Surely it just needs to obey FINALPREFERENCES correctly. Was this deliberatly not done for security reasons or is it implicitly not possible to overide WebPreferences or TWikiPreferences in a Plugin?

-- SamHasler - 12 Jan 2004

On a completely separate topic, I have run into a situation where the following is being done and TopicVarsPlugin breaks something. Given the following: (BTW, the actual date string comes from a topic template using %DATE%)

<!-- Calculate only the year based on when this topic was created
   %<nop>CALC{"$SET(YEAR, $REPLACE(09 Feb 2004, 1, $EVAL($LENGTH(09 Feb 2004)-4),) )"}%
-->

This creates a perfectly fine href:

<a href="#" onClick="var doc-year = window.open('http://www.x.y.com/go/doc-year-2004','doc-year','toolbar=yes,status=yes,
menubar=yes,scrollbars=yes,resizable=yes,directories=no,location=yes,width=640,height=480'); doc-year.focus(); 
return false;">Doc Details</a>

However, if we try loading the above into a variable then recalling it:

   * DOCVAR = <a href="#" onClick="var doc-year = window.open('http://www.x.y.com/go/doc-year-%CALC{"$GET(YEAR)"}%',
'doc-year','toolbar=yes,status=yes, menubar=yes,scrollbars=yes,resizable=yes,directories=no,
location=yes,width=640,height=480'); doc-year.focus(); return false;">Doc Details</a>

%DOCVAR%

we get a munged up link reference when we recall the variable. The actual HTML results look like:

<a href="#" onClick="var doc-year = window.open('http://www.x.y.com/go/doc-year-%CALC{"$GET(YEAR)}%','doc-year',
'toolbar=yes,status=yes, menubar=yes,scrollbars=yes,resizable=yes,directories=no,location=yes,width=640,
height=480'); doc-year.focus(); return false;>Doc Details</a>

Note that the double quotes got removed or sucked up by TopicVarsPlugin and the result is a bad URL. Why push a URl into a variable? Well, it makes for better reading when a short variable name is part of a table rather than having that long monster of a URL link embedded in the table.

Any idea what is going on?

Thanks

-- SteveRJones - 09 Feb 2004

Anyone know: Can this be used to provide access to a metadata variable? Is there another way to do that?

-- MartinCleaver - 24 Mar 2004

I can only make this work in Cairo if I turn off SpeedyCGI. Which means in practical that I cannot use it at all since I want the SpeedyCGI to be enabled for performance reasons. Actually - it partly works with ModPerl but Twiki fails severely with ModPerl.

-- KennethLavrsen - 04 Sep 2004

More info. I get these in hundreds in my Apache error log.

... view: Use of uninitialized value in substitution (s///) at ../lib/TWiki/Plugins/TopicVarsPlugin.pm line 70., referer: http://www.lavrsen.dk/twiki/bin/view/TWiki/WebHome

... view: Use of uninitialized value in substitution (s///) at ../lib/TWiki/Plugins/TopicVarsPlugin.pm line 74., referer: http://www.lavrsen.dk/twiki/bin/view/TWiki/WebHome

-- KennethLavrsen - 05 Sep 2004

The errors go away if you put a check around lines 70 and 74:

   if (defined $string) { 
      while ( $string =~ s/([a-z]\w+)\s*=\s*\"([^\"]*)\"//io ) {
         $TWiki::cgiQuery->param( $1, $2);
      }
        # name=value pairs
      while ( $string =~ s/([a-z]\w+)\s*=\s*([^\s,\}]*)//io ) {
         $TWiki::cgiQuery->param( $1, $2);
      }
   }

-- ArthurClemens - 24 Sep 2004

Damn. I just withdrew that last revision because I saw the errors listed on PluginsBenchmarkResults. However, I am tempted to leave the revision undone, because the MacrosPlugin duplicates the functionality I was looking for. Feel free to roll it forward, as long as you re-release it next time :).

-- MartinCleaver - 23 Nov 2004

I can't get this plugin to work with the DEVELOP branch.

-- ArthurClemens - 14 Jul 2005

Wouldn't it make sense to have its functionality in Core?

-- FranzJosefSilli - 14 Jul 2005

I say YES!

I've been looking at other plugins to provide me with this functionality, but couldn't find any. In my case it is essential for creating TWiki web applications.

-- ArthurClemens - 14 Jul 2005

added http://twiki.org/p/pub/Plugins/TopicVarsPlugin/TopicVarsPlugin-20030806-1559.zip to CVS

-- WillNorris - 19 Jul 2005

Has anyone noticed that http://twiki.org/cgi-bin/view/Plugins/TopicVarsPlugin does not match what is in the .zip distribution file? Is this a result of Martin's withdrawal of the update?

-- SteveRJones - 23 Jan 2006

FYI: This plugin now works with TWiki4.0.

-- ArthurClemens - 23 Jan 2006

Arthur, what was changed to make this plugin work? The version that was checked into SVN is very old with none of the patches included in this topic are part of the .zip.

-- SteveRJones - 01 Feb 2006

The zip file attached to the Plugin topic should be renamed to TopicVarsPlugin.zip (without timestamp in name.)

-- PeterThoeny - 08 Feb 2006

To the Plugin maintainer: The zip file attached to the Plugin topic does not work in TWiki 4.0 (as reported in Support.TopicVarsPlugin); the version in SVN seems to work but is based on an old code. Please consider upgrading this Plugin so that it runs on Cairo and Dakar codebase. HandlingCairoDakarPluginDifferences has more.

-- PeterThoeny - 15 May 2006

About a year ago I've contacted Tripp if he could update his plugin. I had the impression that he did have a look at it, but that's about it unfortunately. I don't think we are going to hear any more.

-- ArthurClemens - 15 May 2006

Based on SVN version (10217) I've changed calls to cgi, some patterns and call TWiki::Store::readTopic to TWiki::Func::readTopic inside sub getVarsFromTopic. It seems to working well, but I am not experienced Perl programmer, so please test it intensively. See attached TopicVarsPlugin.JLO arch.

-- JacekLo - 16 May 2006

We changed our TWiki from Cairo to Dakar. I can't seem to get TopicVars to work with the web specification. See below

Test if the plugin is correctly installed: 
Set THE_ANSWER = 42 
You should see the answer here: [42] (%THE_ANSWER%) 
and here: [42] (%TopicVarsPlugin.THE_ANSWER%) 
and here: [%TWiki.TopicVarsPlugin.THE_ANSWER%] (%TWiki.TopicVarsPlugin.THE_ANSWER%) 
And now with parameters 
Set THE_PARAMETERISED_ANSWER = I like 
Here: [I like Jelly] (%TopicVarsPlugin.THE_ANSWER{parameter="Jelly"}%) 
and here: [%TWiki.TopicVarsPlugin.THE_PARAMETERISED_ANSWER{parameter="Jelly"}%] (%TWiki.TopicVarsPlugin.THE_ANSWER{parameter="Jelly"}%) 

-- AlainMivilleDeChene - 09 Jul 2006

Looking at the differences between the zip file on the main page and the latest one here, there are a few differences (other than lots of debugging statements):

  1. A new function, putNameValuePairsIntoCgiparams. This function requires the if (defined $string) fix listed above in ArthurClemens - 24 Sep 2004
  2. getVarsFromTopic used to require that the variable be on a line by itself, with an opening tab:
    ^\t+\*\sSet
     
    Now it only requires * Set anywhere in the line:
    \*\sSet
     
  3. commonTagsHandler allows variables to have {stuff} in them.

One question: In Dakar, there doesn't appear to be any equivalent of $TWiki::SecurityFilter, but this doesn't seem to be discussed anywhere that I can find.

-- DougClaar - 07 Dec 2006

After a conversation with a potential client this morning, I am increasingly of the opinion that this plugin is the long way around of making MakingVarVARTopicCapable

-- MartinCleaver - 25 Mar 2008

Topic attachments
I Attachment History Action Size Date Who Comment
Unknown file formatpatch TopicVarsPlugin.patch r1 manage 3.6 K 2002-06-28 - 15:57 DiabJerius better mod_perl support
Compressed Zip archivezip TopicVarsPlugin_DJ1.zip r1 manage 4.2 K 2002-08-06 - 21:34 DiabJerius Even Better mod_perl support
Compressed Zip archivezip TopicVarsPlugin_DJ2.zip r1 manage 5.2 K 2003-01-10 - 00:48 DiabJerius Fix Web/Topic scoping issues
Compressed Zip archivezip TopicVarsPlugin_JLO.zip r1 manage 4.6 K 2006-05-16 - 10:07 JacekLo Some 4.0.2 fixes
Edit | Attach | Watch | Print version | History: r60 < r59 < r58 < r57 < r56 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r60 - 2008-03-25 - MartinCleaver
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.