DOM load and save flow

From COLLADA Public Wiki
Revision as of 22:32, 21 March 2007 by Elf (talk | contribs) (copy in Andy's text from word doc)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Summary: This article describes the internal loading and saving flow of the COLLADA DOM.

Loading

Calling load on the DAE object just checks that an IO plugin and database exist, creating default ones if they don’t, then calls read on the IO plugin.

The libxml plugin read function calls a recursive function that reads the XML element hierarchy using libxml’s SAX parsing functionality.

The nextElement function will call the appropriate functions based on the XML SAX type currently being parsed, i.e. attribute or value or new element.

The readAttributes function handles the white space delimiting of array values. It then calls setAttribute on the current element. (see the meta section for information on what this does) This has a nasty, but pursposely designed this way, side effect that if the element is an array type the particle gets appended to the attribute type list and not actually “set”.

readValue does the same as readAttribute except it doesn’t call setAttribute on the element but uses the meta value attribute (more in meta section) to set the data.

After the libxml plugin reads and converts all of the XML document, it creates a daeDocument with the root being the root that was created on parse.

It then creates all of the integration objects if they are used.

It then resolves all elements that require resolution (more in the meta section).

Then it calls the integration object conversion functions.

Saving

DAE save just checks if the IO plugin and database exist, creating them if it doesn’t.

If there is no database then save will most certainly fail, but it creates it anyways.

Then it calls write on the IO plugin.

The libxml plugin uses libxml2’s SAX writer to write out the COLLADA document.

It calls a recursive write function that writes each element and it’s child subtree.

There is some special case handling if you have the option set to save the float data as a .raw file. (more on this later)

If an element’s meta type is not flagged transparent then a new XML tag will be created and the attributes written. (code generator section for rules on what is marked transparent)

writeAttribute does some processing to check if an attribute should be written or not. It also does some special case handling so string types aren’t bound by the same size constraints that other types are.

Attributes that are required always get written. An element’s value is an attribute that is always considered required.

If the attribute is not required it checks if it was set. If not then it is not written.

If the attribute is set then it gets compared to the default value, if one was specified. If the attribute is the same as the default then it ignored. This will always fail for array types (I think).