And I've been meaning to see if anyone has invented a proxy server that
does this sort of thing.

I'm still not convinced the compiler can convert e4x to these calls.  We
can if we force folks to strongly type everything, but I'd bet a lot of
existing code is not strongly-typed enough.  For example:

Class CustomItemRenderer
{
   Public function get data():Object
   {
        Return _data;
   }
}

If the CustomItemRenderer is used for an XMLListCollection, the data will
be XML but the compiler will not know that.

But yes, you are welcome to pursue making more of folks' XML code work in
FlexJS without porting.

-Alex

On 7/6/14 10:52 PM, "Harbs" <harbs.li...@gmail.com> wrote:

>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_serializin
>>g_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
>> 
>

Reply via email to