[Zope-dev] XHTML Templates comments from the peanut gallery

[Spicklemire, Jerry]

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