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
