My system now has locked pages, which means I can and do lock Web and Site preference pages (as it could be when group permissions appear). However, if someone wants to make a new variable, they have no way to set the default except in their own personal preferences.
To remedy this, I propose extending the variable syntax so it includes an optional colon followed by a default color:
%COLOR:Blue%
This is easy to do in
handleCommonTags (in
wiki.pm ). Right after the check for existing preferences (and before the tests for fixed tag names) I put:
$text =~ s/%[^:\s]+:([^%\s]+)%/\1/go;
I had originally thought to modify
getPrefsValue but it doesn't look like anyone calls that with user input -- it is always with something the program wants to look up. Still easy enough to do, although not strictly necessary:
sub getPrefsValue
{
my ( $theKey ) = @_;
my $x;
my $theDefault;
( $theKey, $theDefault )= ($theKey =~ /([^:]+):?(.*)/);
for( $x = 0; $x < @prefsKeys; $x++ ) {
if( $prefsKeys[$x] eq $theKey ) {
return $prefsValues[$x];
}
}
return $theDefault;
}
Note white space is not allowed in the variable name, but it is in the default.
NOT COMPLETELY TESTED
Well, I see at least one place where this is breaking:
<A HREF="%SCRIPTURLPATH%/search%SCRIPTSUFFIX%/%WEB%/?scope=topic®ex=on&search=.*">
Topic index</A>: List up all
%WIKITOOLNAME%.%WEB% topics in alphabetical order.
This is mismatching. No time to figure it out now, but should be easy enough. Looks like the last % in WEB is matching with the colon after the link. Probably should just move my expression down below all matches so it has the lowest priority.
--
AlWilliams - 22 Sep 2000
Seems to be OK if you move it to the end. I wonder if I should have made the matching stingy...
$text =~ s/%[^:\s]+?:([^%\s]+?)%/\1/go;
My Perl is pretty rusty, so I'll leave it to you experts if that's better or worse (it is -- at least -- untested). Seems like as long as it can't match the % or : it will be stingy anyway?
--
AlWilliams - 22 Sep 2000