On 11/10/15, 11:16 AM, "Harbs" <harbs.li...@gmail.com> wrote:
>I’m not sure you answered my primary question here. How do I target >HTML/JS native classes like Document, DOMParser, etc. in ActionScript? I >don’t want to do that in js. I’d rather have FlaconJX cross-compile it >for me. Not sure about what FlashBuilder will let you do, but from Ant, you should be able to use Document, DOMParser etc inside COMPILE::JS blocks. Try adding test code to a class in the Core project and compile it. Then we’ll worry about FlashBuilder. It should work for Core because the compile-asjs phase will not use playerglobal/airglobal, it will use js.swc from the Falcon repo which has Document and DOMParser in it. > >Regarding decoding and encoding XML: Yes. That might be a good way to go. >I’ll look at the Encoder and Decoder classes to see what they’re doing. >How does it handle attributes and properties that might have the same >names? Does each object have children and attributes, or does it take a >simple structure approach? Same for namespaces, instructions and comments. AIUI, attributes and properties with the same names is the key feature that XML has over JSON. The question is: how many folks actually have this scenario? Because if you don’t, the performance benefits may be significant. I’m not sure how the decoders handled that if at all. I would expect at minimum you could provide some sort of mapping that is lighter weight than a full-blown XML schema. Another reason to stay with XML is supposedly when you have “mixed-content” where you need namespaces to avoid collisions between node names. I’m interested to know how many folks are truly in this situation. > >One way to handle the XML problem might be a 2-pronged approach: 1. >Create XML/XMLList classes for js which would be able to process the >basic E4X. 2. Have some classes which converts XML to objects and back. >One disadvantage of *simple* objects is the difficulty of accessing >pieces of the structure. Unless you know the exact structure of your data >ahead of time, it’s very hard to get specific pieces of data without a >lot of utility functions. That’s why even if we do go the object >hierarchy approach (JSONy but not exactly JSON), I think the objects >should have the functionality built in to filter content, get >children/descendants, etc. I’m sure there are scenarios where going away from XML just won’t make sense, so I would never say that we would never support XML in FlexJS. I have seen a few places execute the switch from XML to JSON as the means of exchanging data with the client without any hassle because their data structures are straightforward enough that they don’t lose anything by going with JSON, so I’m wanting to make sure folks really need the power of XML in the client. Also, I’ve seen Flex apps that did use SOAPEncoder/SOAPDecoder to convert SOAP/XML to Flex data objects and back. At least one of them was able to manually port only a few files so that they could convert JSON to those same Flex data objects and back in a days work. Their business logic did not use E4x at all because they got better runtime performance by doing the decoding/encoding. But everyone’s mileage may vary.
