I was thinking of creating a class which stores the xml structure internally as javascript objects using these methods [1]
Then we could build on top of that all the standard E4X functions for accessing nodes and attributes. Dot notation would be complex (or impossible) to handle natively, but I imagine FlaconJS could handle E4X dot notation as special cases and call .child() and .attribute() respectively. This should solve the performance concerns with using XML (because it would be native js objects under the hood), but allow E4X type of functionality. I would not have a clue of how to go about handling the dot notation in FlaconJS, but the first part should be pretty straight-forward. [1] https://developer.mozilla.org/en-US/docs/Web/Guide/Parsing_and_serializing_XML On Jul 7, 2014, at 8:27 AM, OmPrakash Muppirala <bigosma...@gmail.com> wrote: > On Sun, Jul 6, 2014 at 10:12 PM, Alex Harui <aha...@adobe.com> wrote: > >> >> >> On 7/6/14 9:54 PM, "OmPrakash Muppirala" <bigosma...@gmail.com> wrote: >> >>> On Sun, Jul 6, 2014 at 9:49 PM, Alex Harui <aha...@adobe.com> wrote: >>> >>>> I certainly won't stop someone from trying to implement e4x in JS. I >>>> think there may already be some attempts. I think a significant number >>>> of >>>> folks use dot-path like Mark Kessler reported and so it will still be a >>>> porting challenge for folks to re-code to using functions. >>>> >>>> That's why it isn't on my priority list: if you're going to port your >>>> e4x >>>> dot-path expressions, it might just be better to go to JSON instead. >>> >>> >>> Switching from XML to JSON will require a server side change in most >>> scenarios. That might not be an option for folks especially servers that >>> they don't have control over. >> This is true, but one of the philosophies of FlexJS is "would you have had >> to convert anyway?". At least a couple potential FlexJS customers have >> already built out JSON backends as they explore which JS migration >> strategy to take. It appears that, at least for those folks, the notion >> of using XML in JS is too nasty and it is worth the time to change the >> backend. >> > > Things like public Atom, RSS feeds do require XML processing. Another > scenario is where I wanted to try out my hand at exporting an Adobe > Illustrator file to .FXG. Now that the Creative Cloud extensions are > HTML(5) based, that seems like a good target for FlexJS. If XML is not > supported, this use case is a non-starter. > > >> >> For others who really truly can't port the backend, it might be worth the >> time to convert from XML to Object, similar to the way the SOAPDecoder and >> XMLDecoders work today. XML has always been much slower and memory >> intensive in Flash and often folks convert to classes/objects. FlexJS has >> support for that already, although there is no generic SOAPDecoder or >> XMLDecoder. >> > > I think mx.rpc.xml.SimpleXMLDecoder should lend itself to FlexJS quite > well. Not exactly E4X, but at least it brings makes it closer to JSON. > What do you think? > > >> >> But again, anyone is welcome to take on trying to support e4x in JS. >> >> -Alex
