Hi Rob!
Rob Miller wrote:
i've been doing a bit of Plone-related hacking around in GenericSetup
recently, and have hit a bit of a snag because the current export
mechanism seems to be pretty tightly married to the idea that a single
object in the ZODB is going to only produce a single file in the
exported profile.
It is married to that idea because the adapters and the files they
produce are meant to be reusable in other contexts like FTP/DAV.
(Just to make it clear: We are talking about the sub-framework for
configuration data. The mechanism used by the content handler works with
multiple files per object.)
this is not always the case, however; consider the case of page
templates and python scripts in the skins that often have accompanying
.metadata files. in the case of CMFFormController, this is particularly
important, because the .metadata files contain validation and traversal
information that is integral to the behaviour of the exported object.
The fact that the skins tool handler exports scripts is an unintended
side-effect. So far there were no plans to make GenericSetup a
replacement for FSDump.
Is your major goal to support the format used by DirectoryViews and
FSDump or just to make sure no information gets lost on export and
re-import?
the export behaviour ultimately comes down to 'name', 'body', and
'mime_type' attributes returned by the export adapter. my first impulse
BTW: 'name' is just a hack to support the random names used in CMFSetup.
I hope in the long run we can get rid of this and use the object ID instead.
is to add support (in the GenericSetup.utils.exportObjects function) for
these values to be returned as a tuple; if this is so,
context.writeDataFile would be called once for each set of values.
even better, i think, would be to have the exporter return some sort of
data payload object that could contain all of the data for any number of
files that might need to be created. this would allow for more future
flexibility, as well.
any thoughts on these suggestions? other ideas on this problem?
The current machinery allows to store additional properties in the
container's XML file using INode interface.
It should also be possible to map complex objects to a folder structure.
But if we really need to support a format like the .metadata files (I
hope we don't) we should try to share code with the content
sub-framework that already supports that.
Cheers,
Yuppie
_______________________________________________
Zope-CMF maillist - [email protected]
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
