Currently, if an attribute expression evaluates to any value that's boolean False, it's omitted (e.g. 0, "", object()). I think that's unexpected. Instead, attributes should only be omitted when the expression evaluates to ``None``. How do folks feel about changing this behavior in ``zope.pagetemplate``. \malthe
On Tue, Mar 10, 2009 at 9:08 AM, Malthe Borch <mborch@gmail.com> wrote:
How do folks feel about changing this behavior in ``zope.pagetemplate``.
The change would need to be in zope.tal. I'm ambivalent; while it makes sense to me in isolation, the affect on existing templates is undesirable, and compatibility is a huge deal for this bit of machinery. -Fred -- Fred L. Drake, Jr. <fdrake at gmail.com> "Chaos is the score upon which reality is written." --Henry Miller
2009/3/10 Fred Drake <fdrake@gmail.com>:
The change would need to be in zope.tal.
True.
I'm ambivalent; while it makes sense to me in isolation, the affect on existing templates is undesirable, and compatibility is a huge deal for this bit of machinery.
I agree, but it would be interesting to gauge the usage of this functionality (e.g. if everyone could put a breakpoint in the right place, run their apps and check). Actually, I think this is a bug; why would the empty string not be printed? If we can agree it's a bug, then I guess it should be fixed as part of the general maintenance of the package. At any rate, if we did change/fix the behavior, a warning should probably be issued. If an attribute == "" then log a warning such as "The behavior of this has changed. Make sure your templates are updated." \malthe
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Malthe Borch wrote:
2009/3/10 Fred Drake <fdrake@gmail.com>:
The change would need to be in zope.tal.
True.
I'm ambivalent; while it makes sense to me in isolation, the affect on existing templates is undesirable, and compatibility is a huge deal for this bit of machinery.
I agree, but it would be interesting to gauge the usage of this functionality (e.g. if everyone could put a breakpoint in the right place, run their apps and check).
Actually, I think this is a bug; why would the empty string not be printed? If we can agree it's a bug, then I guess it should be fixed as part of the general maintenance of the package.
At any rate, if we did change/fix the behavior, a warning should probably be issued. If an attribute == "" then log a warning such as "The behavior of this has changed. Make sure your templates are updated."
It seems like we ought to start emitting the warnings first, and then fold in the new behavior as the default later. Maybe we could allow some kind of configuration to enable the newer behavior sooner. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJtn49+gerLs4ltQ4RAvZRAKCPyQZVuh3ecEj4ODykqe/hSUtpNwCfQItb sKhX/88Ifb5UXv7IRo1oF14= =ucbc -----END PGP SIGNATURE-----
On Tue, 2009-03-10 at 10:50 -0400, Tres Seaver wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Malthe Borch wrote:
2009/3/10 Fred Drake <fdrake@gmail.com>:
The change would need to be in zope.tal.
True.
I'm ambivalent; while it makes sense to me in isolation, the affect on existing templates is undesirable, and compatibility is a huge deal for this bit of machinery.
I agree, but it would be interesting to gauge the usage of this functionality (e.g. if everyone could put a breakpoint in the right place, run their apps and check).
Actually, I think this is a bug; why would the empty string not be printed? If we can agree it's a bug, then I guess it should be fixed as part of the general maintenance of the package.
At any rate, if we did change/fix the behavior, a warning should probably be issued. If an attribute == "" then log a warning such as "The behavior of this has changed. Make sure your templates are updated."
It seems like we ought to start emitting the warnings first, and then fold in the new behavior as the default later. Maybe we could allow some kind of configuration to enable the newer behavior sooner.
Ack. Not being able to produce empty attributes is a bug. Fixing it might break apps. Adding an option to enable it first and then moving this to a default setting later is a good way to go, IMHO. I'm not sure how to time the move, though. One option would be to release a bugfix with the option as non-default and a feature release with the option as default. Christian -- Christian Theune · ct@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 7 · fax +49 345 1229889 1 Zope and Plone consulting and development
2009/3/18 Christian Theune <ct@gocept.com>:
I'm not sure how to time the move, though. One option would be to release a bugfix with the option as non-default and a feature release with the option as default.
That's a good approach. What kind of configuration should enable it; an environment variable or a module global? \malthe
On Wed, 2009-03-18 at 10:55 +0300, Malthe Borch wrote:
2009/3/18 Christian Theune <ct@gocept.com>:
I'm not sure how to time the move, though. One option would be to release a bugfix with the option as non-default and a feature release with the option as default.
That's a good approach.
What kind of configuration should enable it; an environment variable or a module global?
Module global please. The global can then be also set using e.g. a configuration option in other programs, like making it configurable from zope.conf. -- Christian Theune · ct@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 7 · fax +49 345 1229889 1 Zope and Plone consulting and development
Hi Malthe
Betreff: [Zope-dev] ZPT attributes and ""
Currently, if an attribute expression evaluates to any value that's boolean False, it's omitted (e.g. 0, "", object()). I think that's unexpected. Instead, attributes should only be omitted when the expression evaluates to ``None``.
I think this is better then render empty strings. see below...
How do folks feel about changing this behavior in ``zope.pagetemplate``.
Probably anything else then "" should be skipped. There is no logic why object() or False should get rendered as "". I only whould expect that an empty string whould get rendered as "". And probably we should check the HTML specification and make sure that we only render empty strings for attributes where they are allowed. see: http://www.w3.org/TR/html401/types.html#type-name ID and NAME tokens must begin with a letter ([A-Za-z]) and may be followed by any number of letters, digits ([0-9]), hyphens ("-"), underscores ("_"), colons (":"), and periods ("."). This means to me that an empty value for id or name doen't start with [A-Za-z] and is invalid because is must start with [A-Za-z]. or not? Regards Roger Ineichen
\malthe _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
2009/3/18 Roger Ineichen <dev@projekt01.ch>:
This means to me that an empty value for id or name doen't start with [A-Za-z] and is invalid because is must start with [A-Za-z]. or not?
Correct, but should enforce these requirements? I think ZPT should just have predictable, expected behavior, but not make too much fuss about syntax. I agree though, that object() or False should probably raise exceptions. \malthe
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Roger Ineichen wrote:
Hi Malthe
Betreff: [Zope-dev] ZPT attributes and ""
Currently, if an attribute expression evaluates to any value that's boolean False, it's omitted (e.g. 0, "", object()). I think that's unexpected. Instead, attributes should only be omitted when the expression evaluates to ``None``.
I think this is better then render empty strings. see below...
How do folks feel about changing this behavior in ``zope.pagetemplate``.
Probably anything else then "" should be skipped. There is no logic why object() or False should get rendered as "".
Non-true values have special semantics for certain attributes ('checked', 'selected', I think).
I only whould expect that an empty string whould get rendered as "". And probably we should check the HTML specification and make sure that we only render empty strings for attributes where they are allowed.
see: http://www.w3.org/TR/html401/types.html#type-name
ID and NAME tokens must begin with a letter ([A-Za-z]) and may be followed by any number of letters, digits ([0-9]), hyphens ("-"), underscores ("_"), colons (":"), and periods (".").
This means to me that an empty value for id or name doen't start with [A-Za-z] and is invalid because is must start with [A-Za-z]. or not?
- -1 on making ZPT / chameleon responsible for enforcing that requirement: that would be the application's job. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJwNuY+gerLs4ltQ4RAnvLAJ41d/7G0sHnH7GfX/CV9v+Dw6ksAQCgw+ZC LfHPVXRoCkejJLyCvLjdvyU= =ClnO -----END PGP SIGNATURE-----
Hi Tres
Betreff: Re: [Zope-dev] ZPT attributes and ""
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Roger Ineichen wrote:
Hi Malthe
Betreff: [Zope-dev] ZPT attributes and ""
Currently, if an attribute expression evaluates to any value that's boolean False, it's omitted (e.g. 0, "", object()). I think that's unexpected. Instead, attributes should only be omitted when the expression evaluates to ``None``.
I think this is better then render empty strings. see below...
How do folks feel about changing this behavior in ``zope.pagetemplate``.
Probably anything else then "" should be skipped. There is no logic why object() or False should get rendered as "".
Non-true values have special semantics for certain attributes ('checked', 'selected', I think).
Good point
I only whould expect that an empty string whould get rendered as "". And probably we should check the HTML specification and make sure that we only render empty strings for attributes where they are allowed.
see: http://www.w3.org/TR/html401/types.html#type-name
ID and NAME tokens must begin with a letter ([A-Za-z]) and may be followed by any number of letters, digits ([0-9]), hyphens ("-"), underscores ("_"), colons (":"), and periods (".").
This means to me that an empty value for id or name doen't start with [A-Za-z] and is invalid because is must start with [A-Za-z]. or not?
- -1 on making ZPT / chameleon responsible for enforcing that requirement: that would be the application's job.
Hm, that's a good point too. I see what you are thinking. My motivation is, it is valid to skip attributes with empty values for an element in an XML document. (not sure) If this is true, then there is no reason why a default empty values should get rendered. As far as I know it is valid to skip attributes for empty values but for some attributes it is not valid to use empty values. And the bad thing, some attributes need empty values like you suggested with checked="" etc, oh my ;-) Regards Roger Ineichen
Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFJwNuY+gerLs4ltQ4RAnvLAJ41d/7G0sHnH7GfX/CV9v+Dw6ksAQCgw+ZC LfHPVXRoCkejJLyCvLjdvyU= =ClnO -----END PGP SIGNATURE-----
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
On Wed, Mar 18, 2009 at 7:59 AM, Roger Ineichen <dev@projekt01.ch> wrote:
As far as I know it is valid to skip attributes for empty values but for some attributes it is not valid to use empty values.
Let's not use the term valid in this context, as it's pretty overloaded here. In the general case, there's no way to know what string values can be dropped silently, and it's wrong to assume that it can be done safely. Using a special value (None, a.k.a. nothing in templates) is the only reasonable indicator that an attribute should be dropped. -Fred -- Fred L. Drake, Jr. <fdrake at gmail.com> "Chaos is the score upon which reality is written." --Henry Miller
On Wed, Mar 18, 2009 at 07:31:36AM -0400, Tres Seaver wrote:
Roger Ineichen wrote:
Hi Malthe
Betreff: [Zope-dev] ZPT attributes and ""
Currently, if an attribute expression evaluates to any value that's boolean False, it's omitted (e.g. 0, "", object()).
object() is true in boolean contexts.
I think that's unexpected. Instead, attributes should only be omitted when the expression evaluates to ``None``.
I think this is better then render empty strings. see below...
How do folks feel about changing this behavior in ``zope.pagetemplate``.
Probably anything else then "" should be skipped. There is no logic why object() or False should get rendered as "".
Non-true values have special semantics for certain attributes ('checked', 'selected', I think).
True values also. This is a feature of TAL in HTML mode and should be preserved <input type="checkbox" tal:attributes="checked some_bool_expr" /> Marius Gedminas -- http://pov.lt/ -- Zope 3 consulting and development
participants (6)
-
Christian Theune -
Fred Drake -
Malthe Borch -
Marius Gedminas -
Roger Ineichen -
Tres Seaver