[Zope-CMF] Re: GenericSetup: one object -> mulitple files

[yuppie]

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