I used the wrong link. It should have been: https://developer.mozilla.org/en-US/docs/JXON
On Jul 7, 2014, at 8:50 AM, Harbs <harbs.li...@gmail.com> wrote: > 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 >
