IMHO a url parameter is just a transitory preference definition. I cannot see the rationale for %URLPARAM - it looks like something that was added as a quick hack. To my mind, saying ?fred=blah should define the preference variable %fred% for the duration of the request. At the same time, the arcane support for default values for URL params should be extended to TWiki variables, so that you can say %MYVAR{default="a value"}% (or %fred{default="a value"}% which should be synonymous with %URLPARAM{"fred" default="a value"}%.

Counter-arguments?

-- CrawfordCurrie - 09 Nov 2005

What happens if I have defined a local TWiki variable of the same name? Which value will be taken during view?

This proposal definitely would make some TWikiApplications more -- transparent, consistent, ... searching for the right term.

-- FranzJosefSilli - 09 Nov 2005

no counter argument from me - I want to see only one type of variable, the distinctions and different evaluation paths make me sad

-- SvenDowideit - 09 Nov 2005

The value taken during view should be the closest enclosing scope. The request is the narrowest possible scope, so values in the request should always override those defined in preferences (exception: ALLOWTOPICCHANGE which SHOULD NOT BE A PREFERENCES)

-- CrawfordCurrie - 09 Nov 2005

I've said it before and I'll say it again, access control "settings" are not preferences. View them being so as a quick kludge to get TWiki up and running that we are now stuck with.

Access control should be out-of-band. Look at any other system such as your file ssytem. The access control is not part of the file content.

-- AntonAylward - 09 Nov 2005