[Zope] <% ... %> ?

[Paul Everitt]

Jim Fulton wrote:
> Some tools, such as Netscape Composer provide minimal
> support.  You can actually select and edit DTML tags.  In fact,
> DTML tags get as much support as FORM tags.

Ironically, Composer doesn't do form tags. :^)
 
> It would be helpful to make hideuosness a little more specific.

Good point.
 
> What makes it hideous?  Is it the noice characters? (!--#)
> Is it the number of shift characters?  Is it the fact that
> DTML don't look like other tags?  Is it the tag in an attribute
> problem mentioned above?

I'd say, in order:

1) It doesn't look like the competition.  (which is largely <% or
inventing their own tags).

2) Excessive noise.

3) When something interesting requires the expr machinery, you can only
do one expression per line.  (Note that this complaint isn't slated to
be solved by a syntax change in DTML, just that it is a common
complaint).
 
> > Tool Support
> > ------------
> >
> > The SSI syntax just happens to enjoy nearly zero support out there.
> > Things like Netscape Composer, Dreamweaver, and Emacs HTML Mode just
> > can't be convinced to handle it nicely.
> >
> > Does anyone view this issue as important?
> 
> Yes.  What would be needed to make HTML (not XML)
> editors happier?

This is the crux of the matter.  It will be a LONNGGG time before XML
editors saturate the market.  Thus, we have two problems:

a. Better syntax that is friendly to HTML authors and HTML editing
tools.

b. Different approach focused on future standards and tools (XML).

This discussion is rightfully being geared back towards (a).

Here's a chance for all of you folks out there with expertise in HTML
tools (Dreamweaver, FrontPage, Cyberstudio, Alpha, Emacs, etc.) to weigh
in.
 
> > 2) Becoming well-formed means the authors can be given hints before
> > saving changes,
> 
> Good point.

Jeffrey gave Jim and me a demo yesterday of how, with the syntax changed
to <dtml-in>, the Alpha editor could be taught all the options for the
in tag and present checkboxes.
 
> > and Zope can do smarter things with structured data on
> > the server.
> 
> I'm not so sure about this one.  Zope has alot of structured
> data now.  For example, it would be pretty easy to find the
> var references in a parsed DTML object, but I'm not sure how much
> that gains you.

Let's say you rename a document.  Nearly all the competition will update
all the references to the document.
 
> > 3) Zope syntax might not be mappable into XML.
> 
> This isn't a problem.

It was a problem for my XHTML proposal.  It isn't a problem for goal (a)
described above.
 
> Here are some more why nots:
> 
>   4) XML is wildly more verbose that HTML and, without tool support,
>      people might find an XML variant of DTML or HTML to be a real pain.

I think we should rush blindly into implementing standards, as I
proposed, then when everybody hates *that* as well, we come up with
something sane. :^)
 
>   5) DTML is used to generate a variety of text output.  While it *is*
>      used mostly to generate HTML, it is used to produce a variety of other
>      formats as well.
> 
> At any rate, I think that an XML variant of (or cousin of) DTML would be
> a great idea.  I expect that DC will do this eventually, if no one else does.
> I'd expect am XML version of DTML to be able to work with any sort of XML
> data, including XHTML.
> 
> I don't think, however, a plan to have an XML variant of DTML should
> prevent us from improving the non-XML version.

Well stated.

--Paul