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)