[Zope-dev] HiperDOM & xmlc

[Paul Everitt]

I wanted to step back a few jumps in this thread and point out a few
things...

lalo@hackandroll.org wrote:
> > Our "XHTML Templates Proposal" is at:
> >
> >   http://dev.zope.org/Wikis/DevSite/Proposals/XHTMLTemplatesProposal
> 
> It is not linked on the Proposals FrontPage...

You're right, I'll get that done today.  I just wanted to get some
initial comments from you and others.

> --
> 
> Anyway, at least for HiperDOM I feel comfortable with the word
> "template" because that's what it is about. The two primary
> motivations for the design are:

Ultimately I think that's what is going to work for everybody.

> * You can create the layout with any XML-compliant editor; if
> the template is xHTML, you can use a XHTML-compliant WYSIWYG
> tool. Or, thanks to the modern XML technology, you can use a
> WYSIWYG HTML tool and pass it trough a SGML->XML filter to get
> xHTML.

Right, though our real goal was to make it work with existing, here-now
HTML tools like Dreamweaver and GoLive.

>   Using specialized webdesigners with Zope project has been one
> of the biggest pains in Zope development; we have to take the
> sometimes ugly code generated by the tools they use, usually
> clean it up, then insert the DTML tags in it. Making changes to
> the design is a nightmare.

Yep.  Essentially the programmers "steal" the presentation/view layer
from the designers and convert it to "code".

> * The template looks like the rendered page; if you don't want
> to fire up Zope, or if the application logic is not yet
> finished, you can preview the layout by simply loading the
> template in a browser.

I think this is going to be the breakthrough over all other approaches
out there.  Allowing sample data (your "dummy" attribute) is huge.

The downsides I see to using template;

  o Word processors like Word have a different usage of template.

  o The W3C uses "stylesheet" to cover activity in the presentation/view
tier.

> These goals are similar, but not identical to the ones in the
> proposal. Still, some parts of the proposal felt like extracted
> rigth out of my mind :-)

Actually they are identical.  If my wording wasn't clear I need to
change it.

> I don't feel good about calling the layers "document" and
> "view" or "presentation" and "data" because the "view" is not
> strictly presentation code; invariant (static) parts shared by
> all pages rendered with that template can be in the template.
> As much as we all like to talk about "Web Applications", this
> is not exactly like "normal" application design, where you can
> draw a clear line between presentation and data (or model/view).

Unfortunately we have to make it clear.  That's just the way to world
thinks, and Zope pays the price for being so different on so many
things.  We're trying hard to give people an organizational framework
that is approachable.  Just saying "it's objects" hasn't proven helpful.
:^)

> The only thing I _don't_ feel good about this kind of template
> is that, in practice, we will probably lose the benefits of
> things like <dtml-var standard_html_header> - meaning, when you
> want to change the header of your site, you'll have to edit all
> your templates.
> 
> Of course a site where this is a problem still _can_ use
> "includes" like standard_html_header, but I believe most won't.

One of the reasons it took us so long to get the proposal out is that I
wanted to specify the complete architecture for both documents and
templates.  I thought it imperative to decide how a document is "bound"
to a template and how a template looks at a document.  The first
revisions were for a "Document and Template Architecture" proposal.

I was convinced to drop this and move it to a forthcoming "Document
Architecture" proposal.  The user manual material I wrote for documents
and templates on vacation covered what I consider a response to your
issue above.

Basically, when a document is rendered, a series of rules are applied to
decide which template to use.  The document can specify its template
(perhaps with a meta tag), a folder can decide, an acquired folder can
decide, a ZClass can decide, etc.

Perhaps we need to make progress on the document side...

--Paul