Hi, Jim Fulton wrote:

Robb Shecter wrote:

...

Hi,

I think I saw somewhere that a new / alternate syntax for Zope/DHTML is being thought about or worked on.

I'm not sure what you are refering to.

I don't either. :) I had seen some metnion of something, somewhere.

...

This article compares JSP to a competing template language that does things (IMO) much better:

http://www.servlets.com/soapbox/problems-jsp.html

...For me, the syntax of DHTML is the most difficult aspect of Zope, and is reminiscent of JSP.

Let me qualify that: I don't mean to slam on the DHTML syntax. I just wanted to point out a current discussion going on in the Java world. What I meant by difficult is: I'm not too adept at DTML yet, and one thing that throws me is that there are apparently different "levels" of coding; some statement/commands have their own tags. Some are attributes of a tag. Some are written inside a string as the value of an attribute. And, I find the XML tag endings and dtml markers distracting.

That's interesting.

Good.

From a purely syntactic point of view, this paper, favors a perl-style syntax rather than an HTML-style syntax and argue that page designers would find the perl-style syntax easier to understand. For example, the paper argues that:

#foreach $isp in $isps { The next name is $isp.Name <br> }

is more understandable by web-page designers than:

<foreach item="isp" list="isps"> The next name is <jsp:getProperty name="isp" property="name"/> <br> </foreach>

I find this hard to swallow. Web-page designer's tools will certainly have less trouble with the latter format than with the former.

Hmm - the second one looks like a horror to me. But then, I'm not a web page designer. Also, Webmacro's syntax was chosen to be deliberately non-xml-like, so that it *would* work well with html tools. It avoids the problems of programs choking on, or not displaying unknown tags. The Java servlet list occasionally has messages like "Looking for JSP-aware editors"... AFAIK, that isn't a problem with webmacro.

I certainly prefer:

<dtml-in isps> The next name is <dtml-var sequence-item><br> </dtml-in>

to either of the above.

How about something like: #in $isps { The next name is $item <br> } Somehow this version is easier on the eyes for me - like I can more easily pick out the dynamic bits. I guess the real issue is whether xml syntax is a good thing. I guess there's reasons both for and against it. I do my scripting by hand, usually, so the extra characters required for xml-like seeem to get in the way.

Leaving out syntactical details, I think the paper makes some interesting points having to do with the basic approach of JSP (and ASP). JSP and ASP are fundamentally, though subtley, different from "template languages", like DTML and the languages discussed in the paper.

Yes - true. The paper helps categorize things a bit. - Robb

If you ignore everything after/including Problem #4, this paper transforms quite well if you just replace 'JSP' with 'DTML', 'Java' with 'Python', and 'WebMacro' with 'DTML-entity syntax' :-)

&dtml-foo; (along with <dtml-let>) addresses most of the issues raised by the paper. The remainder already aren't *too* bad in DTML. Still, there are many times when I'd like to be able to do XSLT-style manipulation of pages rather than embedding stuff.

That's an absolutely brilliant idee! One problem that I see with DTML is that is hard to make complex methods in. DTML great for embedding content in a template, thou. Python Methods on the other hand are brilliant for making methods/functions. It would be nice to be able to include inline Python Methods inside a DTML Method/Document, either with <dtml-tags> or &dtml-entities; It would make methods more manageable collecting all related code. Example: <dtml-pymethod> def myfunc(): return super_stylus </dtml-pymethod> <h1>&dtml-id;</h1> <p style="&dtml-myfunc;">This is a super styled message!</p> etc... //Johan

...

...

Still, there are many times when I'd like to be able to do XSLT-style manipulation of pages rather than embedding stuff.

That's an absolutely brilliant idee!

If this was a response to the quoted line which precedes it, you either didn't know what I meant by XSLT or leapt away on a tangent :-) I was talking about treating an HTML page as a DOM tree, and manipulating it with code like:

doc['mybutton'].setAttribute('value', 'Whee!') doc.match('table//p').setContent('This is a paragraph in a table')

Oh, I thought you meant using an XLS sheet to modify the output.

...

It would be nice to be able to include inline Python Methods inside a DTML Method/Document

No! Stop! Aieee! <mantra>separation of code and content. separation of code and content.</mantra>

Oh, well, I see the point. But I seem to end up doing alote of functional things in DTML anyway. On the other hand I always try to put content outside of templates. Templates aren't content. But I still use DTML Methods to implement both Template and Content. I might add that I usualy use Folders as an abstraction for documents (containing content, as dtml methods). And my main template are the index_html (usualy only one in the root). I would say <mantra>separation of code, content, and design...</mantra> //Johan

I will admit that it would be nice to associate a bunch of small Python functions with a Document without having to make a separate Zope object for each function. Perhaps a PythonMethodLibrary object? We'll see.

...

We've considered for some time allowing something like:

<dtml-var a/b>

meaning "insert sub-object b of object a".

This is a good idea, but we haven't agreed on the semantics of the '/'. Some people assume attribute access. Others expect URL traversal, along the lines of what the publisher does. Others want URL traversal *and* publisher-style calling.

Hmm. Both useful. Use a different separator for each? you could even mix-and-match within the same call, I suppose, but it would be a royal pain to debug...

What would also be useful is the ability to put: <dtml-var ../a/b> This would allow you to build a store of library-like objects which can then easily be called from other sub sections of a site. Cheers, Stephen -- Stephen Harrison - stephen@nipltd.com New Information Paradigms - www.nipltd.com