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