[ZPT] tal:define limitations

Sun Oct 19 00:47:59 EDT 2003

On Saturday, October 18, 2003, at 05:31 PM, Michael Bernstein wrote:
> (Reposted from main zope at zope.org list)
>
> I just stumbled across the fact that variables that are defined via 
> tal:define apparently must conform to Python identifier conventions 
> (must start with a letter or underscore, etc.). This doesn't seem to 
> be mentioned anywhere in the documentation.
>
> However, URL arguments and form field names are not subject to the 
> same limitations at all, which leaves me with no simple way to define 
> default values in TAL for optional URL arguments or form fields that 
> use a number as the identifier for a name/value pair.
>
> Example:
>
> http://example.com/sample?1=off
>
> I would like the following code to work:
>
> <html tal:define="1 request/1 | string:on">
>
> This should have the effect of defaulting the argument to 'on' within 
> the context of the page when the URL is http://example.com/sample but 
> allowing it to be overridden via the URL parameter 1=off.

While it may seem more conceptually simple to have a variable with the 
name "1", it's not really necessary.  Since variable names are used 
only inside the scope of the page, they don't really have to conform to 
any external conventions (like URL parameters might have to).  There's 
nothing keeping you from using "one" instead of "1" here 
(tal:define="one request/1 | string:on") -- the only problem is the 
disconnect of the URL parameter and the local variable.  This is only a 
conceptual limitation -- there is no functional limitation.

You also have to understand that request/1 is really equivalent to 
request['1'] -- '1' is a valid string, but it's not a valid identifier. 
  You can't use request.1 (technically you can set attribute that aren't 
valid Python identifiers, but that's ugly).  That's not too big a deal, 
but in the top-level scope you *only* have variable access.  You can't 
use "python: ['1']".  Maybe ZPT already has a variable like DTML's "_", 
but I haven't seen it documented, and I'd rather not see it used -- 
without such a variable you couldn't access your '1' variable in a 
Python expression.

--
Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org