Re: [Zope-dev] Re: [ZPT] Order of attribute execution Feature Request
On Sat, May 11, 2002 at 02:55:23PM +, Florent Guillaume wrote: Jim Penny [EMAIL PROTECTED] wrote: I also have not found a convention that I am comfortable with on handling check-boxes and radio buttons in error processing. But I expect to! Are you referring to what I call magic boolean attributes ? http://lists.zope.org/pipermail/zpt/2002-March/003013.html Yes, thanks very much, this is very helpful. I see that you could find no documentation on this, and got no reply. Is this intended to be a permanent feature, or is is experimental? Jim Penny Florent -- Florent Guillaume, Nuxeo (Paris, France) +33 1 40 33 79 87 http://nuxeo.com mailto:[EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [ZPT] Order of attribute execution Feature Request
Jim Penny [EMAIL PROTECTED] wrote: Are you referring to what I call magic boolean attributes ? http://lists.zope.org/pipermail/zpt/2002-March/003013.html Yes, thanks very much, this is very helpful. I see that you could find no documentation on this, and got no reply. Is this intended to be a permanent feature, or is is experimental? I'm pretty sure it's permanent, only undocumented. Florent -- Florent Guillaume, Nuxeo (Paris, France) +33 1 40 33 79 87 http://nuxeo.com mailto:[EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [ZPT] Order of attribute execution Feature Request
Florent Guillaume wrote: Jim Penny [EMAIL PROTECTED] wrote: Are you referring to what I call magic boolean attributes ? http://lists.zope.org/pipermail/zpt/2002-March/003013.html Yes, thanks very much, this is very helpful. I see that you could find no documentation on this, and got no reply. Is this intended to be a permanent feature, or is is experimental? I'm pretty sure it's permanent, only undocumented. Florent, do you have committer privileges? You can certainly check in documentation of this behavior. You can also add a comment to the Zope book. http://www.zope.org/Documentation/ZopeBook/AdvZPT.stx Shane ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [ZPT] Order of attribute execution Feature Request
Shane Hathaway [EMAIL PROTECTED] wrote: I'm pretty sure it's permanent, only undocumented. Florent, do you have committer privileges? You can certainly check in documentation of this behavior. You can also add a comment to the Zope book. http://www.zope.org/Documentation/ZopeBook/AdvZPT.stx Yes I have committer privileges, and if I find the time I'll check in the necessary changes to the doc. BTW my comment was in no way intended to disparage you or the writers of the TAL doc, I myself understand only too much how 24 hours in a day are never enough :-) Florent -- Florent Guillaume, Nuxeo (Paris, France) +33 1 40 33 79 87 http://nuxeo.com mailto:[EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [ZPT] Order of attribute execution Feature Request
On Mon, May 13, 2002 at 03:32:21PM -0400, Shane Hathaway wrote: Florent Guillaume wrote: Jim Penny [EMAIL PROTECTED] wrote: Are you referring to what I call magic boolean attributes ? http://lists.zope.org/pipermail/zpt/2002-March/003013.html Yes, thanks very much, this is very helpful. I see that you could find no documentation on this, and got no reply. Is this intended to be a permanent feature, or is is experimental? I'm pretty sure it's permanent, only undocumented. Florent, do you have committer privileges? You can certainly check in documentation of this behavior. You can also add a comment to the Zope book. http://www.zope.org/Documentation/ZopeBook/AdvZPT.stx I will write up something and do the feedback thing in the Zope book. It seems to me it should be in both the advanced section and the ZPTRef section. Would like a bit of guidance on the Ref writeup, i.e., what does ZC want to call it (presumably not magic boolean attributes)? Jim Penny Shane ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [ZPT] Order of attribute execution Feature Request
Jim Penny [EMAIL PROTECTED] wrote: I also have not found a convention that I am comfortable with on handling check-boxes and radio buttons in error processing. But I expect to! Are you referring to what I call magic boolean attributes ? http://lists.zope.org/pipermail/zpt/2002-March/003013.html Florent -- Florent Guillaume, Nuxeo (Paris, France) +33 1 40 33 79 87 http://nuxeo.com mailto:[EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [ZPT] Order of attribute execution Feature Request
Tim Hoffman wrote: In addition event handlers in html ie onClick onBlur etc are all order independant. now adding tal: attributes that where order dependant would seem to fly in the face of that convention. (Admittedely there are probably no strange dependancies that could be introduced with different orders of border, src etc) Indeed. It isn't just a convention. The order of attributes within an XML or SGML tag is explicitly defined not to matter. Two important properties of attributes within a tag are that they are unordered, and they are unique. http://aspn.activestate.com/ASPN/Mail/Message/xml-dev/666339 -- Steve Alexander ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [ZPT] Order of attribute execution Feature Request
Jim Penny wrote: on the surface, to be pretty ugly. I have said that there are three specific things I dislike about ZPT -- 0) lots of things have changed spelling again -- request v. REQUEST, here v. context v. container v. this v. ? Yeah, there was absolutely no need for this and I did find it extremely frustrating. That said, the whole area has always been a mess, particularly in DTML. I do, however, wish that Script (Python)'s and ZPT could have been consistent :-(( 1) infix notation that makes program scansion hard, You don't HAVE to use infix ;-) tr tal:repeat=x xes td tal:content=x/idan ID/td /tr ...can also be written as: tal:x repeat=x xes tr tdtal:x replace=x/id//td /tr /tal:x 2) the order of operations, which I think is baroque. Six levels of precendence for eight statements is pretty amazing. And it is certainly harder to explain/remember than things happen in the order you specify. *shrugs* I've done a u-turn on this. Tim's comments make it perfectly obvious why this needs to be the case, and at least it is very well defined what order things happen in (as Ken pointed out). My only beef is that define sometimes happens in an order that is less helpful than it could be ;-) tal:x repeat=fish fishes define=species fish/species ...doesn't do what I'd like it to ;-) I will add a fourth nit -- I cannot see why attributes should be plural when every other command is singular. Certainly it feels like attribute ought to be an acceptable spelling of the atttributes command! *shrugs* this is pretty minor to be honest ;-) My most-missed DTML feature has not been mentioned at all -- it is not loop batching -- it is the dtml-else option of dtml-in -- which made it much easier to handle the nothing found case. tal:x define=pigs here/gimmeSomePigs tal:x repeat=pig pigs This little piggie went to tal:x replace=pig/location. /tal:x tal:else condition=not:pigs Waaagh! No bacon! /tal:else /tal:x I also have not found a convention that I am comfortable with on handling check-boxes and radio buttons in error processing. But I expect to! Not sure what you mean, can you explain the problem a bit more? cheers, Chris ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [ZPT] Order of attribute execution Feature Request
On Fri, May 10, 2002 at 11:53:47AM +0100, Chris Withers wrote: Jim Penny wrote: on the surface, to be pretty ugly. I have said that there are three specific things I dislike about ZPT -- 0) lots of things have changed spelling again -- request v. REQUEST, here v. context v. container v. this v. ? Yeah, there was absolutely no need for this and I did find it extremely frustrating. That said, the whole area has always been a mess, particularly in DTML. I do, however, wish that Script (Python)'s and ZPT could have been consistent :-(( 1) infix notation that makes program scansion hard, You don't HAVE to use infix ;-) tr tal:repeat=x xes td tal:content=x/idan ID/td /tr ...can also be written as: tal:x repeat=x xes tr tdtal:x replace=x/id//td /tr /tal:x Interesting. I seem to remember this from the Wiki's, is it documented anywhere else? This really seems like Chapter 5 material. 2) the order of operations, which I think is baroque. Six levels of precendence for eight statements is pretty amazing. And it is certainly harder to explain/remember than things happen in the order you specify. *shrugs* I've done a u-turn on this. Tim's comments make it perfectly obvious why this needs to be the case, and at least it is very well defined what order things happen in (as Ken pointed out). My only beef is that define sometimes happens in an order that is less helpful than it could be ;-) tal:x repeat=fish fishes define=species fish/species Actually, the first time I got bit was on repeat v. condition. I wanted the condition to test each row, not to guard the entire iteration process. ...doesn't do what I'd like it to ;-) I now agree with this, as well, on the basis that XML says no order, and that some XML tools may reorder. Yuck. OK, off to add following comments to Zope Book ZPT Reference -- Since the on-error statement is invoked ... +If multiple statements appearing within an element have the same +precedence level, the order of execution of those statements +within the precedence group is undefined. The reasoning behind these precedences begins with the fact that TAL statements are being writtten as XML attributes. By definition, XML attributes are un-ordered, and XML tools may, and do, rewrite attributes in any order they wish. But, for TAL to be useful as a programming language, there has to be a predictable order of operations. This order was chosen by the following rationale: ... Any objection to that wording? I will add a fourth nit -- I cannot see why attributes should be plural when every other command is singular. Certainly it feels like attribute ought to be an acceptable spelling of the atttributes command! *shrugs* this is pretty minor to be honest ;-) Hey, nits are by definition small. A foolish consistency is the hobgoblin of small minds but Make things as simple as possible, but no simpler! My most-missed DTML feature has not been mentioned at all -- it is not loop batching -- it is the dtml-else option of dtml-in -- which made it much easier to handle the nothing found case. tal:x define=pigs here/gimmeSomePigs tal:x repeat=pig pigs This little piggie went to tal:x replace=pig/location. /tal:x tal:else condition=not:pigs Waaagh! No bacon! /tal:else /tal:x Thanks... I also have not found a convention that I am comfortable with on handling check-boxes and radio buttons in error processing. But I expect to! Not sure what you mean, can you explain the problem a bit more? OK, consider a form like: pError Message (may be replaced)/p form action=. Name: input type=text name=namebr/ Type: input type=checkbox name=social_skills value=nerd checkednerd input type=checkbox name=social_skills value=geekgeek input type=checkbox name=social_skills value=mundanemundane ... /form On entry I would like a default to be checked. On call with an error message I would like the item that was most recently checked to remain checked. For example, suppose I needed to prevent multiple definitions of the same name. my validation routine could set error_message and then my tal would look like: p tal:replace=structure contents | nothingError Message/p form action=. Name: input type=text name=name tal:attributes=name request/name|nothingbr/ But how do I elegantly handle checked element? If checked were a true attribute (i.e. took form checked=1 or checked=0), it would be clear! But they aren't. cheers, Chris ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - [EMAIL PROTECTED]
Re: [Zope-dev] Re: [ZPT] Order of attribute execution Feature Request
Jim Penny wrote: ...can also be written as: tal:x repeat=x xes tr tdtal:x replace=x/id//td /tr /tal:x Interesting. I seem to remember this from the Wiki's, is it documented anywhere else? This really seems like Chapter 5 material. No idea, but it definitely should be... tal:x repeat=fish fishes define=species fish/species Actually, the first time I got bit was on repeat v. condition. I wanted the condition to test each row, not to guard the entire iteration process. Yup, that's another common one, easily solved though: tal:x repeat=fish fishes tal:x condition=fish/hasHead !-- instructions for removing fish head here -- /tal:x /tal:x OK, off to add following comments to Zope Book ZPT Reference -- Since the on-error statement is invoked ... +If multiple statements appearing within an element have the same +precedence level, the order of execution of those statements +within the precedence group is undefined. ...and that does suck :-S in any order they wish. But, for TAL to be useful as a programming language, TAL IS NOT A PROGRAMMING LANGUAGE!!! It is a templating language, and they are VERY different animals... OK, consider a form like: pError Message (may be replaced)/p form action=. Name: input type=text name=namebr/ Type: input type=checkbox name=social_skills value=nerd checkednerd input type=checkbox name=social_skills value=geekgeek input type=checkbox name=social_skills value=mundanemundane ... /form On entry I would like a default to be checked. On call with an error message I would like the item that was most recently checked to remain checked. For example, suppose I needed to prevent multiple definitions of the same name. my validation routine could set error_message and then my tal would look like: p tal:replace=structure contents | nothingError Message/p form action=. Name: input type=text name=name tal:attributes=name request/name|nothingbr/ But how do I elegantly handle checked element? If checked were a true attribute (i.e. took form checked=1 or checked=0), it would be clear! But they aren't. Oh but they are ;-) I was surprised by this, but HTML no longer has attributes without values, and all browsers support it: tal:x define=social_skills request/social_skills | string:nerd repeat=skill python:['nerd','geek','mundane'] input type=checkbox name=social_skills value=nerd tal:attributes=checked python:social_skills==skill;nerd /tal:x cheers, Chris ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [ZPT] Order of attribute execution Feature Request
Jim Penny wrote: I have also said that, while ZPT is not as warty as DTML, ZPT looks, on the surface, to be pretty ugly. I have said that there are three specific things I dislike about ZPT -- 0) lots of things have changed spelling again -- request v. REQUEST, here v. context v. container v. this v. ? I understand this, but ZPT design was deliberately not constrained by DTML or Script binding design. DTML has no way to spell 'here' or 'container', and 'this' is actually a method defined by one of the Zope mixin classes. REQUEST is an artifact of acquisition, an attempt to deal with a giant pile of (possibly conflicting) names that doesn't make sense in the TALES namespace. So, the only real spelling changes are acquisition's REQUEST vs. request and Scripts' context vs. here. During development, we often referred to the entire collection of standard TALES variables as contexts, so calling the current traversal object context felt peculiar. 2) the order of operations, which I think is baroque. Six levels of precendence for eight statements is pretty amazing. And it is certainly harder to explain/remember than things happen in the order you specify. As mentioned before, several decisions were made based on the constraints of XML. Process XML with XSLT, or some other standards-compliant filter, and you cannot guarantee that the order of attributes will be preserved. Frankly, I don't see the difficulty. All you need to remember is that variables are defined first and substitions happen after repetition. The only thing I would change now is to make repeat come first. I will add a fourth nit -- I cannot see why attributes should be plural when every other command is singular. Certainly it feels like attribute ought to be an acceptable spelling of the atttributes command! I suggested allowing both singular and plural versions, but it was roundly rejected by Jim and Guido (among others) on the basis of too many ways to spell things. Also, the only other TAL statement that can have multiple parts is define; define a variable and define variables both sound right. My most-missed DTML feature has not been mentioned at all -- it is not loop batching -- it is the dtml-else option of dtml-in -- which made it much easier to handle the nothing found case. Yes, TAL's constraints make else-type logic hard to do well. It's not all bad, though; if you define a variable for your list you can easily do: div tal:repeat=value seq.../div div tal:condition=not:seqelse/div I also have not found a convention that I am comfortable with on handling check-boxes and radio buttons in error processing. But I expect to! What do you mean? Cheers, Evan @ 4-am ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
