I had a chat with Danny Bloemendaal about some differences in how Zope
and Chameleon understands attribute result values (in the
``tal:attributes`` statement), specifically boolean values.
In a recent change, Chameleon now does support Zope's behavior on a
set of special case attributes:
BOOLEAN_HTML_ATTRS = frozenset([
"compact", "nowrap", "ismap", "declare", "noshade", "checked",
"disabled", "readonly", "multiple", "selected", "noresize",
"defer"
])
That is, if you return ``True``, then you'll get e.g.
``selected="selected"``. If you return ``False``, then the attribute
is dropped.
Now, with any other attribute, Zope has a different behavior: it
simply turns the bool value into a string: "True" and "False",
respectively.
Chameleon drops the attribute in both cases.
The motivation is that it's convenient that ``False`` behaves like
``None`` and simply drops the attribute. There's some history in this,
because Python did not use to have a ternary operator and so this sort
of logic was usually done using boolean logic (or a ``test`` function
which has to evaluate both arguments). And adding ``or None`` behind
these statements is tedious and often forgotten.
That said, in the Zope world, people do rely on boolean values being
coerced to string values, whether bad practice or not (I think they
should explicitly coerce to integer and return 0 or 1 because it's a
cleaner input than "False" or "True").
I guess what I'm asking is: should the behavior change, or should this
be a configuration option such that Zope users can get their own
custom behavior here.
\malthe
--
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To post to this group, send email to pylons-discuss@googlegroups.com.
To unsubscribe from this group, send email to
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en.
