create new tag
, view all tags

Grace Full Fallback For Plugin TWiki Variables

if you turn off all the plugins in a default install of TWiki, you see a mess on every page - lots of unexpanded TWikiVariables, like the TWISTY, and TipsContrib ones.

I'd also like to start making contribs that are optionally enhanced via other plugins - like using Javascript if you have YahooUserInterfaceContrib installed, or Popups if you have JSPopupPlugin installed.

All this would be more possible, if TWiki had a way to define a fallback for TWikiVariables that are not 'defined'

rather than saying

%IF{"installed JSPopupPlugin" then "%JSPOPUP{"%SCRIPTURL{rdiff}%%SCRIPTSUFFIX%/$WEB%/%TOPIC%?type=last"}%" else="%SCRIPTURL{rdiff}%%SCRIPTSUFFIX%/$WEB%/%TOPIC%?type=last"}%

i'd like to define a TWikiVariableFallback for JSPOPUP such that it defaults to being replaced with the 'default' parameter's content

one possiblilty is to add a Setting in the BugsContrib WebPreferences


or in the case of TWISTY


though it could be possible to just define


-- Contributors: SvenDowideit - 08 Mar 2007


I am not sure I understand the FALLBACKTODEFAULTPARAM setting.

The "fall back to empty string" is basically the spec of HTML: Any tag a user agent does not understand is ignored. Borrowing from this, we could create a global UNDEFVARIABLEFALLBACK setting with these sample settings:

  • (not set, or set to empty value) - show variable %AS_WRITTEN% (e.g. current spec.)
  • all: name - return variable name (same as above)
  • all: empty - return empty string for all undefined variables
  • all: empty, CHART: "Please install the TWiki:Plugins.ChartPlugin" - empty string for all but %CHART{}%, in which case a message is shown
  • all: empty, CHART: install - same as above; the install shows a "please install" message

-- PeterThoeny - 27 Mar 2007

Rather than creating yet another obscure TWiki variable I'd rather define a syntax to deal with this. For example,

  • Default JSPOPUP = You need to install JSPOPUP for this to work
  • Default COMMENT = CommentPlugin is not installed, sorry
  • Default TWISTYTOGGLE =
etc. I think this would allow the existing parser and preferences code to be used with minimum changes (a Default is just a Set with a flag, and getDefaultValue would mirror getPreferencesValue).

Whatever you choose to do, please make sure that it's exposed via the plugins interface so that plugins can manage the values.

-- CrawfordCurrie - 27 Mar 2007

Being able to define a default for named settings is good. However, I find the Set NAME and Local NAME already confusing enough, I am not sure if we should add yet another Default NAME syntax. And how would you set an overall default?

-- PeterThoeny - 28 Mar 2007

to be honest, while I could do with something that provides this functionality, I'm not confident enough of its merits to implement it without quite a bit of discussion.

One of the dubious side effects of the idea, is that it would create a TWikiVariable setting mechanism that would act in a 'sort of' reverse action to normal Settings.

ie, setting a default value for SVENSMYSTERY in a topic, would probably need to be over-ridden by a web wide default for SVENSMYSTERY, but then that would need to be over-ridden by any actual Set ting of SVENSMYSTERY,

still, food for thought, while we get on with the more well defined features.

-- SvenDowideit - 28 Mar 2007

I find both the "Default" and the FALLBACK syntax a bit geeky and difficult for "normal" users to ever understand.

I am sure there are better ideas to be found if we think about it for a while.

-- KennethLavrsen - 28 Mar 2007

Yes, the spec needs t be solidified.

Thinking KISS, what do we really need? From what I understand, a way to suppress undefined variables, analogous to HTML tags a browser does not understand. How about a new variable analogous to the FINALPREFERENCES variable that takes a list of variable names? Such as


-- PeterThoeny - 24 Apr 2007

Perhaps we are guilty of thinking like developers here. The reality is that most people don't need to know when a TWiki variable is undefined. As Peter says above, the "fall back to empty string" approach works fine for HTML, and would work fine for TML as well, I contend. The problem comes when I want to know where an undefined TWiki variable is used, and that's usually when I'm debugging.

So, how about a global debugging switch for TWiki? When I turn it on, I get to see all undefined variables in full technicolor. When it's off they are silently ignored. The fact that TWiki variables are macro ids means that having this mode would make it more likely that someone could define a TWiki application that breaks in debug mode.

As much as I dislike adding more TWiki variables, this might be a case for one.


An alternative approach would be to generate undefined variables as comments - <!--%UNDEFINEDVARIABLE%--> - so they can be seen in the HTML souce by the developer. Because this would always be turned on, there are fewer opportunities to define a TWiki application that breaks.

Of the two approaches, I prefer the comment approach. Don't mode me in!

-- CrawfordCurrie - 28 Sep 2007

I am in favor of the comment approach as well. But how would this work for any other ouput than html? Like e-mail, xml (rss) and so on.

-- ArthurClemens - 28 Sep 2007

That is XML comment syntax. In plain text you would see the full <!--%UNDEFINEDVARIABLE%--> - but is that such a big problem? At the moment you get %UNDEFINEDVARIABLE%. OK, so it might limit the ways you can use this, but personally I think it's an acceptable compromise.

-- CrawfordCurrie - 28 Sep 2007

ok, while i sympathise with the comment suggestion, it might be better to consider performance too. If someone makes a complex but optional TWikiApp, commenting it out, will make an output html that is much larger in size than needed.

Though we do need the debug option - sometimes it would be the only way to see why things are not as expected.

-- SvenDowideit - 28 Sep 2007

This discussion ended with people including the proposer agreeing on something pretty far from the original proposal.

The original proposal needs to be refactored before a decision can be made.

-- KennethLavrsen - 30 Mar 2008

agreed - not just refactored, but tried out. It probly would be best done with some experimental code that implements the ideas by replacing the normal TWiki::Prefs code, so we can see the consequenses of the idea (and then work out a syntax)

-- SvenDowideit - 31 Mar 2008

Without a clear spec to decide on I will park this proposal to give other proposals in the backlog more visibility.

UN-Park the proposal when you update the spec. This is not a rejection or an attempt to reject. Just to get some momentum on those proposals where developers have a spec ready and want to work on it smile many of those yours Sven.

-- KennethLavrsen - 14 Apr 2008

This parked proposal warrants revival. I like Crawford's reasoning and his first proposal of introducing an on/off switch. The HTMl comment approach as a small drawback to break HTML code if there is an undefined variable within an HML comment block (HTML comments cannot be nested.)

As Kenneth stated, the proposal at the top needs to be updated so that the 14 day clock can start again.

-- PeterThoeny - 28 May 2008

Edit | Attach | Watch | Print version | History: r18 < r17 < r16 < r15 < r14 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r18 - 2008-05-28 - PeterThoeny
  • 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-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.