[Zope] Using ZPT with options/radio/checkboxes

[Paul Winkler]

On Thu, Aug 07, 2003 at 06:00:05PM +0100, Chris Withers wrote:
> Paul Winkler wrote:
> >1) It's surprising - other attributes don't behave this way.
> 
> Not very. The attributes it applies to need this, and I think it only 
> happens if the content type of the ZPT is text/html. Try doing a checkbox 
> withotu this feature ;-)

hmm. OK that sounds sensible. If this is the case, and given the
omit-"nothing" behavior that I didn't know about, my whole proposal
is probably unnecessary. Whew. :-)

But when I try setting the content-type to text/xml, the tal:attributes 
are not evaluated at all!  I see the raw tal:attributes expressions 
in the output!  wha????


It does seem a bit odd that "selected" and "checked" can be omitted 
when the expression returns *any* pythonically false value, while 
other attributes only behave this way when the return value is
pythonically None (aka nothing). But i guess that's a quibble.

> >2) It's undocumented AFAICT.
> 
> Hmm... try the Zope 2.6 Book, I know I've read this documentation in the 
> language specs somewhere...

Looking again, I see that the delete-when-"nothing" behavior is 
documented, in both the Advanced Page Templates chapter and the ZPT 
reference. Hmm, I should read those again. :-) 

It's also possible to keep the value of an attribute when the
expression evaluates to "default". neat!

However, there is no mention of this special behavior for checked & 
selected - that true values are discarded and replaced with the
name of the attribute.

> >3) It's specific to XHTML and likely to be problematic when using ZPT to
> >generate other flavors of XML. I notice that this special behavior
> >is applied regardless of what tag you put these attributes in.
> 
> See note about content type above.

see weird result above :)

> >There is of course the common idiom of writing the entire tag twice with 
> >two
> >opposing "tal:condition"s, but that often leads to redundant html
> >as well as redundant tag contents.
> 
> Erg! Ug! Yuk! People do this?!

Erg ug yuk, indeed... but it was posted as a suggestion earlier in this 
very thread, and I've seen it a lot.

> ><input type="checkbox" 
> > tal:conditional_attributes="checked request/some_var | nothing" />
> 
> I suspect that will work as expected if you remove the conditional_ 
> prefix... do let me know though!

Well, it sort of does. Discarding the return value still seems icky 
to me. I guess it was considered necessary, to avoid the need for a 
python expression like so:

<input type="checkbox" checked="checked"
 tal:attributes="checked python:request.get('some_var') and default or nothing" />

But that could be avoided more cleanly if there were an "and" operator,
something like:

<input type="checkbox" checked="checked"
 tal:attributes="checked request/some_var & default | nothing" />

... but that's another proposal for another day ;-)

-- 

Paul Winkler
http://www.slinkp.com
Look! Up in the sky! It's SUPER MATHEMATICIAN OF WANKFORDSHIRE!
(random hero from isometric.spaceninja.com)