"Chris McDonough" <[EMAIL PROTECTED]> writes:

> I don't think it's reasonable or wise to impose any "master
> structure" for filesystem serialization of bodies of
> objects.  Each instance (or perhaps each class) should
> define how best to serialize itself to disk.
> Representations between classes are likely to be radically
> different.  A place for standardization is in the
> "properties" file(s) which accompany each object rep... this
> is likely to be XML or another structured variant.

Is there a motivation for using serialization to provide an editable
"god's eye view" of all or part of a Zope site?

That is, provide a two-way XML serialization at any stage of the
managed hierarchy of a site?  That way, XML tools could be used as
stream editors at any level, to the extent that the serialization is

So, for example, we'd have ways to not just alter a template or
content that gets templatized, but the containers that organize them,
and related metadata or content that isn't as near.

This links well with the standardization that you mention - objects
can have arbitrary serialization formats, but if certain attributes
that we're interested in are recognizable, those attributes could be
edited on a containerwide level.  So, if we had arbitrary objects that
we wanted to have an effect on content or display, the same XML tools
could be used to manage them all, limited only by the ability of those
tools to slog through a level of the hierarchy.

This is kind of stream-of-consciousness talk, and might be more silly
than realistic; certainly, if the objects didn't guard how they could
be updated, a misconfigured tool could waste them without warning.

There's a similar project called psilib that was discussed in xml.com:

Karl Anderson                          [EMAIL PROTECTED]

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope )

Reply via email to