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
- 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:
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
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
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
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:
<!--
* 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__
-->
(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
| *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
--
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):
- A new function, putNameValuePairsIntoCgiparams. This function requires the
if (defined $string)
fix listed above in ArthurClemens - 24 Sep 2004
- 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
- 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