[Zope-dev] HiperDOM & xmlc

[Phillip J. Eby]

At 04:07 PM 9/17/00 -0400, Shane Hathaway wrote:
>
>We think alike.  A few of us tried to present this very solution (with a
>different spelling) to several people here at DC.  They found it quite
>confusing.  I honestly don't know why. :-/
>
>But assuming someone can properly document this without making heads
>hurt and without sounding alarms in the minds of OO folks, maybe the
>right solution is an optional attribute on the opening tag that
>specifies the wrapping template.  If not specified, it would default to
>"standard_page_template".
>
>Of course, the name of the default wrapping template could always be
>overridden by the document class.  Instances of 'NewsDocument', for
>example, might use "standard_news_template".
>

Suppose that you could add to any element an hdom:asset="nameOrPath"
attribute.  When saving a template containing such elements, the content of
the named document is compared against the tagged block in the template
being saved, and against the previous version of the template.  If the
content has not been changed since the last version of the template, but
the asset itself is different, the named portion is silently replaced with
the new version of the asset.  If the content *has* been changed, the
author is given the option of updating the named object with the changed
contents, undoing the change, attempting to merge changes, etc.  If an
asset is named in a template being saved, but no such object exists, it is
automatically created as a peer of the template (and of course it can be
moved higher in the tree for acquisition without breaking the reference).
And last, but not least, if one is creating a new template, and the named
element is empty, it is replaced with the referenced asset.  (Actually, in
practice you'd do almost all of this not by copying XML fragments but by
using DOM objects that were symlink-ish.)

That was a very terse way of describing the idea, but I think that it could
preserve the Zope/programmerish notion of fragments while preserving the
editability of documents.  And it seems to me it would be an easy sell to
any web designer who isn't afraid to manually add an attribute or two to
their code, in exchange for not having to repeat themselves so often.

Yes, you say, but what about the problem you're talking about, where the
wrapper is not well-formed?  Just take the same basic idea and turn it
inside out, and have a hdom:wrapper="nameOrPath" attribute which could be
added to one and only one element within the page.  Anything which is
*outside* (around?) this block is then treated in much the same way I
described for an "asset".  (Meanwhile, assets as previously described would
be usable both inside and outside the central block.)

The effective external behavior of these two attributes, would be to let a
web designer load and save any page or template they wished in the site,
freely making changes to the header, footer, or various embedded elements
thereof, and then save that *one* page, and have those style changes
propagated throughout the relevant areas of the site.  This could
potentially be a "killer feature" for web designers.

The tricky bit is managing UI handling for what happens when they save
their page.  WebDAV and FTP are all very well and good, but unfortunately,
they don't have any convenient way to pop up a dialog box and let you
prompt the user to replace/update things.  You'd have to have this do some
sort of workflow notification, or a way for the designer to go in and
review what things might need to be updated.

Anyway, just thought I'd throw a few more ideas on the fire...  :)