The xobj project provides an object reflector between various dynamic languages and XML. Currently, python and ActionScript 3 implementations are available.
Motivations
xobj was motivated by a few specific goals:
- Make the use of XML for object model interchange between client and server tiers less painful
- Allow your code to use real typed instances of classes rather than simple generic data structures
- Treat your code as the definition of schema rather than forcing an XMLSchema driven approach on your code.
- Read and write XML documents that will pass most XMLSchema structural validation requirements with relatively little effort on your part
Implementation Notes
During XML decoding, xobj preserves namespaces, element ordering and tracks attributes vs elements so that re-encoded object graphs can comply with most of the common XMLSchema validation requirements. This observed metadata is attached to your object graph rather than hidden out of view.
For "whole cloth" generation of XML from object graphs that were not themselves decoded in the first place, you can provide the namespace, elements ordering and attribute metadata declaratively to facilitate XMLSchema conformance.
However, most casual-use applications don't need to worry about namespaces, so your instance graphs will encode just fine as a usable XML document leveraging as much runtime class introspective data as is available. (AS3 in particular)
During decoding, xobj uses both the runtime type information available from your classes as well as a typemap you specify to determine the target type for every decoded XML element.
During encoding, xobj uses this same runtime information plus additional observed (or provided) metadata to inform the output XML.
For ActionScript, xobj decodes XML documents directly into typed instance objects rather than generic Object or ObjectProxy wrappers. This avoids the double-handling of generic objects required by the default SimpleXMLDecoder provided by Adobe Flex.
During decoding, xobj uses both the runtime type information available from your classes as well as a typemap you specify to determine the target type for every decoded XML element.
During encoding, xobj uses this same runtime information plus additional observed (or provided) metadata to inform the output XML.
For ActionScript, xobj decodes XML documents directly into typed instance objects rather than generic Object or ObjectProxy wrappers. This avoids the double-handling of generic objects required by the default SimpleXMLDecoder provided by Adobe Flex.
We've made a lot of use of this library in recent Flex/Python RESTful services at rPath.
0 comments:
Post a Comment