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

[yuppie]

Hi Rob!


Rob Miller wrote:
> yuppie wrote:
> 
>> 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.

Agreed.

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

Well. None of the possible solutions sounds perfectly right to me. There 
are already many XML files that contain the complete information about 
subobjects and the other XML files that represent containers embed at 
least the information that is necessary to create empty subobjects.

If we want to support established file formats like those for 
PageTemplates and PythonScripts we have to make compromises. And adding 
some additional properties to the parents XML file doesn't sound that 
bad to me. At least it doesn't add a new pattern to solve the same problem.

>> 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?

In the long run the skins tool will be replaced by Zope 3 style skins. 
So if supporting the skins tool is the only reason to make the config 
handler machinery less generic and more complex I vote against full 
skins tool support.

On the other hand - as stated above - I don't think we need to change 
the framework to support skin folder export in a sufficient way.


Cheers,

	Yuppie