[Zope-dev] HiperDOM & xmlc

[Spicklemire, Jerry]

Hi Zope Gurus,

After looking over all the HiperDOM / xmlc stuff I think I'm starting to
"get it". I'll just summarize the things that ring especially true for me,
with some comments

Re. letting HTML "Page" Designers use familiar tools:

"Note that XMLC depends on legal HTML/XML markup that will not interfere
with other uses of the tags. HTML browsers are required to ignore tags and
attributes that they do not understand or use."

 http://staff.plugged.net.au/dwood/xmlc/dynamic.html#sample_html

So, xmlc seems to be an alternative solution to the original motivation
behind embedding DTML within HTML Comment / Server Side Include style tags.
The convention exists, so that's a way Zope can fit in to Zope-unaware HTML
environments. 

"But using external fragments ("includes") is not a natural idea for web
designers. One of the main points of this fuss is to allow them to create
the templates in something like Dreamweaver."

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

However, it's hard to imagine that Web "Designers" can survive the XML wave
without becoming comfortable with inclusions. Doesn't the current version of
Dreamweaver have "folding" capability to "collapse" inclusions, such as
Javascript, and even entire tables, so only a pair of tags is displayed on
the screen? No doubt this feature will quickly become a "must have" item, as
fans of folding editors can attest. The verbosity of XML demands some
solution, and the usability of "folding" is well proven. At that point the
real question is, "If xmlc and DTML can both be easily included, collapsed,
etc., what sort of power and flexibility might be lost with an xmlc-ish
convention?"

Re. changing Bad Habits

"The current "header/footer" fragments are not optimal wrt. modularization,
as tightly coupled stuff ("footer" must close everything that "header"
opened) is separated into different objects."

 http://lists.zope.org/pipermail/zope-dev/2000-September/006907.html
 
Certainly breaking well-formedness by placing HTML, HEAD, BODY, etc. in
standard_html_header, and closing HTML, HEAD, BODY, in standard_html_footer
was a dead end. But it's not at all difficult to package up as inclusions
all the other pieces-parts, while keeping HEAD, BODY, etc. within a
monolithic "wrapper". No doubt a multitude of other common DTML sins can
likewise be mended with diligent well-formedness.

"Of course you can already use "includes" which are valid XML, such as a
single row or cell of a table (for example, the navbar of a complex site)."

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

The perceived "problem" with this approach is that the Designer sees
"nothing" where these items will be inserted. Actually, in edit mode they
can see a dtml-var tag. Yes, this can be confusing for Designers, but use of
inclusions is not really new, nor isolated to Zope. Anticpating "the
inclusion thing" will remain a persistent problem is based on the assumption
that Designers won't "learn to love" inclusions, which seems unlikely. 

Re. kludging Zope to do "what they want"

Ideally, Zope's native ftp server can deliver DTML inclusions, which
DreamWeaver, et. al. can "cache" for display purposes. Can Zope's native ftp
server be taught to recognize such requests, and respond with a reasonable
(rendered) facsimile, even if some resources are not currently available?
That should keep visually oriented folks happy, since they'll be able to see
a mock-up, at least. If that's possible, the little gotcha of Dreamweaver
wanting to write back after updating might be handled politely too?

Meeting this need one way or another is the whole point of the "round trip",
edit vs. rendered discussion. So much for speculation about how a
hypothetical SuperZope might learn to recognize requests from an editing
tool, as opposed to some other ftp client. I know, ftp is not a smart
protocol . . .

Re. anti-inclusions, HTML "dummies"

"It is much better to have a module that contains both the page prolog and
epilog and a placeholder for the actual content, maybe filled in with sample
text that later is replaced by the content, i.e. a page template. It is good
that you are forced to use well formed XML in your modules."

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

How is the "place-holder HTML that will never be rendered" solution any more
appropriate? Perhaps simply because it's possible, as opposed to the
mythical ftp beast above? It seems less so to me, at first glance. If we're
seriously concerned over Designer reactions to inclusions, what will they
say when we tell, them, "Just put anything there, for now, the system will
handle it?" If they can get used to "subtractions", what's the real problem
with "inclusions"? Aren't collapsed tags Good Enough as placeholders? It's a
"visual" thing?

Of course, I don't have a clear notion of how the xmlc model will change the
way methods are invoked, and the innate capacities of Zope to deliver
flexible solutions in this context. I'm eagerly awaiting a few lucid example
demonstrating that Zope+xmlc is not only cleaner, and better future proofed,
but actually more powerful and flexible than ever. That would be an offer I
couldn't refuse!

Thanks for all the Goodies,
Jerry S.