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

[Rob Miller]

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