Rob Miller 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
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
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.
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.
Zope-CMF maillist - Zope-CMF@lists.zope.org
See http://collector.zope.org/CMF for bug reports and feature requests