[ZPT] tal:define limitations

Sun Oct 19 01:31:05 EDT 2003

Ian Bicking wrote:

> 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.
>>
>> [snip]
>>
>> 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.

Well, in my application, the form field names, URL parameters, 
Properties, ZCatalog indexes, and ZCatalog metadata columns, are all 
generated automatically from an object that synchronizes and manages 
them all to customize the application. It was most convenient to use an 
incrementing integer (stringified) to name the various fields/etc. as 
they are added to the application.

So it *is* important that the URL parameter and the internal variable 
match, because the internal variable is passed implicitly to the 
ZCatalog search.

> 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.

Hmm. This is a good argument against using an incrementing integer to 
name the associated field/property/index/etc. I'll have to think on this 
some more.

Thanks,

- Michael