yuppie wrote:
Hi Rob!


hi back!

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

ah, right. what's interesting, though, is that currently the contents of any non-FS-based skin folders that exist WILL be exported by the configuration data sub-framework, due to the recursive nature of the utils.exportObjects function.

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.

ah... that changes things, then.

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 latter, really. although i may be willing to work w/ punting on this and not exporting the skins at all. what happened is that i discovered that skins folders containing python scripts _were_ getting exported, and from there made the assumption that GenericSetup did intend to support skin folder exports as a part of the configuration profile.

i do think that exporting the skins would be a nice touch. if we don't do so, however, we should a) make it clear that we're not doing so and b) make certain that we aren't accidentally exporting scripts or templates that we don't actually intend to export.

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.

right.

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.

hmmm. this would mean embedding information about subobjects in an XML file corresponding to the container object? doesn't sound right.

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)

well, if we want to support import and export of PageTemplates we either have to support .metadata or some other mechanism for recording the information that would have been stored in the .metadata file.

we should try to share code with the content sub-framework that already supports that.


this is probably the key, yes.

i guess before i dig further, though, we need to make a policy decision. are we going to support skin folder export? or do we delegate this to FSDump or some other tool?

-r

_______________________________________________
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Reply via email to