• Do not register here on develop.twiki.org, login with your twiki.org account.
• Use View topic Item7848 for generic doc work for TWiki-6.1.1. Use View topic Item7851 for doc work on extensions that are not part of a release. More... Close
• Anything you create or change in standard webs (Main, TWiki, Sandbox etc) will be automatically reverted on every SVN update.
Does this site look broken?. Use the LitterTray web for test cases.

See SitePermissions

-- PTh

Actually it was being expanded; but the vars in question were undefined, which is handled by printing the var name and parameters. I changed %VAR to return '' if the variable is undef.

SVN 7578


Oh, thanks Crawford. Sorry for the false alarm.

-- PTh

Crawford, I just saw the change notification. Not sure I uderstand the change, but it looks like VAR returns an empty value if a preferences value is not defined. Please note that this is a spec change that might break existing applications.

-- PTh

I've had apps break because it didn't. Thanks, CC, i'll take this!

-- AJA

Puzzled. How is it possible to "break" an application that you are creating in the first place? I create & debug an application until it does what I need. What I would like to avoid is an upgrade of the system that breaks my existing applications.

An %UNDEFINEDVARIABLE% is rendered as %UNDEFINEDVARIABLE% if used directly. Returning an empty string if querying the variable via %VAR is not consistent and might break existing apps.

Gosh, I sound like a broken record...

-- PTh

Now I'm confused; "Returning an empty string if querying the variable via %VAR is not consistent and might break existing apps." sounds like you think that %VAR should return undef, in which case the rendering code will render it as %VAR...%. No, that can't be right, that was the original report.

To be clear: it wasn't a false alarm, %VAR rendered an undefined variable using the null string in Cairo. I changed the Dakar behaviour to match that. I can't see what's wrong with that.


Clarification on consistency:

  1. Existing variable, such as WEBGBCOLOR
    • gets resolved when called directly as %WEBGBCOLOR%
    • gets resolved when called indirectly as ==
  2. Non-existing variable, such as FOOBARXYZ
    • gets rendered as %FOOBARXYZ% (e.g. left alone) when called directly as %FOOBARXYZ%
    • gets rendered as an empty string when called indirectly as ==

Test cases:

  1. Existing variable WEBGBCOLOR
    • directly as WEBBGCOLOR: "#D2D2FF"
    • indirectly as VAR{ "WEBBGCOLOR" web="Bugs" }: "#D2D2FF"
  2. Non-existing variable FOOBARXYZ
    • directly as FOOBARXYZ: "%FOOBARXYZ%"
    • indirectly as VAR{ "FOOBARXYZ" web="Bugs" }: ""

The empty string is not consistent with the %FOOBARXYZ% rendering. This is the behaviour of Cairo and now also Dakar since 7578. That is, it behaves the same (no compatibility issue), but is not consistent. I can live with that.

-- PTh

Summary %VAR not expanded in %SEARCH
ReportedBy PeterThoeny

SVN Range

AppliesTo Engine

Priority Normal
CurrentState Closed

Checkins 7578
Edit | Attach | Watch | Print version | History: r11 < r10 < r9 < r8 < r7 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r11 - 2006-01-03 - PeterThoeny
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback