Re: Toward XML-dump/load-based migration

Hi Raphael,

> it's been a long-term hope (of some of us at least) to support
> an alternative migration path for Plone sites, namely being
> able to dump configuration and content independently from
> on site and load it into another. Given what we have today,
> it looks like we are basically there :-)

I think this is a sorely needed feature that's been "almost there" for a  
long time. If you have some bandwidth to put into it, that'd be great. :)

> Configuration is handled by GenericSetup now and with Plone's
> (and 3rd-Party product authors) move to GS this can be considered
> (almost) done. (Well, sort of at least.)
>
> For content migration the addition and integration of 'Marshall'
> in Plone 2.5 has been a big step forward and with XMLForest we
> are basically there as well. (Big thanks to Sidnei, Kapil, Gogo,
> and everybody else involved.)

I am still a bit confused about the interdepencies of the stack  
GenericSetup/xmlio/Marshall/XMLForest, but hopefully this will become  
clear.

> While playing with content migration a bit recently, I stumbled
> over the following two problems:
>
> 1. XMFForest can only handle AT-based content. While this is
> almost always the case today, there is one noticable exception:
> The PloneSite (root) itself. Specifying the site root as root
> folder for an export fails when trying to access it's UID.
> Now, what would it take to adapt a PloneSite to support the
> interfaces necessary? (that would be which ones?) Not much,
> I hope, as we "only" have to deal with it being a (or the top
> level) container.
>
> 2. XMLForest uses Marshall's ATXMLMarshaller which in turn
> serializes each content item by iterating over its schema
> (plus some other stuff).
> So far so good. For default field types this works fine but
> I have trouble with some of my custom field types (those who
> manage data that itself has some non-trivial structure, e.g.,
> the RecordField, RecordsField, FormattableNamesField,
> RemoteTextField, ...).
> Looking into this more closely, it turns out that the marshaller
> just uses the field's default (edit)accessor to get at the value
> and the mutator to write the data back and all further (potentially
> data type dependend) processing is done in the marshaller itself.
> Now my question: wouldn't it be better to let the field itself
> control the (de)serialization of its value? At least optionally?
> How about makeing at least this part benefit from the CA, i.e.,
> providing adapters from IField to IXMLFieldValue or some such
> wich could be configured and further specified on field type.
>
> Is this the right direction to go?
> Anything I missed or should know?
> How does member data handling fit in this picture?
> (in particular when using CMFMember?)
> Anyone else thinking along those lines?

Basically, the only sensible way of doing this would be with Zope 3  
interfaces and adapters. We would need to be able to adapt any content  
object to a serialiser-deserialiser, at the very least, and possibly offer  
finer grained interfaces in the AT implementation for field-level  
serialisation-deserialisation. I don't imagine separating concerns like  
this would be terribly hard, and it would probably make the code a lot  
easier to test and develop.

I can't think of any particular problems with CMFMember (heck, it's just  
content after all), but then again :)

Martin

-- 
(muted)



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642