DOM integration classes

This is some internal notes about COLLADA DOM integration classes.

Integration classes provide a SAX-like approach to using the DOM. My problem with this is that the interdependent links between COLLADA elements has become very complex. Parsing a DOM structure lends itself better to handle these problems. Creating an integration class to process, for example, materials may take the same amount of work as accessing the DOM structures itself. Here's a comparison.

To do with Integration Class:

1. Create class that inherits from daeIntegrationObject.
2. Implement the fromCOLLADA code to do the conversion.
3. Implement the fromCOLLADAPostProcess code to do the processing needed to resolve links to other elements, for example, effect.
4. Make your integration library register with the DOM.

To do with DOM access:

1. Get DOM by calling getDOM() or getDOMRoot from the daeDocument.
   • For each material library
   • For each material
2. Call your conversion function (which would be the same as your fromCOLLADA). Your conversion function can even do the post-processing linking needed since all the data required by the other elements would be available.

Also it is a lot harder to go from custom classes to COLLADA DOM with the integration objects than it would be just with the DOM structures.

DOM structures give you finer-grained control over what to convert; for example, you can spend time converting only the geometries in the scene and not the possible dozens/hundreds/thousands of others which the integration classes convert every single one. This is especially useful to know if you have documents that cross-reference to other documents. For example, a document that only contains a visual scene where all instance_geometry elements reference a geometry in a document that contains only a library_geometry with all geometries you ever create. ((ANDY: Ack, I couldn't parse that last sentence at all!)) That could be a lot of geometries that could take a lot of time to process.