[Zope-dev] Conditionals in XML
Jeffrey P Shell writes: You would at the very least need something like: condition if.../if elif.../elif else.../else /condition Which would ensure / cut back on needless growth of stacks and/or global variables. Personally, I think the way Page Templates can do it (via a 'not' expression) is fine. When I used it today (and in the past), I never felt myself missing 'else', because there's not really an 'if' to begin with. Just conditions. It keeps TAL light, and lets TALES take on the lifting of how to write those conditions. I've been banging my head against the problem of how to elegantly express if/else/ifelse structures in xml, so this is an interesting discussion! Any easy sleazy solution (like dtml's approach) that breaks XML syntax or structure is right out, so it requires a different approach. I like Jeffrey's idea: The condition comes first (outside), and the if and else that use it are nested inside: condition expr=... if ... /if elif [I'm not sure how this clause works: where does its condition go?] /elif else ... /else /condition It reads easily (with the condition obviously first and up top), and blocks the code off nicely. The elif I'm not so clear on. It might have its own expr=... (or whatever), which would break the symmetry and imply that if could also contain a conditional expression. I haven't used TAL yet, so I'm not really qualified to judge. But I'm not really happy with the attribute based approach. I'd rather use an XML based macro language with the full capabilities of Lisp macros (just bound to the Python runtime instead of a Lisp system). I think Python is a great implementation language for other higher level XML based languages, like ZPT and others. I don't like the idea of purposefully crippling a language in the misguided quest to separate presentation and logic. If you have a good enough XML based language, you can use it to express both presentation and logic, and you can cleanly and easily separate presentation and logic because you have the power of abstraction, not because you're forced to. Any extra incompatible language syntax you're forced to use just add friction and confusion and interoperability problems. Don't add another layer unless you have to. Don't force programmers to drop down into Python because the templating language is too weak (nothing against Python, but I'm talking about implementing a higher level language that is more powerful, not purposefully weaker). Templates should be structural transformation macros, not string substitution. Macros require a full powered programming language, or else they're a waste of time because their limitations cause maintenance nightmares. Please do not repeat the mistakes of the miserable C pre-processor macros (or scandalous C++ templates for that matter). Settle for nothing less than Lisp macros, and strive for something even better. Full power macros make it possible for programmers to implement clean, simple application specific mini-languages, that can be neatly nested inside of other templates, data, etc. There are many wonderful ways of separating presentation and logic, that Lisp macros make not only possible but also convenient and maintainable. The standard approach of lobotomizing the presentation language forces you to separate presentation and logic in the worst possible way (by using another language), while sacrificing many superior approaches to solving the problem. Paul Graham's wonderful book On Lisp practically explains Lisp macros with lots of great examples, and you can download the pdf file and read it for free: http://www.paulgraham.com/onlisp.html Lisp's cond seems more elegant than long chains of if/elif/else. The if/elif/else syntax requires several different keywords with a particular ordering, so it's harder to rearrange, add and delete clauses; therefore it's harder to maintain the code over time. It uses different keywords for different clauses (and in xml they're repeated twice as begin and end tags) so you have to change both of them to add or delete additional clauses. How can the syntax best support maintaining reliable and readable templates and code? (C's switch statement and single statement if/else's without brackets are horrible counter examples.) Since if/else is more common than if/elif/else, maybe it's better to keep if/else simple, use cond for chains, and not to support elif (or elseif or however you spell it, which invites mistakes). Lisp's cond is easier to use and more general purpose than C's switch/case syntax (which I would dread to emulate in any other language, with its horrible limitations and problems (design defects): not supporting computed case statements, requiring break, too many ways to make mistakes). Paul Graham (the author of On Lisp) has written some other interesting stuff about simplifying cond, in the design of his ARC language. http://www.paulgraham.com/arc.html http://www.paulgraham.com/arcll1.html The
[Zope-dev] Depending on attribute order is not XML compliant
I feel compelled to take the XML hard line, and point out that depending on the ordering of XML attributes is not compliant: http://www.w3.org/TR/xml-infoset/ XML Information Set W3C Recommendation 24 October 2001 2. Information Items 2.2. Element Information Items An element information item has the following properties: 5. [attributes] An unordered set of attribute information items, one for each of the attributes (specified or defaulted from the DTD) of this element. Namespace declarations do not appear in this set. If the element has no attributes, this set has no members. If you're going to use XML, then use XML, and don't break the spec. The worse thing you could do is to use something-that-almost-looks-like-xml-but-is-slightly-different. That's asking for trouble, and guarantees there will be problems down the line. The whole point of using XML is so people can have the valid expectation that their XML data will work with any compliant XML tool. As somebody else pointed out, many XML editors reorder the attributes (which they are 100% justified in doing), and that is as much a fact of life as what they do with the newlines and white space. If you're going to define a language that's not XML because it depends on attribute ordering, then please use an obviously different syntax (like parenthesis instead of angled brackets), so as not to mislead and confuse people, or corrupt data. If you just want to attach ordered items to an XML element, then use sub-elements which can be ordered, not attributes which are by definition unordered. -Don ___ 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 )
[Zope-dev] Re: Zope-Dev digest, Vol 1 #1682 - 11 msgs
At 06:13 10/05/2002, [EMAIL PROTECTED] wrote: 'else' is tricky within the block oriented structure of anything XML-ish, because of the concept of 'well-formedness'. The 'if' statement would have to be singly wrapped, and the else block wrapped separately, looking at least somewhat awkward any way you go about it. The best I can come up with in my mind is this, in order to have the 'else' pick up on the condition expressed in its surrounding container. But, yuck: if ... true stuff else false stuff /else /if A good page template way is something like this: tal:if condition=myTalesExpression truth /tal:if tal:else condition=not:myTalesExpression false /tal:else The 'not' TALES namespace is valuable. The downside is that you evaluate the expression twice. A good way to work within this is something that I did earlier today, outside of this conversation, where I evaluate an expression earlier and assign it to a variable: div id=edit-area tal:define=editItems python:here.getMenuItem(...) h3Edit Menu Items/h3 form action=Delete method=post name=actForm tal:condition=editItems ... (form and table elements, and a loop over editItems contained in here if there were results) ... /form div class=emph tal:condition=not:editItems No menu items available /div /div This is something I did a lot in DTML too, setting a search result to either a global variable, or inside of a large dtml-let namescape It is maybe not clear that the above is really usable and allowed. I do not know how and where to stress that the tal: marked tags are underdocumented what a pity. I have already tried : http://www.zope.org/Documentation/ZopeBook/AdvZPT.stx#3-44 Sorry that I am not able to explain it better... -- Godefroid Chapelle BubbleNet sprl rue Victor Horta, 18 / 202 1348 Louvain-la-Neuve Belgium Tel + 32 (10) 459901 Mob + 32 (477) 363942 TVA 467 093 008 RC Niv 49849 ___ 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 FeatureRequest
Tim Hoffman wrote: snip This I would imagine could introduce all sorts of nasty bugs. Good points! On that basis, I retract my feature request ;-) 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: 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] ZPT and 'else'
Tim Hoffman wrote: The big problem with the whole 'else' issue as I see it, is that non coders, using dreamweaver etc.. would no doubt end up with both bit's of html in their template. But that's exactly what you want! hey can then see what would happen in either case and will probabyl write better templates as a result :-) 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] Can I get rid of standard_template.pt?
I'm not using it, and will never use it, so why does Zope 2.5.1 always create one for me? Grrr. Highly annoying. :-[ ___ 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] ZPT is young
On Thursday 09 May 2002 09:47, Chris Withers wrote: Thomas Olsen wrote: DTML is great for style sheets, javascript and such where you cannot use ZPT and python scripts would be too ugly to use ;-) There's no reason to use DTML for these, as I've explained before ;-) Must have missed that mail..? -- Regards, Thomas Olsen ___ 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] ZPT is young
On Friday 10 May 2002 01:19, Adrian Hungate wrote: Yeah, for CSS I'd use ZStyleSheets, and for javascript I'd use a very large magnet... but that is another argument. GRIN -- Regards, Thomas Olsen ___ 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] ZPT is young
Thomas Olsen wrote: Must have missed that mail..? http://zope.nipltd.com/public/lists/dev-archive.nsf/$$Search?OpenForm 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] Re: ZPT and else
Quoting Jeffrey P Shell: The 'not' TALES namespace is valuable. The downside is that you evaluate the expression twice. A good way to work within this is something that I did earlier today, outside of this conversation, where I evaluate an expression earlier and assign it to a variable: div id=edit-area tal:define=editItems python:here.getMenuItem(...) h3Edit Menu Items/h3 form action=Delete method=post name=actForm tal:condition=editItems ... (form and table elements, and a loop over editItems contained in here if there were results) ... /form div class=emph tal:condition=not:editItems No menu items available /div /div Another way to do this is to use the python test() function inside tal:replace to conditionally replace the if content with the else content. For example: div id=edit-area tal:define=editItems python:here.getMenuItem(...) h3Edit Menu Items/h3 form action=Delete method=post name=actForm tal:replace=python:test(editItems, default, 'No menu items available') ... (form and table elements, and a loop over editItems contained in here if there were results) ... /form /div This technique works well when you have one case which is more involved and can be the default, and another case which is simple text (like an error message). -- Brent - The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures. -- Frederick Brooks, Jr., The Mythical Man Month ___ 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] Can I get rid of standard_template.pt?
Lennart Regebro wrote: I'm not using it, and will never use it, so why does Zope 2.5.1 always create one for me? Grrr. Highly annoying. :-[ From Zope 2.1.3 (when I started Zopeing), I could write a Python Product that expected standard_html_header and standard_html_footer to exist. From Zope 2.5.1, I can write a Python Product that expects standard_template.pt to exist. -- 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] Can I get rid of standard_template.pt?
From: Steve Alexander [EMAIL PROTECTED] From Zope 2.5.1, I can write a Python Product that expects standard_template.pt to exist. I dont see the purpose of that. Checking that is exists is trivial if you need it. I don't. I want to get rid of it, thankyouverymuch. Guess I'll just have to patch the core, as usual. Ah well. *Deep sigh*. ___ 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] Can I get rid of standard_template.pt?
If its the same as earlier zopes its line 174 of OFS\Application.py remove the offending reserved names. Except maybe for Control_Panel, it seems pointless. If the item's not there, an error is raised. Simple. To me there should just be a warning message, Removing this item may cause some products that expect this not to work, are you sure you want to do this? Likewise I will probably get rid of standard_template.pt, most of the session stuff... This also lets you do useful things like make standard_error_message a Python Script, yipeee. - Original Message - From: Lennart Regebro [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, May 10, 2002 5:36 AM Subject: [Zope-dev] Can I get rid of standard_template.pt? I'm not using it, and will never use it, so why does Zope 2.5.1 always create one for me? Grrr. Highly annoying. :-[ ___ 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
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] Can I get rid of standard_template.pt?
I looked at 2.5 on surprised to see that apart from Control Panel only 'browser_id_manager' and 'temp_folder' are protected meaning you can delete all the others. I threw a monkeypatch up that allows you to delete them anyway, and it will work for pre 2.4 systems (http://www.zope.org/Members/andym/Reserved) But... when you restart Zope it recreates them all again for you :) However you can delete the Examples and not have them come back ;) Since its all one big function in Application.py, it will be a little bit hard to monkey patch further but could probably be a little more consistent to say the least. - Original Message - From: Andy McKay [EMAIL PROTECTED] To: Lennart Regebro [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, May 10, 2002 7:20 AM Subject: Re: [Zope-dev] Can I get rid of standard_template.pt? If its the same as earlier zopes its line 174 of OFS\Application.py remove the offending reserved names. Except maybe for Control_Panel, it seems pointless. If the item's not there, an error is raised. Simple. To me there should just be a warning message, Removing this item may cause some products that expect this not to work, are you sure you want to do this? Likewise I will probably get rid of standard_template.pt, most of the session stuff... This also lets you do useful things like make standard_error_message a Python Script, yipeee. - Original Message - From: Lennart Regebro [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, May 10, 2002 5:36 AM Subject: [Zope-dev] Can I get rid of standard_template.pt? I'm not using it, and will never use it, so why does Zope 2.5.1 always create one for me? Grrr. Highly annoying. :-[ ___ 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 ) ___ 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] ZPT and 'else'
on 5/10/02 12:47 AM, Jeffrey P Shell at [EMAIL PROTECTED] scrivened: You would need something to close off the 'if' statement, otherwise, a document full of 'if' statements and no 'else' ones could fill up a stack needlessly. What's so bad about that? The stack wouldn't carry over after html/html or body/body - couldn't practically more than 1000's - insignificant! You would at the very least need something like: condition if.../if elif.../elif else.../else /condition Which would ensure / cut back on needless growth of stacks and/or global variables. Personally, I think the way Page Templates can do it (via a 'not' expression) is fine. When I used it today (and in the past), I never felt myself missing 'else', because there's not really an 'if' to begin with. Just conditions. It keeps TAL light, and lets TALES take on the lifting of how to write those conditions. Point is, it's slow and inefficient, and a clunky syntax. Reasons the whole idea of 'else' was invented in the first place. I worry, that ZPT is benchmarked 4x slower than DTML and it's becoming the standard - not a step forward. And issue like this haven't been satisfactorily resolved. I think, if it's going to have logic in there, make it sufficiently powerful and efficient. Otherwise get rid of it altogether, unapologetically, and require Python for such things ___ 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] ZPT and 'else'
on 5/9/02 11:58 PM, Tim Hoffman at [EMAIL PROTECTED] scrivened: The big problem with the whole 'else' issue as I see it, is that non coders, using dreamweaver etc.. would no doubt end up with both bit's of html in their template. Don't you have that now with the kludgey 'not' construct? ___ 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: ...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] 'not:' kludgey?!
Marc Lindahl wrote: Don't you have that now with the kludgey 'not' construct? What is kludgey about the 'not:' construct?! 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 FeatureRequest
On 5/10/02 4:53 AM, Chris Withers [EMAIL PROTECTED] 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 :-(( Me too. I keep typing 'here' in Python Scripts now. While I know I can change the bindings, I'm sure that would just make more confusion for me down the road. In regards to request v. REQUEST, I do like the page templates spelling. 'request' is just another path root, and all path roots are lower case. 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 I think this is another good feature of ZPT which seems almost like a side benefit of XML Namespace usage (and instead of 'tal:x', you can also use more meaningful terms like 'tal:loop'). As for program 'scansion', I don't view a Page Template as program. But I think programmer readability can be achieved just by good formatting. And when using some HTML tools, whether they're text oriented, visually, or both, some of them hilight unknown attributes differently. GoLive 6 by default colorizes unknown attributes/tags in orange, while known ones are in blue. Attribute values remain in brown. So, a combination of good formatting and a half decent editor can yield good usability. If these are problems for the pure-programming set, there is still DTML. And, if anyone can plug in a good XSLT processor, that could open up another alternative templating system. XHTML aware editors should present the least amount of problems, as namespaces (in theory) shouldn't cause any confusion. 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 ;-) Evan Simpson explained this to me once in a way that made sense, but I can't remember what it is right now. [SNIP!] -- Jeffrey P Shell www.cuemedia.com Industrie Toulouse on Zope http://radio.weblogs.com/0106123/categories/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 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 )
Re: [Zope-dev] ZPT and 'else'
On 5/10/02 9:25 AM, Marc Lindahl [EMAIL PROTECTED] wrote:
on 5/10/02 12:47 AM, Jeffrey P Shell at [EMAIL PROTECTED] scrivened:
You would need something to close off the 'if' statement, otherwise, a
document full of 'if' statements and no 'else' ones could fill up a stack
needlessly.
What's so bad about that? The stack wouldn't carry over after html/html
or body/body - couldn't practically more than 1000's - insignificant!
Still, yuck. It's - for better or worse - not a valid XML way. Even XSLT
does things like this:
xsl:stylesheet version=1.1
xmlns:xsl=http://www.w3.org/1999/XSL/Transform;
xsl:template match=/
xsl:choose
xsl:when test=system-property('xsl:version') = 1.1
xsl:exciting-new-1.1-feature/
/xsl:when
xsl:otherwise
html
head
titleXSLT 1.1 required/title
/head
body
pSorry, this stylesheet requires XSLT 1.1./p
/body
/html
/xsl:otherwise
/xsl:choose
/xsl:template
/xsl:stylesheet
xsl:if can stand on its own, but to do the equivalent of else, one has to
use:
xsl:choose
xsl:when test=expression(template)/xsl:when
xsl:when test=expression(template)/xsl:when
xsl:otherwise(template)/xsl:when
/xsl:choose
But, Page Templates are not XSLT. And I thank gods for that. XSLT is
powerful, but I wouldn't be able to do the type of work I've been doing this
week with them as easily as I've been able to do them with Page Templates.
I couldn't even have done them as easily using DTML.
You would at the very least need something like:
condition
if.../if
elif.../elif
else.../else
/condition
Which would ensure / cut back on needless growth of stacks and/or global
variables.
Personally, I think the way Page Templates can do it (via a 'not'
expression) is fine. When I used it today (and in the past), I never felt
myself missing 'else', because there's not really an 'if' to begin with.
Just conditions. It keeps TAL light, and lets TALES take on the lifting of
how to write those conditions.
Point is, it's slow and inefficient, and a clunky syntax. Reasons the whole
idea of 'else' was invented in the first place. I worry, that ZPT is
benchmarked 4x slower than DTML and it's becoming the standard - not a step
forward. And issue like this haven't been satisfactorily resolved.
If speed mattered that much, we'd all still be using C and/or assembly
language. Scripting Languages have become very standard, even though
they're orders of magnitude slower than their compiled counterparts. I
don't think it would be any more worth turning Page Templates back into an
imperative programming language than it would be to turn Python into C. Or
Haskell into Python. Or J into Lisp. Or Zope into PHP. Every language
and platform has its strengths and weaknesses, and I think ZPT's strengths
more than make up for its current speed deficiencies. I spend less time
debugging and cleaning up Page Template code than I did with DTML,
particularly late-generation DTML. And the results look *much* better.
I personally can't see a way of having an else (or equivalent of
'xsl:choose') without starting to clutter up the current elegance of Page
Templates, and it has to do with the way Page Templates are designed (and
it's a design that I think is done pretty close to right). One reason being
that, since all TAL things happen on attributes (it is the 'Template
Attribute Language', and by law all XML attributes have to be quoted, you'd
end up with something like this:
div tal:choose=
h1 tal:condition=some/expressionYay!/h1
h1 class=warning tal:otherwise=Boo/h1
/div
The only way out of this is to introduce special TAL tags. And at that
point, we're back to some of the problems with DTML - 'special markup tags
and the editors the bruise them'. And at _that_ point, we're out of one of
the intended audiences of Page Templates.
I think, if it's going to have logic in there, make it sufficiently powerful
and efficient. Otherwise get rid of it altogether, unapologetically, and
require Python for such things
Another option is the XMLC route, which is painful. XMLC identified every
possible writable element with an id, and id only. Then, corresponding Java
code could refer to that ID and replace the element with something. It kept
the visual design side very clean, but the code to do the dynamic generation
could get very ugly.
Or, there's the option is to give up on templating altogether and go with
PHP style syntax, or fill up Python code with:
s += 'emNo contents available/em'
I personally think Page Templates are rather elegant and a joy to use after
five and a half years of DTML usage. I keep having to deal with other
solutions like 'tea', 'cheetah', ASP/PSP, and it's just a mess.
--
Jeffrey P Shell
www.cuemedia.com
___
Zope-Dev maillist - [EMAIL PROTECTED]
[Zope-dev] Don't try to improve or reinvent XML. Stick with the standard.
From: Marc Lindahl [EMAIL PROTECTED] You would need something to close off the 'if' statement, otherwise, a document full of 'if' statements and no 'else' ones could fill up a stack needlessly. What's so bad about that? The stack wouldn't carry over after html/html or body/body - couldn't practically more than 1000's - insignificant! If you're not going to use correct XML syntax, which REQUIRES balanced tags, then you shouldn't use a syntax that looks like XML but isn't. The world does NOT need another language that looks almost like XML, but that is impossible to process using standard XML tools. Not balancing the tags is as bad as requiring the attributes to be ordered: it's simply not compliant. If you're going to invent a new non-standard non-XML syntax, PLEASE don't make it look ANYTHING like XML. Otherwise you wrongly set the users' expectations that they'll be able to use standard XML editing tools, which is false advertising. If you really want to invent a new syntax that doesn't have the restrictions of XML like balanced tags and unordered attributes, then please don't make it look anything like XML, and please fix all of XML's other problems while you're at it. Don't just force users to suffer with the bad parts of XML without getting the benefits of interoperability with XML tools. That's the worst of both worlds. -Don ___ 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] Don't try to improve or reinvent XML. Stick withthe standard.
Don Hopkins wrote: From: Marc Lindahl [EMAIL PROTECTED] You would need something to close off the 'if' statement, otherwise, a document full of 'if' statements and no 'else' ones could fill up a stack needlessly. What's so bad about that? The stack wouldn't carry over after html/html or body/body - couldn't practically more than 1000's - insignificant! If you're not going to use correct XML syntax, which REQUIRES balanced tags, then you shouldn't use a syntax that looks like XML but isn't. I don't think that's what was originally suggested. I think what was originally suggested is that an 'if' *element* would leave something on the interpreter's stack, for use by an 'else' element later. So, the document remains well-formed, but there is a coupling between non-contained elements. -- 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 )
[Zope-dev] Permissions
Hello, I would like to setup the security on a Zope server such that a user can edit permissions on something they own, but not grant more permissions than what they have acquired from the parent. If a user owns a folder they could grant Owner any permissions they want inside of that folder (Assuming they have the Change permission permission). Is there a way to limit which permissions a user can change? I would like to be able to delegate permissions. Such that if a user creates a folder they can grant other roles permissions up to the permissions they have acquired from the parent folder. Is this possible? I don't want that user to be able to grant themselves additional permissions. Thanks, -Brian Brinegar ___ 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] Order of attribute execution Feature Request
On Fri, 2002-05-10 at 12:21, Jim Penny wrote: On Fri, May 10, 2002 at 11:53:47AM +0100, Chris Withers wrote: [...] 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. You shouldn't want that. If you want a condition applied to each item of a sequence to decide if you want to display it or not, then you are filtering the sequence, and filtering sequences has no place in a templating language. What you should want is to have a python script or a tal:define (which evaluates before tal:repeat) to provide the filtered sequence. Filtering elements out of a sequence is coding, and a presentation language should not be messing with that. And no, putting a tal:x tal:condition... block enclosed imediatelly inside a tal:x tal:repeat is not an acceptable solution, because you'll be generating useless whitespace for every instance of the repeat that is not selected by your condition. I still have painful memories of a situation where some pages served by a Zope instance in one client where excruciatingly slow. It turned out to be the pages themselves, which where huge, and contained mostly whitespace. And the reason they where huge was because they contained 3 dtml-ins with dtml-ifs to the same HUGE sequence (a sql query, IIRC), with dtml-ins in them, each time selecting just a few of the elements. Cheers, Leo -- Ideas don't stay in some minds very long because they don't like solitary confinement. ___ 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 )
