...

Paul Everitt wrote: o Allow those presentation tools to work by having well-formed markup (e.g. no separation into header and footer)

to which Chris Withers replied: Hmmm... I wonder how refactoring, which _header and _footer were really useful for, will happen now...

The most obvious problem was that _header + _footer idiom was presented in a way that resulted in tags being opened in _header, and cosed in _footer. I personally adopted this as a "Good Example" of how to use Zope, and had created quite a mess for myself before a post on one of the lists pointed out how genuinley horrible this is, from a well-formedness point of view. Duh! Still, it's just not that big a trick to factor out the HEAD tag as a monolith, and insert references to other pieces parts inside the HTML tag that used to be included in _header, but now appears as a "hard coded" element in the "presentation" document. On the surface it may look like you wind up with things more scattered about, but as far as factoring, it's manageable. Even in the worst case, my _headers tended to be made up of references to other elements that had been factored out anyhow. Same applies to _footer, and other items. So, there is a change in mind set, but not on the scale of a tectonic shift. If we can get here:

...

Zope should move to an architecture with clear separation of presentation, data, and logic, with clear concepts in Zope for these tiers and audiences.

it will certainly be worth any adaptation that need to occur. However, I am a bit puzzled regarding:

...

The presentation tier will get a tremendous usability increase by allowing round trip presentation with common tools. This also ensures that Site Designers finish with the same stuff they started with, meaning the programmers don't come in and cast their work into "code".

Folks really do want to use Dreamweaver et. al. to layout Web "pages", that's verifiable. The proposal to meet this need is to "let the designer see what they expect, but swap in a Zopification at run time". That may be enough to fulfill the requirement, but it looks pretty pale from this end. There is a very narrow band of "graphic stuff" that won't need to be thoroughly Zopified ("cast into code") in the process of adapting a designer's work. Most of the stuff that makes a Web site useable, such as menus, navigation bars, etc. must be entirely transformed into lists (tables) and scripts (DTML, Python methods, whatever) on the way to maintainability nirvana. As for real Web Applications, the range is even thinner. The illusion of "round trip editing" may be enforcable this way, and there may in fact be a long range plan to convert to a real implementation, based on DOM, XSLT. If that's sufficient to get past the "let me do it my way" objections of temperamental "Artists", so be it.

...

Site Designers want simple reuse of content within reach of standard tools. For instance, the Site Designer wants a standard copyright "asset" on the bottom of every page.

This is easy enough to provide for, but the proposal seems to imply that a "hard copy" of each "asset" will be inserted in the designed "page", but a Zopification of that asset will appear in the served "page". Of course that's quite feasible with Zope, change an "asset", all instances will be composed, at serve time, to display the updated "asset". Then, all the designers have to do is go back, and hand edit every "dummy" instance that's just there to keep them contented, because those "hard copies" aren't going to be updated, since they are not accessible by Zope. What has been gained here?

...

Site Designers will create XHTML Template objects that control

This sounds great, but are these the same folks who can't live without their Dreamweaver? Now they're going to design XHTML Templates? My guess is that the designer will create an HTML "page", and a Zope jockey will tuck some references inside some tags that point to other goodies that were concocted far from the gaze of the "designer", and essentially override the original. Hopefully the designer won't notice those new little gotchas hiding in the tags, and will leave them where they are. Can you say "element level locking"?

...

XHTML Templates will be complete, well-formed HTML that look like a resource will look when the XHTML Template is applied to it. There will be no "source vs. rendered" issue.

Except for the "dummy assets" which will only be an "artists conception" of the rendered "resource", if I'm getting this right.

...

The XHTML Template architecture will facilitate re-use by allowing blocks in the XHTML Template to be named as a (component/library/asset) block. As the Site Designer authors and updates the block of XHTML, Zope saves the named block as a separate object in Zope. This named object can then be used in other XHTML Templates.

Will it be up to the designer then, to see that "blocks" are well formed? That shouldn't be too much to ask. So Zope will recognize the "block" objects, update them when they are changed, and make them available to the designer for reference in other "pages"? So now the designer has mastered the concept of something resembling a "Serve Side Include"? And is this all going on in Dreamweaver, or GoLive, or wherever the designer lives? The concepts sound fabulous and amazing, but as you can see, there are points for clarification. I truly hope this can be done, but unless the editor environments simultaneously develop some remarkable new abilities to interpret a DOM, and interact with a live server instead of by writing directly to local copies of HTML files, it sounds pretty tough. Always Zopeful, Jerry S.