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

[Evan Simpson]

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