[Zope-dev] Re: [ZPT] Order of attribute execution Feature Request

[Jim Penny]

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 )
>