[Zope-dev] HiperDOM & xmlc

[Spicklemire, Jerry]

There are a few things I'm trying to understand about the xmlc-like
Templates proposal. First :

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

http://lists.zope.org/pipermail/zope-dev/2000-September/006893.html


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

http://lists.zope.org/pipermail/zope-dev/2000-September/006958.html

OK, point taken, but it's not quite that simple. In the end, isn't that why
artist do design, and coders code? One of the primary purposes in a complete
Content Management System is to distill the presentation standard in a way
that can be "layered" over any content. This principle doesn't stop at a
clearly delineated "visual" line.

Leaving the page layout "as is", which is what it sounds like you are
suggesting, is even worse than doing the job right at the "cast into code"
stage. If you leave the ugly HTML ugly, it will still be ugly next time it
gets updated, but it will be much less useful in the meantime. Worse, it's
likely to get uglier over time. Have you ever seen a baby rhinocerous?

To me the real solution is to clean up the layout, converting hard coded
"virtual" lists into real lists, etc., while painstakingly preserving the
visual design. That clean, codified version can then be leveraged to the
utmost during it's production life, and still be fed back to the designer at
design update time. This can be easily done today in the form of a static
HTML file, simply by calling the Zope URL of the base template, and hitting
"save as". With the proposed xmlc-ish Template, the "snapshot" step should
not be needed, which is great! 

Granted, if the person who distills the design into clean, reusable HTML /
DTML / XML hasn't done the job well, incorporating the changes of the
updated version may well be a nightmare. On the other hand, if this crucial
step is done well, adapting the base template to match the "new vision"
should in fact be much easier the second time.

I think a large part of the confusion comes from where we each draw the
conceptual line regarding what is "visual" and what is best handled as
"code". An anchor tag is, after all, just a pointer to some related stuff,
not the actual physical location of anything. 

If making it easy for visual folks to avoid this basic fact is the driver
here, there's a much larger problem looming in the immediate XML future . .
.

Also, the idea of presenting a place holder sounds a lot like :

"As for cases where a dataset is displayed, such as by a ZSQL query, perhaps
a single "dummy" row, or cell, could stand in for design purposes."

http://www.zope.org/Resources/Mozilla/ZWiki/IDEs

Is that what you mean? Is the "dummy" stuff intended to resemble the final
content, or just to mark an insertion point? Might it be possible to make
place holders in the form of anchors (links) to DTML Methods, or other
appropriate forms of native Zope elements, so that DreamWeaver, et. al. can
pull down a "real" item, rather than having a hard coded "stuff goes here"
label? That sounds advantageous to me, in terms of validating a visual
design.

Groping toward grokking,
Jerry S.