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