[Zope] - XML-style DTML code

[Christopher G. Petrilli]

On Fri, Jan 29, 1999 at 09:30:42PM -0800, Gabe Wachob wrote:
> Perhaps this is retreading old territory, but if the goal is to have DTML that
> "looks like" XML, I would say either make it XML or don't. It seems like it
> would be too confusing to those of us familiar with XML to try to get used to a
> "almost-XML" syntax.

Well, actually I've figured out a way to make it well-formed, and
largely compliant without having to add in all the XSL parsing BS that
isn't ready for prime time yet, in my opinion.  Remember, the goal is to
get 99% of the functionality for 1% of the effort... I'm lazy, and well,
if you wanna write it, please feel free :-)

> Why not do something like:
> 
> <zope:if condition="total_votes">
>     <p>
>         <zope:in var="choices">
>             <zope:var expr="percent_for(_['sequence-index'])" fmt="%2d"/>
>         </zope:in>
>         <br/>
>     </p>
> <zope:else>
>     <em>No votes have been cast yet</em>
> </zope:if>

Well, that's because this is a LOT more than what people feel like
writing most of the time... it also requires a TOTAL rewrite of the
parse, which i ssomething I don't want to do.  The currentl DTML parser,
even with my hacks is substantially faster (in scientific handwaving
sessions) than any XML parser I know... it doesn't do a lot of stuff,
but that's fine, neither does DTML, which it's attempting to fix.

> That's XML which represents HTML (a la XSL-- note the <br/> -- XML doesn't have
> unclosed tags). The only thing that might not work above is inserting & or < ,
> etc. in certain places (they would normally have to be &amp;  or &lt;)

Also this isn't familiar to 99.999% of the populace, not yet anyway.
What I'm trying to accomplish, AGAIN, is to get partway there, as that's
1/100th the work.  As it goes, put your code where your mouth is.

> Then, the DTML interpreter would just be an XML app (and not that complicated I
> would think).

You underestimate ;-) The existing DTML PARSER is only... 1400 lines of
code, INCLUDING a bunch of headers, so probably more like 1000 lines of
code (until you get into the implementation of the commands themselves).

This is something that I've talked a little with Paul about, and I'm
sure it's a great direction to go in... in good time.

> I know there are reasons things weren't done this way -- I'm curious to hear
> what they are.

The existing syntax was written for speed, and for ease of use by
users... also it was written not to break anything.  I've got the same
basic goals + 1 new one... be reasonably editable in a normal HTML
editor... not be fully compliant with Interleaf's SGML editor so that
full DOM trees can be built.  WE're just not THERE yet, maybe one day,
and I'm sure everyone would be happy to SEE the code for it... but I
have a gut feeling that it's a lot more handwaving than reality.

Chris
-- 
| Christopher Petrilli
| petrilli@amber.org