I was facing a very similar issue just recently. I had all these AS model classes that mapped identical properties in accordance to the backend objects I was dealing with, but no FDS-style convenience mechanism to handle typing via HTTPService calls. What I found out is the beauty of the "xmlDecode" and "xmlEncode" methods.
When you use the xmlDecode method, passing it a function reference, that function will expect an XMLDocument object that is generated automatically by the service. You can then take that XMLDocument, iterate through it, building and returning objects of whatever type you desire. When you access "event.result" in your handler function, that property value will be typed based on your decoder return type. So "event.result" is now, say a User object, rather than a user xml node representation. The beauty of this strategy is, at any point, your transport mechanism becomes disposable. If you suddenly decide to switch from XML to JSON as your transport mechanism of choice, you only need to code some decoder / encoder functions, and you're done. No need to change what, say, a datagrid expects. Very elegant architecture. I recommend taking a look at AS3's SimpleXMLDecoder class, along with Darron Schall's ObjectTranslator class, which makes writing an XML decoder a breeze. If anyone is interested, I can post a sample. > So I tried setting the resultFormat to "object" for a service that > returns a fairly deep XML structure. I found that it did a pretty good > job of mapping the text nodes to the correct types (Boolean, String > and Number); it didn't map "2006-11-17" to a Date, but hey, you can't > be all things to all people. > > Anybody else out there have experience with resultFormat="object"? Is > there any documentation that specifically describes how the object > graph is put together and what the text-node-to-object rules are? I > suppose I could go look at the source code, but figured I might as > well ask around first. > > Thanks, > Chris
