"Products.GenericSetup.OFSP.exportimport.FolderXMLAdapter._{ex|im}portNode" ineffective

[Dieter Maurer]

"FolderXMLAdapter" defines its own "_exportNode" and "_importNode" but they are not used in the "INode" interface because property "node" is not redefined with this new definitions and therefore continues to use the one from "Products.GenericSetup.utils.BodyAdapterBase".

[yuppie (yuppie3)]

'_exportNode' and '_importNode' solve the same task in XML adapters and pure node adapters. That's why those methods have the same name in both kinds of adapters. But they are used differently: XML adapters call them from '_exportBody' and '_importBody', pure node adapters use them for the 'node' property.

XML adapters need to export and import 2 different nodes for each object: One simple node that's part of the parent's XML file. And one complete node that's stored in the object's own XML file.

Only pure node adapters should redefine the 'node' property.

[Tres Seaver (tseaver)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

yuppie wrote:
> '_exportNode' and '_importNode' solve the same task in XML adapters and
> pure node adapters. That's why those methods have the same name in both
> kinds of adapters. But they are used differently: XML adapters call them
> from '_exportBody' and '_importBody', pure node adapters use them for
> the 'node' property.
>
> XML adapters need to export and import 2 different nodes for each
> object: One simple node that's part of the parent's XML file. And one
> complete node that's stored in the object's own XML file.
>
> Only pure node adapters should redefine the 'node' property.
>
> ** Changed in: zope-cmf
> Status: New => Invalid

Thanks, Yuppie -- I couldn't quite figure out how those things were
supposed to work.

Tres.
- --
===================================================================
Tres Seaver [phone] <email address hidden>
Palladion Software "Excellence by Design" http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkrTf8IACgkQ+gerLs4ltQ6SPwCgqQkqKCkRWE5lOfAE6jiMyxK6
fcEAn1C62sb0jAa1sZdtBdu65nVpcW7N
=FP2g
-----END PGP SIGNATURE-----

[Dieter Maurer (d.maurer)]

This indicates that (at least) additional documentation would be helpful. For me, it was extremely surprising that "node" does not handle the folder content but only an empty folder hull. In addition: the catalog support uses "INode.node" to serialize indexes -- and in this use case, obviously configuration subobjects of an index should be included. This means that Yuppie's explanantion cannot convince me.

[yuppie (yuppie3)]

Did you have a look at docs/handlers.rst (or doc/handlers.txt in older versions)? It describes the difference between XML adapters and node adapters. Catalog indexes have node adapters, not XML adapters. 'body' always returns the complete body, 'node' the subtree that should become part of the parent's XML body.

[Dieter Maurer (d.maurer)]

> Did you have a look at docs/handlers.rst (or doc/handlers.txt in older versions)?

I had indeed. And I knew that I would need a node adapter. Therefore, I had looked up an "INode" adapter for an "OrderedFolder" instance and a "GenericSetup" environment -- and I got something the "node" of which ignored the folders children. I started to investigate and found that the adapter's method definitions for "_{ex|im}portNode" were correct but the used "node" property not updated. This could only be a bug! Therefore, I have filed this bug report.

You are convinced that the "node" property is correct but then something else is buggy. A node adapter for a folder that ignores all children cannot be correct.

[yuppie (yuppie3)]

No. It is correct that all children are ignored. The adapter for OrderedFolder is no example for a *pure* node adapter. ObjectManager children have their own file in GS profiles. IBody.body handles those separate files.

GS would also work with profiles that contain the whole tree in one XML file. But that's not the way the adapters for ObjectManager items are implemented.

[Dieter Maurer (d.maurer)]

> No. It is correct that all children are ignored. The adapter for OrderedFolder is no example for a *pure* node adapter. ObjectManager children have their own file in GS profiles. IBody.body handles those separate files.

You argue that content and properties of a "Folder" are sufficiently relevant to be included if the folder is serialized to its own file but should be ignored if the same folder is serialized as part of another object. I hope you understand that such an argumentation has difficulties to convince me. Especially, I have not yet found documentation that describes this surprising inconsistency (between serialization into its own file and as part of another object).

[yuppie (yuppie3)]

The point is that you have to decide which kind of serialization you want *before* you write the adapter. Content and properties of a "Folder" are always relevant, but if you store that information in a separate file you don't have store the same information in the parent's file. In that case the parent's file just stores the information how to create an *empty* subobject and where exactly to place it in ordered containers. After the empty object is created it can be adapted and import the rest from it's own file.

[Dieter Maurer (d.maurer)]

I can see the use case you want to support -- but it seems strange to me and incompletely implemented.

Apparently, you want to separate the folder location from its content with the latter coming from a separate file. Why should this separation be the default rather than the more natural "keep the content together with the object"? With content in a separate file, content must be handled outside the node generation -- probably by a separate step; would it not be more natural to let this step also add the object itself? How about folders inside folders: does each of these subfolders need there own files? How do they get the name for such files?

At least, the documentation needs significant improvement to not be surprised by the strange implementation ramifications.

[yuppie (yuppie3)]

There are several reasons for the current implementation:

- It provides backwards compatibility with older implementations and profiles.

- Folders often contain objects with binary data and type specific serializations. That kind of data is hard to integrate in an XML file.

- Ordered folders make it necessary to keep track of the order of subobjects. We can't store that information in the separate subobject files.

Did you have a look at http://svn.zope.org/Products.GenericSetup/branches/1.4/Products/GenericSetup/doc/SampleSite/profiles/default/ ? It shows the result of exporting a folder 'siteroot' with a subfolder 'foo'.

Obviously my explanations are hard to understand for you. I guess the best way to improve the documentation would be if you summarize what you have learned from this discussion.

[Dieter Maurer (d.maurer)]

> I guess the best way to improve the documentation would be if you summarize what you have learned from this discussion.

My summary: Do not trust "INode" adapters. If the adapter only provides "INode" (and not "IBody") it is likely to faithfully serialize the object. If, however, it also provides "IBody", it is likely that its "node" serializes only an empty hull (without content or additional information such as properties) and expects that the missing parts are taken care of separately by the remaining "IBody" infrastructure in a separate step. An essential example of this behaviour is the default "INode" adapter for "Folder" (and friends): its "node" just specifies the folder's id and meta type, the folder's content is only serialized by "body".

[yuppie (yuppie3)]

Thanks! I added your explanation to the INode interface:
http://svn.zope.org/?rev=105100&view=rev