From: <Cra...@nt...> - 2005-10-30 11:17:09
|
Author: CrawfordCurrie Date: 2005-10-30 03:15:47 -0800 (Sun, 30 Oct 2005) New Revision: 7228 Modified: twiki/branches/DEVELOP/data/TWiki/DakarReleaseNotes.txt Log: Item297: clarified semantics of twiki variables Modified: twiki/branches/DEVELOP/data/TWiki/DakarReleaseNotes.txt =================================================================== --- twiki/branches/DEVELOP/data/TWiki/DakarReleaseNotes.txt 2005-10-30 11:13:42 UTC (rev 7227) +++ twiki/branches/DEVELOP/data/TWiki/DakarReleaseNotes.txt 2005-10-30 11:15:47 UTC (rev 7228) @@ -483,7 +483,7 @@ ---+++ Changes to variable parsing In earlier TWiki versions there was considerable confusion over the syntax and semantics of Preferences, TWiki Variables, and Plugin variables. The documentation suggested that all %VARIABLES% were equal, but in fact some were more equal than others. -The syntax and semantics of preferences and TWikiVariables has been made consistent. %<nop>VARIABLE% has been made semantically identical to %<nop>VARIABLE()%, so if you set a preference named %<nop>VARIABLE% it will automatically be instantiated in place of %<nop>VARIABLE{}%. This is an elegant solution in several ways: first, it allows an administrator to electively disable !TWikiVariables, simply by defining an overriding preference. Second, it rationalises the semantics in line with the common syntax. Third, it allows a single parser to do all the work, allowing localised optimisation. Fourth, it prevents a plugin from accidentally kidnapping system TWikiVariable (while this can still be done by registering a tag handler, it's a much more explicit process). Fifth, the ground rules are set for a possible future extension to support parameterised TWikiVariables e.g. +The syntax and semantics of preferences and TWikiVariables has been made consistent. %<nop>VARIABLE% has been made semantically identical to %<nop>VARIABLE()%, so if you set a preference named %<nop>VARIABLE% it will automatically be instantiated in place of %<nop>VARIABLE{}%. This is an elegant solution in several ways: first, it allows an administrator to electively disable !TWikiVariables, simply by defining an overriding preference. Second, it rationalises the semantics in line with the common syntax. Third, it allows a single parser to do all the work, allowing localised optimisation. Fourth, it prevents a plugin from accidentally kidnapping system TWikiVariables (while this can still be done by registering a tag handler, it's a much more explicit process). Fifth, the ground rules are set for a possible future extension to support parameterised TWikiVariables e.g. * Set CAR{make model accessory} = I drive %make% %model% with %accessory% in my dreams %CAR{make="an Aston Martin" model="DB9" accessory="a gorgeous blonde"}% |