After a whole bunch of digging around under the hood of the mx.rpc.XMLDecoder class, I finally pinpointed the line that is causing it to incorrectly decode elements that do not have sub-elements. Basically, when it gets to an element that it considers to have simple content (meaning just a string value between the tags), it immediately returns that string value and moves on to the next node. So, in the case of an empty node (like the one below), which has no inner value but only attributes, XMLDecoder would never even try to parse the attributes.
<car make="Subaru" model="Impreza" />The solution was to check if the inner value evaluated to an empty string, and if it does, continue on as though it were actually a complex node, which will then parse the attributes.
Patch for Flex Bug #SDK-17271
I’ve created an example that decodes some simple xml data against a simple schema. By checking the “Patch” box, you can see that fix returns a object graph with the correct properties for the CarVO. This example would also be a good starting point if you’re interested in learning how to decode xml into strongly-typed objects. With the exception of this bug, the XMLDecoder class seems pretty solid, and it’s really handy if you want to parse something, like, say an MXML file.
3 Comments
Yeay for XMLDecoder hacking. I recently created an extended version of SOAPDecoder (which in turn extends XMLDecoder) and overrode decodeType to force dateTime values in SOAP messages to UTC time if they don’t have a time zone designator. (By default Flex interprets these as local time).
I’d really like to see some better examples somewhere on how to use the schema type registry or whatever it’s called to directly generate strongly-typed VO objects. Adobe’s documentation seems a bit scant…
Hey,
This post helped me a lot as I was stuck with the exact problem you have mentioned here.
Thanks a ton!!!
Great work. Thank you.
How would you change this code if you wanted to return an ArrayCollection of CarVO objects instead of just a single one?