create new tag
, view all tags
In Cairo we have several different "kinds" of variable:
  • Hard-coded TWiki Variables
  • User defined TWiki Variables
  • Sets that look like TWiki Variables but aren't (protections)
  • URL parameters

Dakar makes this better by making the syntax consistent for all the TWiki variables, but also worse by adding

  • %INCLUDE parameters

We badly need a consistent syntax for referring to these beasties. %URLPARAM is the best template for the job, but it suffers from a hopeless name; it clearly can't be used to refer to anything that is not a URL param.

What we need is a way to refer to variables consistently and cleanly. The proposal is based on %URLPARAM:

%GET{"name" default="value"}%
The scoping/precedence rules need to be clearly defined:
  1. Hard-coded
  2. INCLUDE variable
  3. URL parameter
  4. Local Set (within the topic)
  5. Web Set
  6. Global Set

The %GET syntax should be optional, and only required where a default needs to be specified. The standard % syntax should work for URL params as well.

We should deprecate %URLPARAM and replace it with %GET.

So, examples:

%X% will be one
   * Set Y = 99
%Y% will be still be 2

... %INCLUDE{"Sandbox.MyTopic" X="1" Y="2"}%
will behave the same

-- CrawfordCurrie, SvenDowideit - 24 Aug 2005

What about making syntax orthogonal: and ?

-- MichaelDaum - 24 Aug 2005

I like the idea of handling parameters orthogonally, this is useful. What is the benefit of searching all internal and Set variables besides URL params and INCLUDE params? It seems like the default="%SOMEVAR%" gives enough control. Assuming the new variable just handles URL params and INCLUDE params it might be better to give it a more descriptive name, such as GETPARAM. KISS is one item in the TWikiMission.

But, kill URLPARAM? I would like to see more focus on the TWikiMission, specifically "Protect corporate investment (topic contents) from data corruption and incompatible changes". The URLPARAM should never be deprecated (for later retirement), or we break almost all TWiki applications out there! From the book interviews we have seen that there are many large corporations who have a huge investment in TWiki, we cannot ignore existing customers.

The two variables can coexist nicely. URLPARAM is probably also faster than GETPARAM.

-- PeterThoeny - 24 Aug 2005

FWIW %GET and %SET make a lot of sense to me too.

-- TravisBarker - 25 Aug 2005

This feature is being proposed precisely because default="%SOMEVAR%" does not give enough control.

The benefit is rationalisation of all the different variable types; a single syntax to recover all types of variable. This makes it easier for the end user (consistent syntax and semantics; variables are variables; not url params versus twikivariables versus include params, each with a different syntax).

The main use is macro topics - e.g.

                     default="| $topic | $formield(%GET{"field" default="none"}%)"
can be used either by ...view/Web/TrivialExample?field=Name&format=$topic or by %INCLUDE{"TrivialExample" field="Name" format="$topic"}% or by %INCLUDE{"TrivialExample"}% (picking up defaults from TWiki variables). There is no way to do this otherwise.

Nobody is suggesting disabling URLPARAM, just deprecating it.

  • But the choice of the topic name is dubious. -- ArthurClemens - 25 Aug 2005
Deprecation means a feature continues to work, though is not documented and therefore not recommended for use. Eventually when enough time has passed, it can be removed. Deprecation is a critical process; without it, systems become mired in accumulated mistakes. Feature lifetimes can be ended in several ways, including scripts to upgrade content (in the case of URLPARAM -> GET this would be a trivial script).

It is much better to provide the means for users to upgrade content, than to try to continue to support outmoded or redundant syntax that simply erodes performance. Peter, you have done this several times yourself, often without a deprecation step.

As for relative efficiency of %GET and %URLPARAM, it's irrelevant. The cost is not in looking up the variable tables (one hash reference), but in building them - and that has to be done anyway.

%SET is fine, but what is the scope of the SET? If it is the same as the equivalent

   * Set =
then why not just use the existing syntax (however horrible it may be!)
OK, having said all that, there is another approach, more attractive in many ways, and that is:
  1. Allow URL params to be recovered using the %% syntax
  2. Add an %IF statement
                    then="| $topic |%IF{"field"
                                        then=" $formfield(%field%) |"
which is more general, cleaner and simpler in many ways. The boolean in the IF statement would have to behave exactly like a perl if statement. If we add context constants into the set of variables, then it can replace %IFCONTEXT as well.

-- CrawfordCurrie - 25 Aug 2005

Hm, how can IF ever behave exactly like a perl if statement when tags are evaluated from inside to outside? Add some %SET inside and your head will spin, no matter what the semantics of %SET would have (similar to * Set, or like in the MacrosPlugin).

-- MichaelDaum - 25 Aug 2005

Peter's reminder about the TWikiMission's statement to 'Protect corporate investment (topic contents) from data corruption and incompatible changes' brings up some interesting thoughts for me....

  • if corporations are really worried about the TWiki language changing (and most proposals to do so are for good reason), maybe they can work on writing and publishing migration tools (open source is based on writing what you need after all) (for example, the work i did on the UpgradeTWiki script was paid for by my workplace, as it made the job i had to do easier..)
  • I don't actually think that dissallowing the evolution (and that means deprecating some things) for TWikiMission reasons is valid, as that is only going to lead to the stagnation of TWiki, and the creation of a TWiki++ (which so far i've worked hard against)

back to the topic ??

-- SvenDowideit - 25 Aug 2005

Michael, as usual you are thinking more clearly than me. That's exactly the reason I did the %TMPL:INCLUDE conditional the way I did.

Of course it can't behave like a perl if. At best it can only behave like a cpp ifdef.

Any suggestions for how to make the semantics simpler would be most welcome.

-- CrawfordCurrie - 25 Aug 2005

Edit | Attach | Watch | Print version | History: r10 < r9 < r8 < r7 < r6 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r10 - 2005-08-25 - ArthurClemens
  • 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.