[Zope] <% ... %> ?

[Jim Fulton]

Paul Everitt wrote:
> 
(snip)
> Let me limit the conversation back to your subject line: <% vs. <!--#
> 
> The latter was originally chosen to be like the dominant syntax at the
> time (SSI) and to be "legal HTML". 

It was also an attempt to avoid collisions with HTML tags.  It was also
chosen because DTML tags looked like comments, which was, at the time, 
considered an advantage.  for example, you could view a DTML document
as HTML without the DTML tags showing up.


(snip)

> What are some reasons to consider changing from the SSI syntax?
> 
>   o It's hideous, cumbersome, and everybody hates it
> 
>   o No tools support editing it

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. 
 
>   o It isn't conformant with the direction of HTML
> 
>   o Any others?

It leads to invalid HTML when you need to insert a value into
another tag:

  <a href="<!--#var URL1-->/manage_main">
 
> Let's evaluate the situation in light of these.
> 
> It's Hideous
> ------------
> 
> Yes.

It would be helpful to make hideuosness a little more specific.

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?
 
> 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?  
 
> Future of HTML
> --------------
> 
> What role does SSI play in the future of HTML?  Zero.  Of course,
> neither do any of the alternative syntaxes mentioned previously.
> 
> Thus, I'd like to list some requirements for a future syntax:
> 
> 1) Within reach of "content managers".  I won't budge on this one.  I
> think XSL will have a role in Zope, but *NOT* as a DTML replacement.

I agree.
 
> 2) Reasonably close to DTML.  The current DTML accomplishes some level
> of functionality.  While some small amount might not be permitted in
> some change, or might be permitted in a clumsy way, there should be a
> reasonable match.

Cool.  Of course, someone could write something totally different
from DTML and make it useful in Zope, it just wouldn't be DTML.
 
> 3) Coherent with the HTML future.  We have a choice: invent a syntax
> and, one by one, support every web authoring tool.  Alternatively, we
> can stick to standards and wait for them to support it.
> 
> Proposal
> --------
> 
> _If_ these were the requirements, then I think a reasonable proposal is
> XHTML:
> 
>   http://wdvl.com/Authoring/Languages/XML/XHTML/
> 
>   http://www.w3.org/MarkUp/#future
> 
> XHTML reworks HTML as an XML-compliant language.  Most imporantly, you
> can extend it with new namespaces (like Zope instructions) without
> breaking the DTD, as is the case with ColdFusion et al.
> 
> Why?
> 
> 1) Alledgely it is the future of HTML.
> 
> 2) Becoming well-formed means the authors can be given hints before
> saving changes,

Good point.

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

 
> Why Not?
> 
> 1) A number of differences with HTML might drive people off.
> 
> 2) It isn't here yet.
> 
> 3) Zope syntax might not be mappable into XML.

This isn't a problem.

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.

  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.

Jim

--
Jim Fulton           mailto:jim@digicool.com   Python Powered!        
Technical Director   (888) 344-4332            http://www.python.org  
Digital Creations    http://www.digicool.com   http://www.zope.org    

Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email
address may not be added to any commercial mail list with out my
permission.  Violation of my privacy with advertising or SPAM will
result in a suit for a MINIMUM of $500 damages/incident, $1500 for
repeats.