[Zope-dev] Zopifying an FTP'd/POST'ed HTML

Sin Hang Kin kentsin@macau.ctm.net
Sat, 26 Feb 2000 17:20:17 +0800


In the long run, a xml editor will be able to get the document from zope,
edit it, and update it through webdav. This will solve the
gui editing problem.

The user edit the document with the xml editor and can embeed the dtml tags
inside the xml file to allow dynamic contents.

Zope should take care the versioning : if an older version of xml file is
exist, it will allociate a new version number, and publish the old version
with another url (with versioning). Some new tags should be added to allow
the automatically publish the history, the revision date, md5 etc of the
document. Just like all the W3C documents on the web.

Zope should also take care of publishing the document in multiple ways :
source code, source code with dtml-rendered, html pre page, html tar ball,
pdf, etc. Zope shoule be able to publish a partial sub-tree of the xml doc
with criteria set (adding the root node if necessary).

Zope should goes the way to client-side rendering as far as possible, with
possible fallback facilities: zope should sent the xml file to the client,
with xslt and css to off-load the server. A fallback parameter will then let
the server do the rendering if the client fail to do so.

Currently, zope's dtml syntax prevent it from embeeded in xml files.
Versioning is required for zope to be a content manager. IMHO versioning
should be essential part of all web storage system.

> Has anywone worked on a mechanism for taking HTML documents that are FTP'd
or
> HTTP-POST'ed by end-users and manipulating them into Zopish documents --
> inserting <dtml-var standard_html_header> and <..._footer> tags, for
instance?
>
> It seems to me (though I haven't tried yet) that there's more at work than
> just prefixing/suffixing the content with the <dtml> codes when rendering
it.
> Though such a result might be renderable, it would certainly not be
> HTML-conformant (prob. two sets of <HTML> and <HEAD> codes) and might give
> unusual results (the possiblity of conflicting <HEAD> elements in the
document
> and in the standard_html_header; ...).
>
> On a related note, it might be interesting to run a second, modified FTP
> handler on a Zope Server, which "Zopifies" HTML documents upon upload,
perhaps
> even storing them as some subclass of DTML Document which renders itself
as
> DTML but which returns the originally-uploaded document if accessed via
FTP.
>
> Again, I'm just asking if anyone's done any work along such lines. It
seems a
> fairly useful feature to offer if (a) your end-user base is used to more
> traditional HTML publishing and (b) you want to gain the benefits of
> Acquisition while making it transparent to your end-users.