Re: [ZPT] Order of attribute execution Feature Request
On Thu, May 09, 2002 at 04:07:14PM -0400, Ken Manheimer wrote:
On Thu, 9 May 2002, Dieter Maurer wrote:
Chris Withers writes:
Jim Penny wrote:
2) that is introduces some additional, fairly baroque magic in the "order of execution of element type" definitions. I would have preferred that they be evaulated/performed in textual order.
This is a case where i'd say "baroque" is intemperate. The documention ( http://dev.zope.org/Wikis/DevSite/Projects/ZPT/TAL%20Specification%201.4 ) not only specifically declares the order of operations operations, but it goes on to describe the rationale behind them!
Now, if you _disagree_ with the choices, and can cite cases which substantiate your reasoning, then great, file a collector issue! But calling it baroque implies that it's overelaborate and/or obscure to the informed user - neither of which seems, to me at least, to be the case.
I'd second that... where do we stick feature requests like this?
I would assume it's the Zope collector. I suppose you could add comments in the ZPT wiki, as well. If you see a glaring error, and feel it warrants stirring up a lot of attention, then post something to zope coders - but you've both been pretty vague about your complaints, i don't have the impression you are chafing from some particular error.
Now, Ken, I think you ought to reread the thread. Chris has consistently defended ZPT, except for this one "feature". I am ambivalent towards ZPT, but have stated that I will be, and am in fact, moving towards using them nearly exclusively. I am in this because I felt that someone was being dumped on for daring to suggest that DTML is at least cosmetically better. 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. ? 1) infix notation that makes program scansion hard, 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." 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! Now I will turn around and say what I do like about ZPT. Well-formed-ness is indeed nice. The reduction of magic in variable lookup is nice. The "| nothing" convention is very nice when used content or replace statements -- it makes it very easy to use the same form for both input and error processing -- something that is almost by itself worth the price of admission. In fact, this is not really mentioned in the ZopeBook or ZPT Reference, it is shown only (on page 143) in combination with an unnecessary condition command. I also missed the "| default" convention that I can see as very useful. 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. 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! Jim Penny
I think the order is irrelevant because the DOM considers attributes unordered. Not good to implement things against the standard model.
Attributes are unordered in the traversal, but of course the processing of the resulting structure (the semantics) is up to the application! And the documentation is very clear about how the application behaves - with good motivation.
Furthermore, changing this facet in the implementation will break lots of exiting templates.
Where do we condemn feature requests like this?
:-)
I imagine whoever is responsible for PageTemplates will float a proposal for changes if they're convinced any are necessary.
-- Ken klm@zope.com
Hi Just my 2c worth, but I would like to defend order of execution of ZPT. What it does mean for me is I can guaruntee zpt commands will "always" be processed in a known order irrespective of where you put them in a tag, this I like ;-) What I do miss is "else" clause but I think it would be probably be too hard to implement, and too much of encouragement for people to start putting more logic in the template, so on the whole it is probably best to leave it out. See ya T On Fri, 2002-05-10 at 05:15, Jim Penny wrote:
On Thu, May 09, 2002 at 04:07:14PM -0400, Ken Manheimer wrote:
On Thu, 9 May 2002, Dieter Maurer wrote:
Chris Withers writes:
Jim Penny wrote:
2) that is introduces some additional, fairly baroque magic in the "order of execution of element type" definitions. I would have preferred that they be evaulated/performed in textual order.
This is a case where i'd say "baroque" is intemperate. The documention ( http://dev.zope.org/Wikis/DevSite/Projects/ZPT/TAL%20Specification%201.4 ) not only specifically declares the order of operations operations, but it goes on to describe the rationale behind them!
Now, if you _disagree_ with the choices, and can cite cases which substantiate your reasoning, then great, file a collector issue! But calling it baroque implies that it's overelaborate and/or obscure to the informed user - neither of which seems, to me at least, to be the case.
I'd second that... where do we stick feature requests like this?
I would assume it's the Zope collector. I suppose you could add comments in the ZPT wiki, as well. If you see a glaring error, and feel it warrants stirring up a lot of attention, then post something to zope coders - but you've both been pretty vague about your complaints, i don't have the impression you are chafing from some particular error.
Now, Ken, I think you ought to reread the thread. Chris has consistently defended ZPT, except for this one "feature". I am ambivalent towards ZPT, but have stated that I will be, and am in fact, moving towards using them nearly exclusively. I am in this because I felt that someone was being dumped on for daring to suggest that DTML is at least cosmetically better.
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. ? 1) infix notation that makes program scansion hard, 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."
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!
Now I will turn around and say what I do like about ZPT. Well-formed-ness is indeed nice. The reduction of magic in variable lookup is nice. The "| nothing" convention is very nice when used content or replace statements -- it makes it very easy to use the same form for both input and error processing -- something that is almost by itself worth the price of admission. In fact, this is not really mentioned in the ZopeBook or ZPT Reference, it is shown only (on page 143) in combination with an unnecessary condition command. I also missed the "| default" convention that I can see as very useful.
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.
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!
Jim Penny
I think the order is irrelevant because the DOM considers attributes unordered. Not good to implement things against the standard model.
Attributes are unordered in the traversal, but of course the processing of the resulting structure (the semantics) is up to the application! And the documentation is very clear about how the application behaves - with good motivation.
Furthermore, changing this facet in the implementation will break lots of exiting templates.
Where do we condemn feature requests like this?
:-)
I imagine whoever is responsible for PageTemplates will float a proposal for changes if they're convinced any are necessary.
-- Ken klm@zope.com
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org 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 )
On 5/9/02 7:07 PM, "Tim Hoffman" <timhoffman@cams.wa.gov.au> wrote:
Just my 2c worth, but I would like to defend order of execution of ZPT. What it does mean for me is I can guaruntee zpt commands will "always" be processed in a known order irrespective of where you put them in a tag, this I like ;-)
Me too. Occasional alarms, no surprises.
What I do miss is "else" clause but I think it would be probably be too hard to implement, and too much of encouragement for people to start putting more logic in the template, so on the whole it is probably best to leave it out.
See ya
T On Fri, 2002-05-10 at 05:15, Jim Penny wrote:
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.
'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(...)"> <h3>Edit 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 -- Jeffrey P Shell www.cuemedia.com Industrie Toulouse on Zope http://radio.weblogs.com/0106123/categories/zope/
Yecch! Why not: <if ...> True stuff </if> <else> False stuff </else> If leaves around boolean result, else picks up the most recent one... It's like they push on a stack so you can nest them.... Something like that? on 5/9/02 11:10 PM, Jeffrey P Shell at jeffrey@cuemedia.com scrivened:
'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(...)">
<h3>Edit 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
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. T On Fri, 2002-05-10 at 11:39, Marc Lindahl wrote:
Yecch!
Why not: <if ...> True stuff </if> <else> False stuff </else>
If leaves around boolean result, else picks up the most recent one... It's like they push on a stack so you can nest them.... Something like that?
on 5/9/02 11:10 PM, Jeffrey P Shell at jeffrey@cuemedia.com scrivened:
'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(...)">
<h3>Edit 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
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org 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 )
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
on 5/9/02 11:58 PM, Tim Hoffman at timhoffman@cams.wa.gov.au 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?
on 5/10/02 11:32 AM, Chris Withers at chrisw@nipltd.com scrivened:
Marc Lindahl wrote:
Don't you have that now with the kludgey 'not' construct?
What is kludgey about the 'not:' construct?!
For the reasons 'else' was invented in the first place, I guess: prone to errors, inefficient, bulky. The biggest thing I see is: isn't linked to the other construct, so it's prone to errors when editing the conditions.
Marc Lindahl wrote:
on 5/10/02 11:32 AM, Chris Withers at chrisw@nipltd.com scrivened:
Marc Lindahl wrote:
Don't you have that now with the kludgey 'not' construct?
What is kludgey about the 'not:' construct?!
For the reasons 'else' was invented in the first place,
'else' in what context?!
I guess: prone to errors, inefficient, bulky.
Can you give any material that actually backs up these sweeping claims? ;-)
The biggest thing I see is: isn't linked to the other construct, so it's prone to errors when editing the conditions.
Well, I've already shown the way I'd do this which only has the condition in one place.... cheers, Chris
on 5/13/02 3:11 PM, Chris Withers at chrisw@nipltd.com scrivened:
For the reasons 'else' was invented in the first place,
'else' in what context?!
Meaning, in procedural languages.
I guess: prone to errors, inefficient, bulky.
Can you give any material that actually backs up these sweeping claims? ;-)
Prone to errors: when changing the condition, have to duplicated edits in 2 places, so you could make an error which would be hard to track down. Inefficient: have to evaluate an expression twice (unless someone makes a jit compiler!) Bulky: in terms of taking more space in the source file, without clarifying what's being done.
The biggest thing I see is: isn't linked to the other construct, so it's prone to errors when editing the conditions.
Well, I've already shown the way I'd do this which only has the condition in one place....
Yes you did, and re-reading the TAL wiki (http://www.zope.org//Wikis/DevSite/Projects/ZPT/TAL%20Specification%201.2) it's clear that your approach is the one the language is designed for. Also, your approach can easily accommodate other logic structures like case statement. Well, I guess I'm convinced!
Marc Lindahl wrote:
on 5/13/02 3:11 PM, Chris Withers at chrisw@nipltd.com scrivened:
For the reasons 'else' was invented in the first place,
'else' in what context?!
Meaning, in procedural languages.
Okay, repeat the mantra over to yourself: Templating languages are not procedural languages Templating languages are not procedural languages Templating languages are not procedural languages (etc) *grinz*
I guess: prone to errors, inefficient, bulky.
Can you give any material that actually backs up these sweeping claims? ;-)
Prone to errors: when changing the condition, have to duplicated edits in 2 places,
No you don't. Do I have to say that a third time? ;-)
Inefficient: have to evaluate an expression twice (unless someone makes a jit compiler!)
I guess I do... :-P
Bulky: in terms of taking more space in the source file, without clarifying what's being done.
That's a bit woolly, gimme some concrete examples...
Yes you did, and re-reading the TAL wiki (http://www.zope.org//Wikis/DevSite/Projects/ZPT/TAL%20Specification%201.2) it's clear that your approach is the one the language is designed for. Also, your approach can easily accommodate other logic structures like case statement. Well, I guess I'm convinced!
*grinz* Chris
on 5/14/02 4:41 AM, Chris Withers at chrisw@nipltd.com scrivened:
Okay, repeat the mantra over to yourself:
Templating languages are not procedural languages
Sounds nice, but what does it mean? AFAIK a procedural language is something that has a definite order of execution... How does a templating language differ?
Can you give any material that actually backs up these sweeping claims? ;-)
Prone to errors: when changing the condition, have to duplicated edits in 2 places,
No you don't. Do I have to say that a third time? ;-)
Referring to, not the construct you exemplified, but the previous one in the thread (can't find it in the archive right now)....
Marc Lindahl wrote:
on 5/14/02 4:41 AM, Chris Withers at chrisw@nipltd.com scrivened:
Okay, repeat the mantra over to yourself:
Templating languages are not procedural languages
Sounds nice, but what does it mean? AFAIK a procedural language is something that has a definite order of execution... How does a templating language differ?
A template language is all about filling in holes in a template. This should be thought of logically as happening 'all at once', so _not_ in a definite order of execution... cheers, Chris
There's absolutely nothing about your definition of templating languages ("all about filling in holes in a template") that precludes them being procedural languages (or functional languages for that matter, as XSLT attempts to be). That's just your own arbitrary, artificial limitation that unfortunately has been religiously applied to this particular templating language. It's simply a trade-off that somebody decided to make, too long ago to change. The fact that "else" is kludgy is just one of the many unfortunate consequences of that design decision. That shouldn't discourage people from designing better templating languages. Please don't impinge on the definition of all templating languages, just because of the limitations of one particular implementation. Lisp is a wonderfully powerful templating language, and it certainly supports procedural, functional, object oriented, and many other kinds of programming. However, the standard, agreed-upon definition of XML EXPLICITLY defines attributes as being unordered, so any so-called "templating" language that depends on the order of attributes is BY DEFINITION not standard XML, and should not be advertised as such. -Don From: "Chris Withers" <chrisw@nipltd.com> Subject: Re: [Zope-dev] 'not:' kludgey?!
on 5/14/02 4:41 AM, Chris Withers at chrisw@nipltd.com scrivened:
Okay, repeat the mantra over to yourself:
Templating languages are not procedural languages
Sounds nice, but what does it mean? AFAIK a procedural language is something that has a definite order of execution... How does a templating language differ?
A template language is all about filling in holes in a template. This should be thought of logically as happening 'all at once', so _not_ in a definite order of execution...
cheers,
Chris
on 5/14/02 6:11 PM, Don Hopkins at xardox@mindspring.com scrivened:
However, the standard, agreed-upon definition of XML EXPLICITLY defines attributes as being unordered, so any so-called "templating" language that depends on the order of attributes is BY DEFINITION not standard XML, and should not be advertised as such.
There are different concepts of ordering: - sequential down the page - hierarchical - precedence I think we're talking about sequential - since XML does have a hierarchical ordering, and doesn't seem to tread into precedence. TAL defines precedence (define before condition, etc.) The idea for implementing 'else' (though I now think it's unneccessary) used the hierarchical ordering of XML to get the ordering it needed. But I also submit that ZPT can't be simply 'filling the slots' since it has a condition statement.
From: "Chris Withers" <chrisw@nipltd.com> Subject: Re: [Zope-dev] 'not:' kludgey?!
For the reasons 'else' was invented in the first place,
'else' in what context?!
Meaning, in procedural languages.
Okay, repeat the mantra over to yourself:
Templating languages are not procedural languages Templating languages are not procedural languages Templating languages are not procedural languages
To be more accurate: SOME templating languages were never designed to be procedural languages. SOME templating languages were never designed to be procedural languages. SOME templating languages were never designed to be procedural languages. -Don
Don Hopkins wrote:
To be more accurate:
Nope ;-)
SOME templating languages were never designed to be procedural languages.
...if a language is designed to be a procedural language, then it ain't a templating language... cheers, Chris
From: "Chris Withers" <chrisw@nipltd.com> Subject: Re: [Zope-dev] 'not:' kludgey?!
Don Hopkins wrote:
To be more accurate:
Nope ;-)
SOME templating languages were never designed to be procedural languages.
...if a language is designed to be a procedural language, then it ain't a templating language...
cheers,
Chris
Please show me some references to where you got your definition of "templating language". Has the term been officiall defined by W3C, or is the term defined in the literature? References and examples, please! A few years ago I implemented my own XML templating language which was a lot like Lisp, based on the lessons of HyperTIES and other systems. Since then I've decided to throw it away and reimplement an even better XML templating language with Python, which is why this discussion interests me. I've included some samples of my own XML templating language, including code and data, at the end of this message. Templating is a purpose to which you put a language. It's not an exclusive category that rules out any particular programming technique. Lisp is an excellent templating language for generating Lisp code, also known as "metaprogramming'. The C preprocessor is a woefully lame templating language, because it's string based, and lacks procedural programming constructs. But C++ templates are certainly a much more powerful templating language than C preprocessor macros. C++ templates allow you to trick the compiler into performing all kinds of calculations for you. They're Turing complete, but astronomically complex. Unfortunately you have to deeply understand almost everything about C++ templates in to use them (and especially to debug them). Case in point: STL. However, Lisp macros are way more powerful than C++ templates, and much easier to use, without requiring you to understand their inner workings. Example: the "loop" macro. Here are some references and examples of some of my earlier work on hypertext templating languages. During 1988-1990, I was working for Ben Shneiderman at the University of Maryland Human Computer Interaction Lab, on a system called "HyperTIES": designing, implementing and using a hypermedia markup language called "HyperTIES Markup Language", with a browser for the NeWS window system, and an authoring tool based on UniPress Emacs. We considered using SGML at the time but decided not to, because it was too complex and not very user-friendly, so we developed our own markup language. Ben Shneiderman is very focused on the "ease of use" thing (for authors as well as users), but as a researcher he also wants to experiment with advanced techniques like authoring and browsing conditional and parameterized hypermedia (aka "templates"). So HyperTIES was designed to be simple enough for non-programmers to author and use, yet also powerful enough for programmers to make application-specific templates and frameworks of macros, which non-programmers could easily use to author their own pages, without understanding the entire language. The HyperTIES Markup Language syntax was designed to be simple ("low syntactic surface area"), while also supporting abstraction, conditionals, looping, variables, macros and other procedural programming language constructs. In 1989, the Unix version of HyperTIES supported java-like "applets" which casual authors could easily embed and parameterize, without understanding the implementation language. I implemented the HyperTIES browser in C and NeWS PostScript, and the authoring tool in Emacs Mocklisp, using James Gosling's NeWS window system and Emacs text editor (he hadn't invented Java yet). HyperTIES authors could use macros and other constructs like loops and conditionals, to dynamically populate pages with interactive formatted text, graphics, and parameterized applets (like pie menus, etc). The HyperTIES browser would download a formatted PostScript display list to the window server, then instantiate and customize all of the interactive embedded widgets on the page. It supported components such as encapsulated PostScript, graphical buttons, pop-up shaped image maps, text editors, pie menus, and other interactive widgets implemented in PostScript for the NeWS window system. Casual hypermedia authors could create applets and pass parameters to them without programming or understanding the PostScript implementation language running in the window server. Authors could also call on pre-defined higher level libraries of HyperTIES macros, written by programmers to support their particular tasks, all without knowing how to program the HyperTIES Markup Language running in the browser. You don't need to know how to program in a language, in order to simply call pre-defined functions and macros. It's misguided to artificially limit the power of a templating language, in order to make it "easy to use". Defining templating languages as "not procedural lanugages" is simply wrong, and totally arbitrary. That definition excludes many widely used, well known templating languages, and totally ignores mountains of published literature and research on the subject. (Douglas Adams calls this the "Somebody Else's Problem" syndrome. Templating languages that support procedural programming are so big, brightly painted and obvious that they must be "Somebody Else's Problem", thus rendering them invisible.) Whether or not we agree on the definition of "templating" languages, I do know that it's possible to design XML based languages that are both easy to use for non-programmers to author, and also powerful enough for programmers to extend to handle all kinds of tasks. The power of abstraction makes it possible for programmers to create macros that are easy for non-programmers to use, which can be illustrated by HyperTIES and the anonymous XML templating languages included at the end of this message. (Sorry, I never gave the language a name.) It's unfortunate that some so-called "templating" languages leave out macros and other powerful programming language constructs, so they are much less useful than they would have been otherwise, which is a shame. -Don ==== http://www.cms.dmu.ac.uk/General/hci/hcibib/HTML/HYPER/Shne91a.html CS-TR-2433 Ben Shneiderman. Catherine Plaisant. Rodrigo Botafogo. Don Hopkins. William Weiland. May 1991. Designing to facilitate browsing: A look back at the Hyperties. Since browsing hypertext can present a formidable cognitive challenge, user interface design plays a major role in determining acceptability. In the Unix workstation version of Hyperties, a research-oriented prototype, we focussed on design features that facilitate browsing. We first give a general overview of Hyperties and its markup language. Customizable documents can be generated by the conditional text feature that enables dynamic and selective display of text and graphics. In addition we present: - an innovative solution to link identification: pop-out graphical buttons of arbitrary shape. - application of pie menus to permit low cognitive load actions that reduce the distraction of common actions, such as page turning or window selection. - multiple window selection strategies that reduce clutter and housekeeping effort. We preferred piles-of-tiles, in which standard-sized windows were arranged in a consistent pattern on the display and actions could be done rapidly, allowing users to concentrate on the contents. (Also cross-referenced as CAR-TR-494) Human Computer Interaction Laboratory, Center for Automation Research, Dept. of Computer Science, Univ. of Maryland, Institute for Systems Research, ==== http://www.cs.umd.edu/hcil/hyperties/ Hypertext Research: The Development of HyperTIES Starting in 1982, HCIL developed an early hypertext system on the IBM PC computers. Ben Shneiderman invented the idea of having the text itself be the link marker, a concept that came to be called embedded menus or illuminated links. Earlier systems used typed-in codes, numbered menus or link icons. Embedded menus were first implemented by Dan Ostroff in 1983 and then applied and tested by Larry Koved (Koved and Shneiderman, 1986). In 1984-85 the work was supported by a contract from the US Department of Interior in connection with the U.S. Holocaust Memorial Museum and Education Center. Originally called The Interactive Encyclopedia Systems (TIES), we ran into trademark conflicts and in 1986 changed the name to HyperTIES as we moved toward commercial licensing with Cognetics Corporation. We conducted approximately 20 empirical studies of many design variables which were reported at the Hypertext 1987 conference and in array of journals and books. Issues such as the use of light blue highlighting as the default color for links, the inclusion of a history stack, easy access to a BACK button, article length, and global string search were all studied empirically. We used Hyperties in the widely circulated ACM-published disk Hypertext on Hypertext which contained the full text of the 8 papers in the July 1988 Communications of the ACM. A Unix-based Sun implementation in the SUN OS and NEWS environments was built by Don Hopkins, Bill Weiland, and Rodrigo Botafogo under the leadership of Catherine Plaisant. Rodrigo Botafogo developed the first image map implementation on the PC for touchscreen selections in the Smithsonian Institution's exhibit "King Herod's Dream" in May 1988. The public access kiosk, developed by Catherine Plaisant and Richard Potter, was called "Guide to Opportunities in Volunteer Archaeology (GOVA) and toured for 18 months in six cities. In 1989, Ben Shneiderman and Greg Kearsley published Hypertext Hands-on!, the world's first commercial electronic book with the highlighted links idea. This innovative book/software package provided the first hands-on, non-technical introduction to hypertext. The publicity claimed: Highlights: - describes hypertext applications for travel guides, product catalogs, technical documentation, novels, blueprints, textbooks, encyclopedias, and more - software contains examples of a hyper novella, hyper travel guide, hyper business procedures, hyper blueprints, and even a hyper joke. - discusses system design issues such as user interface, performance, networks, direct manipulation, windows, browsing, indexes, etc. [...] Other Hyperties features anticipated the World Wide Web. Charles Kreitzberg, Whitney Quesenbery, and programmers at Cognetics made professional implementations of image maps, animations, and a markup language called HTML (Hyperties Markup Language). It is quite similar to the HTML markup language used with web browsers; both drew on concepts in SGML, which continues to be an important markup language within the publishing community. Hyperties also had a Java-like scripting language, which allowed processes to be attached to pages or to links. Early readings on HyperTIES: Ewing, J., Mehrabanzad, S., Sheck, S. Ostroff, D., and Shneiderman, B., An experimental comparison of a mouse and arrow-jump keys for an interactive encyclopedia, International Journal of Man-Machine Studies 24, 1 (January 1986), 29-45. Shneiderman, B., User interface design for the Hyperties electronic encyclopedia, Hypertext '87 Workshop Proceedings, Raleigh, NC, November 13-15, 1987, 199-204. Shneiderman, B. (Editor), Hypertext on Hypertext, Hyperties disk with 1Mbyte data and graphics incorporating Communication of the ACM (July 1988), New York: ACM Press. Koved, L. and Shneiderman, B., Embedded menus: Selecting items in context, Communications of the ACM 29, 4 (April 1986), 312-318. Shneiderman, B., Reflections on authoring, editing, and managing hypertext. In Barrett, E. (Editor), The Society of Text, MIT Press, Cambridge, MA (1989), 115-131. Shneiderman, B. and Kearsley, G., Hypertext Hands-On! An Introduction to a New Way of Organizing and Accessing Information, Addison-Wesley, Reading, MA (1989). Shneiderman, B., Plaisant, C., Botafogo, R., Hopkins, D., and Weiland, W., Designing to facilitate browsing: A look back at the Hyperties workstation browser, Hypermedia 3, 2 (1991), 101-117. Brethauer, D., Plaisant, C., Potter, R., and Shneiderman, B., Three evaluations of museum installations of a hypertext system, Journal of the American Society for Information Science 40, Special Issue on Hypertext, (May 1989), 172-182. ==== This is a description I wrote to Dave Winer about my reaction to the "open-sourcing" of Xanadu, which he asked me to post on his "Userland" discussion board. It describes the "info" hypertext system in UniPress Emacs, as well as HyperTIES, HyperLook, and some ideas from other systems. (I had to break it up into several messages to fit on the discussion board.) http://static.userland.com/userLandDiscussArchive/msg010163.html http://static.userland.com/userLandDiscussArchive/msg010164.html http://static.userland.com/userLandDiscussArchive/msg010165.html http://static.userland.com/userLandDiscussArchive/msg010166.html http://static.userland.com/userLandDiscussArchive/msg010167.html ==== What follows are some examples from my own XML based hypertext templating language. Here is the URL of the experimental server, that you can play around with to see how it works. All the graphics and products are just test data, you can't acutally order anything, and the credit card verification stuff is disabled. http://www.lushcreations.tv/cgi-bin/mugger.cgi Here is a typical page template, that processes a credit card entry form, and relies on a whole bunch of macros and tables of xml data. You can create your own forms by writing in a simple XML data format, without doing any programming at all. The author writes simple XML data and page templates, that calls the pre-defined macros. The macros interpret the parameters and data, and render the html. No programming is necessary for authors to make page templates and forms, but the language's support for programming was essential in order to implement the task specific macros, which the author need not understand in order to use. The XML code can call named macros, that handle high level tasks like rendering, handling and validating forms. Macros can take attribute arguments (unordered of course ;-), as well the XML structures they enclose, as parameters. Most of the strangely named elements are macros, specific to the task of generating html and processing forms, defined in terms of other macros and a few built-in primitives. <page name="Enter Credit Card"> <webpage title="Enter Credit Card"> <scope formResult="0"> <validateform secure="s" name="CreditCard" result="formResult"/> <if><att>scope.formResult</att> <then> [Credit card validation and processing stuff omitted.] </then> </if> </scope> </webpage> </page> Here is the "validateform" macro, which you don't have to understand in order to use. Just pass it the name of a form, defined in XML below. It calls on a bunch of other macros, and uses a framework of form, widget and validator definitions, also written in XML (below). <macro name="validateform" secure=""> <with collection="forms" element="form" key="name" value="{validateform.name}"> <scope valid="true" errormessages="" varval="" textsize="64" textrows="64" textcols="8"> <CENTER> <postform secure="{validateform.secure}"> <TABLE> <foreach element="form"> <if><cgidefined name="{varname}"/> <then> <def element="scope" key="varval"><cgi name="{varname}" default="" remove="false"/></def> <def element="session" key="{varname}"><att>scope.varval</att></def> </then> <else> <def element="scope" key="varval"><att>session.{varname}</att></def> </else> </if> <if><isempty><att>validate</att></isempty> <then> <displaywidget/> </then> <else> <if><strip><expandchildren collection="validators" element="validator" key="name" value="{validate}"/></strip> <then> <hidden NAME="{varname}" VALUE="{varval}"/> <displaywidget/> <def element="session" key="{varname}">{varval}</def> </then> <else> <def element="scope" key="valid">false</def> <def element="scope" key="errormessages">{scope.errormessages} <H2>{error}</H2></def> <TR><TD COLSPAN="2"> <H2> {error} </H2> </TD></TR> <requestwidget/> </else> </if> </else> </if> </foreach> <if><eq><att>scope.valid</att> <quote>true</quote></eq> <then> <TR> <TD COLSPAN="2"> <CENTER> <H1> Thank you! </H1> <store key="{validateform.result}">1</store> </CENTER> </TD> </TR> </then> <else> <TR> <TD COLSPAN="2"> <CENTER> <H1> Please try again! </H1> <inlinenavbutton name="Enter Corrections" page="Enter Credit Card"/> <store key="{validateform.result}">0</store> </CENTER> </TD> </TR> </else> </if> </TABLE> </postform> <navbutton name="Return to Form" page="Credit Card" secure="s"> <hideform name="{validateform.name}"/> </navbutton> </CENTER> </scope> </with> </macro> Here are the XML tables that the form processing framework uses to render, submit and validate the forms. I've omitted some parts like the names of all the states, etc, so you can get the idea without reading all the code. All of the information needed to completely handle a form is specified on one place, in XML. In order to make a form, you only need to understand the <form> and <widget> syntax, and the framework handles the rest. The framework (implemented with macros) takes care of all the heavy lifting and book keeping required to process the forms, by manipulating data in the form of XML structures, and calling on primitives defined in the language interpreter. This is called "data driven programming", which is a common technique with lisp-like languages, that allow you to cleanly and easily embed code inside of data, nest data inside of code, pass data and code around as parameters, evaluate, deconstruct and reconstruct code as data, etc. <forms> <form name="NewAccount"> <widget type="text" label="Name" varname="newuser" srcvar="user.name" validate="isnotempty" error="Please enter your name."/> <widget type="password" label="Password" varname="newpassword1" validate="isnotempty" error="Please enter the same password twice."/> <widget type="password" label="Repeat Password" varname="newpassword2" validate="isnewpassword1" error="Please enter the same password twice."/> <widget type="text" label="Email Address" varname="email" srcvar="user.email" validate="isany" error="Please enter your email address."/> <widget type="text" label="Postal Address" varname="address" srcvar="user.address" validate="isany" error="Please enter your shipping address."/> <widget type="text" label="City" varname="city" srcvar="user.city" validate="isany" error="Please enter your city."/> <widget type="text" label="State" varname="state" srcvar="user.state" validate="isany" error="Please enter your state."/> <widget type="text" label="Zip Code" varname="zipcode" srcvar="user.zipcode" validate="isany" error="Please enter your zip code."/> <widget type="text" label="Country" varname="country" srcvar="user.country" validate="isany" error="Please enter your country."/> <widget type="text" label="Phone" varname="phone" srcvar="user.phone" validate="isany" error="Please enter your phone number, including the area code."/> <widget type="text" label="Fax" varname="fax" srcvar="user.fax" validate="isany" error="Please enter your fax phone number, including the area code."/> </form> <form name="CreditCard"> <widget type="header" label="Billing and Shipping Form"/> <widget type="subrule"/> <widget type="subheader" label="Billing Address"/> <widget type="menu" label="Credit Card" varname="cardtype" default="Visa" validate="iscardtype" error="Please select a valid credit card type."> <item label="Visa" value="Visa"/> <item label="MasterCard" value="MasterCard"/> <item label="American Express" value="AmericanExpress"/> <item label="Choice" value="Choice"/> <item label="Discover" value="Discover"/> </widget> <widget type="menu" label="Expiration Month" varname="cardexpirationmonth" validate="ismonth" default="01" error="Please select a valid credit card expiration month."> <item label="January" value="01"/> [...] </widget> <widget type="text" label="Card Number" varname="cardnumber" validate="iscardnumber" secret="1" error="Please enter a valid credit card number."/> <widget type="text" label="Name on Card" varname="cardname" srcvar="user.name" validate="isnotempty" error="Please enter the name on the credit card."/> <widget type="text" label="Billing Address" varname="cardaddress" srcvar="user.address" validate="isnotempty" error="Please enter the credit card billing address."/> <widget type="text" label="City" varname="cardcity" srcvar="user.city" validate="isnotempty" error="Please enter the city of the credit card billing address."/> <widget type="menu" label="State" varname="cardstate" srcvar="user.state" validate="isstate" default="CA" error="Please select a valid state."> <item label="None" value=""/> <item label="AK" value="AK"/> [...] </widget> <widget type="text" label="Zip Code" varname="cardzipcode" srcvar="user.zipcode" validate="isnotempty" error="Please enter the zip code of the credit card billing address."/\
<widget type="text" label="Country" varname="cardcountry" srcvar="user.country" validate="isnotempty" error="Please enter the country of the credit card billing address."/> <widget type="text" label="Phone" varname="cardphone" srcvar="user.phone" validate="isphone" error="Please enter the billing phone number, including the area code."/> <widget type="text" label="Fax" varname="cardfax" srcvar="user.fax" validate="isphoneorempty" dstvar="cardfax" error="Please enter the billing fax phone number, including th\ e area code."/> <widget type="space"/> <widget type="subheader" label="Shipping Address"/> <widget type="text" label="Name Of Recipient" varname="shippingname" srcvar="user.name" validate="isnotempty" error="Please enter the name of the recipient."/> <widget type="text" label="Shipping Address" varname="shippingaddress" srcvar="user.address" validate="isnotempty" error="Please enter the recipient's shipping address."/> <widget type="text" label="City" varname="shippingcity" srcvar="user.city" validate="isnotempty" error="Please enter the city of the recipient's shipping address."/> <widget type="menu" label="State" varname="shippingstate" srcvar="user.state" validate="isstate" default="CA" error="Please select a valid state."> <item label="None" value=""/> <item label="AK" value="AK"/> [...] </widget> <widget type="text" label="Zip Code" varname="shippingzipcode" srcvar="user.zipcode" validate="isnotempty" error="Please enter the zip code of the recipient's shipping addre\ ss."/> <widget type="text" label="Country" varname="shippingcountry" srcvar="user.country" validate="isnotempty" error="Please enter the country of the recipient's shipping address\ ."/> <widget type="text" label="Phone" varname="shippingphone" srcvar="user.phone" validate="isphone" error="Please enter the recipient's phone number, including the area code."/\
<widget type="text" label="Fax" varname="shippingfax" srcvar="user.fax" validate="isphoneorempty" dstvar="cardfax" error="Please enter the recipient's fax phone number, incl\ uding the area code."/> <widget type="rule"/> </form> The widget types themselves are defined in another XML table. Each widget consists of "hide", "display" and "request" handlers, that are defined in XML of course. <widgets> <widget type="text"> <scope varval=""> <getvarval/> <switch val="{formcommand}"> <case val="hide"> <hidden NAME="{widget.varname}" VALUE="{scope.varval}"/> </case> <case val="display"> <TR> <formlabel>{widget.label}</formlabel> <TD> <showerrmsg/> <if><att>widget.secret</att> <then> <censorsecret>{scope.varval}</censorsecret> </then> <else> {scope.varval} </else> </if> </TD> </TR> </case> <case val="request"> <TR> <formlabel>{widget.label}</formlabel> <TD> <showerrmsg/> <INPUT TYPE="TEXT" SIZE="{textsize}" NAME="{widget.varname}" VALUE="{scope.varval}"/> </TD> </TR> </case> </switch> </scope> </widget> [...] <widget type="menu"> <scope varval=""> <getvarval/> <switch val="{formcommand}"> <case val="hide"> <hidden NAME="{widget.varname}" VALUE="{scope.varval}"/> </case> <case val="display"> <TR> <formlabel>{widget.label}</formlabel> <TD> <showerrmsg/> <foreach element="widget"> <ifelement name="item"> <if><eq><att>item.value</att> <att>scope.varval</att></eq> <then>{item.label}</then> </if> </ifelement> </foreach> </TD> </TR> </case> <case val="request"> <TR> <formlabel>{widget.label}</formlabel> <TD> <showerrmsg/> <SELECT NAME="{widget.varname}"> <foreach element="widget"> <ifelement name="item"> <OPTION VALUE="{item.value}">{item.label} <selectif> <eq><att>item.value</att> <att>scope.varval</att></eq> </selectif> </OPTION> </ifelement> </foreach> </SELECT> </TD> </TR> </case> </switch> </scope> </widget> <widget type="header"> <switch val="{formcommand}"> <case val="hide"> </case> <case val="display"> <TR> <TD> </TD> <TD> <CENTER> <H1>{widget.label}</H1> </CENTER> </TD> </TR> </case> <case val="request"> <TR> <TD> </TD> <TD> <CENTER> <H1>{widget.label}</H1> </CENTER> </TD> </TR> </case> </switch> </widget> [...] </widgets> And here are some of the validators, naturally implemented in XML, but calling on a few primitives implemented in C. <validators> <validator name="isany"> 1 </validator> <validator name="isnotempty"> <isnotempty><strip><att>session.{varname}</att></strip></isnotempty> </validator> <validator name="isnewpassword1"> <eq><att>session.{varname}</att> <att>session.newpassword1</att></eq> </validator> <validator name="isyear"> <and><nge><att>session.{varname}</att> <quote>0</quote></nge> <nle><att>session.{varname}</att> <quote>99</quote></nle></and> </validator> <validator name="ismonth"> <and><nge><att>session.{varname}</att> <quote>1</quote></nge> <nle><att>session.{varname}</att> <quote>12</quote></nle></and> </validator> [...] </validators>
Andy McKay wrote:
On May 15, 2002 11:13 am, Chris Withers wrote:
man, you have waaaaaaaaaaaaaaay to much tiem on your hands ;-)
Wow chris is typing sooo fast he cant spell teim properly...
Nah, I just suffer from IFS... Chris
[Lots of Cc: deleted...]
<snip>Hello?! How much stuff... sorry, I didn't even read it</snip>
You should have, it's interesting stuff, better not dismissing it so lightly. -- Two witches watch two watches. Which witch watched which watch? Nicola Larosa - nico@tekNico.net
Don, it sounds like HyperTIES Markup Language addresses some similar purposes in similar ways to Zope Page Templates. There are also some significant differences, which may interest you. ZPT has some distinctive features particularly aimed to promote ease of collaboration between web designers and programmers (or between those two sides of a developer, working with themselves.-) Chief among those features is use of tag attributes for computation hookup - variable access, conditionals, loops, method invocation, etc. By using tags on standard XHTML, the results of adapting a page for hookup with the rest of the application retains the structure and parsability that the designers originally created. The original structure is preserved, and conversely, typical design tools preserve foreign tags (generally, ignoring them, maybe even colorizing them distinctively), so we avoid disruption in both directions. (It's a pleasure to be able, as a programmer, to take designer's markup and add the right tags, capitalizing on their designs without disrupting them - and to be able to trade the result back and forth, evolving it without having to retrofit changes again and again. I've done this, on customer projects, and was **not** able to do so when we were using DTML.) The issue about "order of tags" seems to be a misunderstanding - the order being described was order of _execution_ - precedence of the tags, to serve the programmers purpose. For more information, see the TAL (Template Attribute Language) specification: http://dev.zope.org/Wikis/DevSite/Projects/ZPT/TAL%20Specification%201.4 The discussion about "procedural versus templating language" may be based on misuse of terms. I think the issue is block-structured versus page/layout markup. It's common to see templating languages that hookup to underlying programming logic by interspersing block-structured code with page-layout directives. Both in principle and as someone who has used a few of these systems, i think they're fatally flawed for anything more than simple layouts. I know that we *can* accomplish elaborate layouts with such systems - god knows, i've done so. I'm just saying they're unnecessarily hard to unravel, change, and debug - because of an "impedence mismatch", where the structuring of one syntax does not obey the structuring of the other. (Recently i posted something equating this intermixing of structural boundaries with undisciplined use of goto in a high-level language - both defeat many of the benefits of clean structuring. This sort of thing is especially galling, eg in DTML, to those of us that came to Zope with an appreciation of Python for its tendency to exceptionally readable, comprehensible code. I also like lisp, particularly for its elementary syntax and susceptibility to programmatic manipulation, but have been won over beyond lisp by python's economies...) Using XML for your language, as i gather HyperTIES does, avoids the structural disruptions, since XML is strict and consistent with HTML. By sticking with HTML, however, we also leverage pervasive expertise - at least being able to use the efforts of the numerous folk familiar with HTML, and in some cases enabling them to do various levels of their own programming hookup with ZPT. There may seem to be ways we restrict our templating language by using HTML, and in some ways, that's right. In fact, that's another, very important benefit, here. The Zope environment provides numerous ways to express elaborate business logic, ways that are much easier to read and process than any markup-oriented language can provide. (These ways include things like web-editable python scripts, standalone "external" methods, and product methods, as well as SQL methods and so forth.) Markup is best used for presentation - the only procedural logic we want in our templates should be presentation specific, or calls out to tap the results of the application business logic, underneath. Conversely, the business logic should not have to produce presentation - just provide the fodder for it. ZPT sits in this balance, very nicely i think. I haven't been following the conversation very carefully, so don't know whether or not you've gotten acquainted with ZPT - the canonical place is: http://dev.zope.org/Wikis/DevSite/Projects/ZPT Considering the approach of HyperTIES, you may find a lot to like there. -- Ken Manheimer klm@zope.com
On 5/9/02 9:39 PM, "Marc Lindahl" <marc@bowery.com> wrote:
Yecch!
Why not: <if ...> True stuff </if> <else> False stuff </else>
If leaves around boolean result, else picks up the most recent one... It's like they push on a stack so you can nest them.... Something like that?
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. 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. -- Jeffrey P Shell www.cuemedia.com
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 following is from Paul Graham's web page, telling how Common Lisp defines cond, compared to ARC. And how ARC defines if in terms of cond. Also notice how "it" is bound to the result of the test expression inside of "if". -Don ==== cond split into cond + do (progn) CL: (cond ((a x) (princ "!") (b x)) ((c x) (d x)) (t (e x))) Arc: (cond (a x) (do (pr "!") (b x)) (c x) (d x) (e x)) - Usually use if, which binds it: (if (a x) (car it)) The core of Arc is much the same as the core of McCarthy's original 1960 Lisp. The operators eval, car, cdr, cons, and quote work the same when applied to symbols and lists (the only data types in the 1960 paper), except that car and cdr generate errors when applied to nil. The one operator we changed is cond. McCarthy, who wanted to keep his axioms to a minimum, buried progn within cond. That worked for his examples, but for programming in general you soon find you need a progn separate from the implicit progn of cond. Having an implicit progn in cond means every cond clause has to have an extra pair of parentheses. McCarthy said later that he thought he had gotten cond wrong, that it used too many parentheses, and this may be what he meant. Arc's cond doesn't have an implicit progn, and so you don't need the parentheses around each clause. We also omitted the t in the default clause, which seemed to be an onion. The example in the slide shows the same code in Common Lisp and in Arc. (Arc's do is Common Lisp progn, and pr is Common Lisp princ.) In Arc, cond is a low-level operator, used mainly in macroexpansions. Most of the time programmers use if, which is exactly the same, except that within a successful then-expression, the variable it will be bound to the result of the test-expression. ====
on 5/10/02 12:47 AM, Jeffrey P Shell at jeffrey@cuemedia.com 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....
On 5/10/02 9:25 AM, "Marc Lindahl" <marc@bowery.com> wrote:
on 5/10/02 12:47 AM, Jeffrey P Shell at jeffrey@cuemedia.com 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> <title>XSLT 1.1 required</title> </head> <body> <p>Sorry, 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/expression">Yay!</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 += '<em>No 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
on 5/10/02 1:18 PM, Jeffrey P Shell at jeffrey@cuemedia.com scrivened:
Still, yuck. It's - for better or worse - not a valid XML way. Even XSLT does things like this:
<snip> Well that makes this look palatable:
You would at the very least need something like: <condition> <if>...</if> <elif>...</elif> <else>...</else> </condition>
Still I think the concept of TAL having some kind of 'stack' for condition results makes sense and is worth exploring... Could yield better logical constructs, and things like case statements.
Marc Lindahl wrote:
Still I think the concept of TAL having some kind of 'stack' for condition results makes sense and is worth exploring... Could yield better logical constructs, and things like case statements.
Sorry, but I don't see a 'stack' of any sort being easy to explain to a newbie or not programmer. cheers, Chris
on 5/13/02 3:15 PM, Chris Withers at chrisw@nipltd.com scrivened:
Marc Lindahl wrote:
Still I think the concept of TAL having some kind of 'stack' for condition results makes sense and is worth exploring... Could yield better logical constructs, and things like case statements.
Sorry, but I don't see a 'stack' of any sort being easy to explain to a newbie or not programmer.
I'd disagree - HTML has this concept - for example the way table tags inherit properties. Key is that the 'stack' idea is hidden within the hierarchy idea.
Marc Lindahl wrote:
Sorry, but I don't see a 'stack' of any sort being easy to explain to a newbie or not programmer.
I'd disagree - HTML has this concept - for example the way table tags inherit properties. Key is that the 'stack' idea is hidden within the hierarchy idea.
Hmmm... do you knnow how many people get confused by that specifc issue? Especially as different browsers inherit different levels of formatting... cheers, Chris
on 5/14/02 4:43 AM, Chris Withers at chrisw@nipltd.com scrivened:
Marc Lindahl wrote:
Sorry, but I don't see a 'stack' of any sort being easy to explain to a newbie or not programmer.
I'd disagree - HTML has this concept - for example the way table tags inherit properties. Key is that the 'stack' idea is hidden within the hierarchy idea.
Hmmm... do you knnow how many people get confused by that specifc issue? Especially as different browsers inherit different levels of formatting...
I think the confusion on that issue with tables has only to do with the bugs in the implementation on certain browsers. Which points to the inability of supposedly real programmers to understand stacks, parsing, state machines - not the poor HTML coders :) - if you read diatribes by the layout guys (like alistapart) you'll see their frustration is based that the heirarchy (stacking) isn't working as expected.
Don't even get me started on that one! I don't think this is neccessarily a criticism of Zope though, or ZPT. We are all human, and apt to err. ZPT is imperfect, but the balance of opinion would appear to be that it is better than what has gone before. It is irritating to learn a new syntax, it is hard to read (Some of us design Zope sites TTW...) the flow of logic is obscure and sometimes downright impossible to follow, but people seem to work around it anyway. Much the same is true of the failure of Netscape, Microsoft, and all the others to even read, let alone follow, the defined standards on, well, just about anything. There is one important point being missed here though - Why should the non-programmers be interested in the coding? If the concept of a stack is to hard for them to understand, so what? Shouldn't they be designing plain pages, which the coded templates simply render? Or are we now passing off the task of designing look and feel to non-experts? Anyone want to find another area of the industry to dilute? Now, return to the Marc and Chris' last comments, why exactly can't leading browsers follow standards, because they are written by people that can't program, in languages that were made "simple" for the sake of "non-experts". I put it to you that this argument is invalid and of no merit. Adrian... ----- Original Message ----- From: "Marc Lindahl" <marc@bowery.com> To: "Chris Withers" <chrisw@nipltd.com> Cc: "zope-dev" <zope-dev@zope.org> Sent: Tuesday, May 14, 2002 4:33 PM Subject: Re: [Zope-dev] Re: stacks != easy to explain
on 5/14/02 4:43 AM, Chris Withers at chrisw@nipltd.com scrivened:
Marc Lindahl wrote:
Sorry, but I don't see a 'stack' of any sort being easy to explain to
a
newbie or not programmer.
I'd disagree - HTML has this concept - for example the way table tags inherit properties. Key is that the 'stack' idea is hidden within the hierarchy idea.
Hmmm... do you knnow how many people get confused by that specifc issue? Especially as different browsers inherit different levels of formatting...
I think the confusion on that issue with tables has only to do with the bugs in the implementation on certain browsers. Which points to the inability of supposedly real programmers to understand stacks, parsing, state machines - not the poor HTML coders :) - if you read diatribes by the layout guys (like alistapart) you'll see their frustration is based that the heirarchy (stacking) isn't working as expected.
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org 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 )
From: "Marc Lindahl" <marc@bowery.com> <snip>
in the implementation on certain browsers. Which points to the inability of supposedly real programmers to understand stacks, parsing, state machines - not the poor HTML coders :) - if you read diatribes by the layout guys (like alistapart) you'll see their frustration is based that the heirarchy (stacking) isn't working as expected.
So surely it would be bad to introduce a similar bug opportunity? Adrian Hungate wrote:
would appear to be that it is better than what has gone before. It is irritating to learn a new syntax,
Think of the benefits ;-)
it is hard to read (Some of us design Zope sites TTW...)
Un-learn that habit too. It's so nice having things like search & replace and syntax highlighting afterall...
the flow of logic is obscure and sometimes downright impossible to follow,
Urm? Gimme some examples so I can help...
There is one important point being missed here though - Why should the non-programmers be interested in the coding? If the concept of a stack is to hard for them to understand, so what? Shouldn't they be designing plain pages, which the coded templates simply render?
See the TASSLE discussion over on the ZPT list ;-)
Or are we now passing off the task of designing look and feel to non-experts? Anyone want to find another area of the industry to dilute? Now, return to the Marc and Chris' last comments, why exactly can't leading browsers follow standards, because they are written by people that can't program, in languages that were made "simple" for the sake of "non-experts".
I put it to you that this argument is invalid and of no merit.
I don't even understand the point you're missing ;-) *grinz* Chris
From: "Chris Withers" <chrisw@nipltd.com>
it is hard to read (Some of us design Zope sites TTW...)
Un-learn that habit too. It's so nice having things like search & replace
and syntax
highlighting afterall...
Now, this is an interesting statement and one I have heard often, and that I throughly disagree on. Correct me if I am wrong, but isn't the TTW part is what is one of the strenghts of Zope - I'd say that the fact that Zope uses TTW editing has had a major impact on the kind of templating mechanism and infrastructure that Zope, as opposed to much of the competition, offers out of the box. I myself choose over iPlanet and Oracle Application Server, because Zope had a lot of infrastructure IN PLACE that is needed for development, as opposed to say, Oracle Application Server, where I had to write everything from scratch, including lots of the admin interfaces. As an example, the only real competitior that Zope had at the time I was loking for web-app frameworks was Roxen Challanger, where Roxen gives away the Roxen Webserver as GPL, but sells their TTW development environment for about 5000 US$/developer. So, TTW has it's merits. Now, Roxen has FILESYSTEM based development as well, which might be what we all want as well, but *not instead*. Just because ChrisW has gone beyond TTW editing, does not make it a Bad Thing(tm) in general :) Going back to the "ZPT is good/bad" and "DTML is ok/evil" discussion, something hit me a couple of weeks ago while chatting on #zope: It seems that ZPT is mostly aimed at the Page Designer, whereas DTML is mostly aimed at the Developer. Would this be a correct assesment of the situation? /dario
Hi Dario, Dario Lopez-Kästen wrote:
Correct me if I am wrong, but isn't the TTW part is what is one of the strenghts of Zope -
Well, no, not really. Being able to edit stuff remotely is where Zope's real strength lies. WebDAV and FTP are much better than using sucky HTTP forms to do this ;-)
Just because ChrisW has gone beyond TTW editing, does not make it a Bad Thing(tm) in general :)
I challenge you to justify how editing in a text box is better than using a full text editor, given that both can be used remotely ;-)
It seems that ZPT is mostly aimed at the Page Designer, whereas DTML is mostly aimed at the Developer. Would this be a correct assesment of the situation?
DTML didn't have a clue who it was aimed at, which was it's main problem ;-) *grinz* Chris
Correct me if I am wrong, but isn't the TTW part is what is one of the strenghts of Zope -
Well, no, not really. Being able to edit stuff remotely is where Zope's real strength lies. WebDAV and FTP are much better than using sucky HTTP forms to do this ;-)
Babies..... bathwater.....
Just because ChrisW has gone beyond TTW editing, does not make it a Bad Thing(tm) in general :)
I challenge you to justify how editing in a text box is better than using a full text editor, given that both can be used remotely ;-)
Hmm... now if I can only find an editor that is worth me spending my valuable time trying to make it do what I want, instead of what it wants for my code.... Or there are those nice little text boxes... they don't assume they know better than me...
It seems that ZPT is mostly aimed at the Page Designer, whereas DTML is mostly aimed at the Developer. Would this be a correct assesment of the situation?
DTML didn't have a clue who it was aimed at, which was it's main problem ;-)
Hmm... strange then that I have used (as have many others) it to produce some very complex (And some think atractive and even elegant) sites. I had always assumed it was aimed at people who wanted to design websites with some server side inteligence - Seems a logical assumption, after all that is what it allows.
*grinz*
Chris
Well, no, not really. Being able to edit stuff remotely is where Zope's real strength lies. WebDAV and FTP are much better than using sucky HTTP forms to do this ;-)
The fact that Zope has a TTW interface indicates that the software itself has the opinion that TTW is valuable - otherwise it would not be in there. So this statement is at odds with the software itself (in other words, it's a wish...)
Dario Lopez-Kästen wrote: [snip]
It seems that ZPT is mostly aimed at the Page Designer, whereas DTML is mostly aimed at the Developer. Would this be a correct assesment of the situation?
I think that assesment is mostly right. It's definately right on the ZPT part. As ChrisW mentioned, DTML wasn't really sure about where it sat at the family dinner table. ZPT is best used by the Dreamweaver crowd, and frankly, from within tools like Dreamweaver. It is pretty verbose for being used TTW (but the TTW environment could be improved over time to help on this, e.g. w/ a colorizing/editable DIV or textarea). FWIW, the ZPT list is discussing a proposal now for moving the programming in ZPT out of the "HTML" page and into...CSS! It's a really interesting proposal, IMO. It might address some of the concerns mentioned here, about verbosity, scanning the page looking for programming etc. And it is sure to raise some new concerns. :^) Check out the thread here: http://lists.zope.org/pipermail/zpt/2002-May/003303.html Let the fun begin... --Paul
Whereas XML attributes, order indeterminisim, slots, METAL and templates are? Adrian... ----- Original Message ----- From: "Chris Withers" <chrisw@nipltd.com> To: "Marc Lindahl" <marc@bowery.com> Cc: "zope-dev" <zope-dev@zope.org> Sent: Monday, May 13, 2002 8:15 PM Subject: [Zope-dev] stacks != easy to explain
Marc Lindahl wrote:
Still I think the concept of TAL having some kind of 'stack' for
condition
results makes sense and is worth exploring... Could yield better logical constructs, and things like case statements.
Sorry, but I don't see a 'stack' of any sort being easy to explain to a newbie or not programmer.
cheers,
Chris
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Adrian Hungate wrote:
Whereas XML attributes, order indeterminisim,
...Solved by making it absolutely clear what order stuff executes in. If I was training people, I'd tell them to write it in that order too...
slots, METAL and templates are?
This is all METAL. METAL is not as simple or robust as it could be, but you don't have to use it ;-) Still, once explained, most people seem to get it pretty quickly... cheers, Chris
From: "Chris Withers" <chrisw@nipltd.com> To: "Adrian Hungate" <adrian@haqa.co.uk> Cc: "Marc Lindahl" <marc@bowery.com>; "zope-dev" <zope-dev@zope.org> Sent: Wednesday, May 15, 2002 1:32 AM Subject: Re: [Zope-dev] stacks != easy to explain
Adrian Hungate wrote:
Whereas XML attributes, order indeterminisim,
...Solved by making it absolutely clear what order stuff executes in. If I was training people, I'd tell them to write it in that order too...
You can't make the order of XML attribute execution clear, because they are defined as unordered. If you're using ordered attributes, then you're not using XML. -Don
whatever... Don Hopkins wrote:
From: "Chris Withers" <chrisw@nipltd.com> To: "Adrian Hungate" <adrian@haqa.co.uk> Cc: "Marc Lindahl" <marc@bowery.com>; "zope-dev" <zope-dev@zope.org> Sent: Wednesday, May 15, 2002 1:32 AM Subject: Re: [Zope-dev] stacks != easy to explain
Adrian Hungate wrote:
Whereas XML attributes, order indeterminisim,
...Solved by making it absolutely clear what order stuff executes in. If I was training people, I'd tell them to write it in that order too...
You can't make the order of XML attribute execution clear, because they are defined as unordered.
If you're using ordered attributes, then you're not using XML.
-Don
Adrian Hungate wrote:
Whereas XML attributes, order indeterminisim,
Chris Withers wrote:
...Solved by making it absolutely clear what order stuff executes in. If I was training people, I'd tell them to write it in that order too...
Don Hopkins wrote:
You can't make the order of XML attribute execution clear, because they are defined as unordered.
If you're using ordered attributes, then you're not using XML.
Indeed, and if your indentation is meaningful in your C source-code, you're not using C. However, that doesn't negate the benefit of a consistent coding style. -- Steve Alexander
From: "Steve Alexander" <steve@cat-box.net> Subject: Re: [Zope-dev] stacks != easy to explain
If you're using ordered attributes, then you're not using XML.
Indeed, and if your indentation is meaningful in your C source-code, you're not using C.
However, that doesn't negate the benefit of a consistent coding style.
Indentation style and the definition of XML are two different things. The XML spec clearly states that attributes are defined as unordered. So any XML editors or tool might rightfully reorder those attributes, thus mangling the meaning of any so-called XML code that depends on attribute order. Any so-called XML tool that depends on the order of attributes incorrect, and has a fundamental design flaw because it deviates from the agreed-upon standard. Just as any so-called C compiler that depends on indentation style is incorrect. -Don Reference: 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.
[Lots of Cc: deleted] My turn...
So any XML editors or tool might rightfully reorder those attributes, thus mangling the meaning of any so-called XML code that depends on attribute order.
The so-called XML code does *not* depend on attribute order.
Any so-called XML tool that depends on the order of attributes incorrect, and has a fundamental design flaw because it deviates from the agreed-upon standard.
The so-called XML code does *not* depend on attribute order. The so-called XML code evaluates attributes in a prespecified order, whatever the attribute order in the so-called XML code itself.
Just as any so-called C compiler that depends on indentation style is incorrect.
That's why it's so-called Python. ;^) -- Two witches watch two watches. Which witch watched which watch? Nicola Larosa - nico@tekNico.net
Don Hopkins wrote:
Indentation style and the definition of XML are two different things. The XML spec clearly states that attributes are defined as unordered. So any XML editors or tool might rightfully reorder those attributes, thus mangling the meaning of any so-called XML code that depends on attribute order. Any so-called XML tool that depends on the order of attributes incorrect, and has a fundamental design flaw because it deviates from the agreed-upon standard. Just as any so-called C compiler that depends on indentation style is incorrect.
...which is precisely why the order of attributes in ZPT source code doesn't matter and why the order of execution of attributes is rigidly defined by ZPT, rather than being that of their order in the source. Anyone got a spare Dime Bar? Chris
Reference:
...no one cares.
I believe what is trying to be explained is that ZPT provides a certain sequence for attribute *processing*, which begins *after* the template is parsed (like unordered keyword arguments in Python). How they are ordered in the source file is irrelevant, but by ordering them in the precise way they will be processed is recommended to aid in the understanding of what will happen. If you do see a concrete example of how and where this occurs that coincides with a breach from the XML spec, please post this to the list for us to see, so that the proper avenues of discussion, hacking, and problem resolution can be made. ZPT is nowhere near complete, and will surely tighten up with time. Regards, Eron On Thu, 2002-05-16 at 10:32, Don Hopkins wrote:
From: "Steve Alexander" <steve@cat-box.net> Subject: Re: [Zope-dev] stacks != easy to explain
If you're using ordered attributes, then you're not using XML.
Indeed, and if your indentation is meaningful in your C source-code, you're not using C.
However, that doesn't negate the benefit of a consistent coding style.
Indentation style and the definition of XML are two different things. The XML spec clearly states that attributes are defined as unordered. So any XML editors or tool might rightfully reorder those attributes, thus mangling the meaning of any so-called XML code that depends on attribute order. Any so-called XML tool that depends on the order of attributes incorrect, and has a fundamental design flaw because it deviates from the agreed-upon standard. Just as any so-called C compiler that depends on indentation style is incorrect.
-Don
Reference:
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.
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org 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 ) --- [This E-mail scanned for viruses by Declude Virus]
--- [This E-mail scanned for viruses by Declude Virus]
Don Hopkins <xardox@mindspring.com> wrote:
Chris Withers" <chrisw@nipltd.com> wrote:
...Solved by making it absolutely clear what order stuff executes in. If I was training people, I'd tell them to write it in that order too...
You can't make the order of XML attribute execution clear, because they are defined as unordered.
If you're using ordered attributes, then you're not using XML.
What Chris means (and it's specified in the TAL documentation) is that for instance "define" attributes are executed before "repeat" attributes. Of course we all know that XML attributes can be reorganized by any parser or whatever. This is not what is meant here. Florent -- Florent Guillaume, Nuxeo (Paris, France) +33 1 40 33 79 87 http://nuxeo.com mailto:fg@nuxeo.com
From: "Marc Lindahl" <marc@bowery.com>
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
Don Hopkins wrote:
From: "Marc Lindahl" <marc@bowery.com>
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
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/id">an ID</td> </tr> ...can also be written as: <tal:x repeat="x xes"> <tr> <td><tal: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
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/id">an ID</td> </tr>
...can also be written as:
<tal:x repeat="x xes"> <tr> <td><tal: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: <p>Error Message (may be replaced)</p> <form action=.> Name: <input type=text name=name><br/> Type: <input type=checkbox name="social_skills" value="nerd" checked>nerd <input type=checkbox name="social_skills" value="geek">geek <input type=checkbox name="social_skills" value="mundane">mundane ... </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 | nothing">Error Message</p> <form action=.> Name: <input type=text name=name tal:attributes="name request/name|nothing"><br/> 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 - Zope-Dev@zope.org 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 )
Jim Penny wrote:
...can also be written as:
<tal:x repeat="x xes"> <tr> <td><tal: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:
<p>Error Message (may be replaced)</p> <form action=.> Name: <input type=text name=name><br/> Type: <input type=checkbox name="social_skills" value="nerd" checked>nerd <input type=checkbox name="social_skills" value="geek">geek <input type=checkbox name="social_skills" value="mundane">mundane ... </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 | nothing">Error Message</p> <form action=.> Name: <input type=text name=name tal:attributes="name request/name|nothing"><br/>
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
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-in>s with <dtml-if>s to the same HUGE sequence (a sql query, IIRC), with <dtml-in>s 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.
On 5/10/02 4:53 AM, "Chris Withers" <chrisw@nipltd.com> 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/id">an ID</td> </tr>
...can also be written as:
<tal:x repeat="x xes"> <tr> <td><tal: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/
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:seq">else</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
Jim Penny <jpenny@universal-fasteners.com> 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:fg@nuxeo.com
On Sat, May 11, 2002 at 02:55:23PM +0000, Florent Guillaume wrote:
Jim Penny <jpenny@universal-fasteners.com> 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" ?
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:fg@nuxeo.com
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org 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 )
Jim Penny <jpenny@universal-fasteners.com> wrote:
Are you referring to what I call "magic boolean attributes" ?
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:fg@nuxeo.com
Florent Guillaume wrote:
Jim Penny <jpenny@universal-fasteners.com> wrote:
Are you referring to what I call "magic boolean attributes" ?
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
Shane Hathaway <shane@zope.com> 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.
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:fg@nuxeo.com
On Mon, May 13, 2002 at 03:32:21PM -0400, Shane Hathaway wrote:
Florent Guillaume wrote:
Jim Penny <jpenny@universal-fasteners.com> wrote:
Are you referring to what I call "magic boolean attributes" ?
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.
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 - Zope-Dev@zope.org 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 )
On 5/13/02 1:51 PM, "Jim Penny" <jpenny@universal-fasteners.com> wrote:
On Mon, May 13, 2002 at 03:32:21PM -0400, Shane Hathaway wrote:
Florent Guillaume wrote:
Jim Penny <jpenny@universal-fasteners.com> wrote:
Are you referring to what I call "magic boolean attributes" ?
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.
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)?
Boolean HTML Attributes perhaps? From TAL/HTMLTALParser.py :: BOOLEAN_HTML_ATTRS = [ # List of Boolean attributes in HTML that may be given in # minimized form (e.g. <img ismap> rather than <img ismap="">) # From http://www.w3.org/TR/xhtml1/#guidelines (C.10) "compact", "nowrap", "ismap", "declare", "noshade", "checked", "disabled", "readonly", "multiple", "selected", "noresize", "defer" ] You should mention that these only get rendered in the classic HTML way when a page template is in HTML mode (content type equals 'text/html'), which I presume is the default. -- Jeffrey P Shell www.cuemedia.com Industrie Toulouse on Zope http://radio.weblogs.com/0106123/categories/zope/
participants (18)
-
Adrian Hungate -
Andy McKay -
Chris Withers -
Dario Lopez-Kästen -
Don Hopkins -
Eron Lloyd -
Evan Simpson -
Florent Guillaume -
Jeffrey P Shell -
Jim Penny -
Ken Manheimer -
Leonardo Rochael Almeida -
Marc Lindahl -
Nicola Larosa -
Paul Everitt -
Shane Hathaway -
Steve Alexander -
Tim Hoffman