Backward compatibility with our large set of deployed (XML based) content is critical, so very likely JS rather than JSON.
Jim -----Original Message----- From: Alex Harui [mailto:aha...@adobe.com] Sent: Tuesday, November 10, 2015 11:36 AM To: dev@flex.apache.org Subject: Re: [FALCONJX][FLEXJS] XML handling (was Re: [FlexJS] Back port) Thanks Jim, We’ll keep that in mind. Just curious, if FlexJS didn’t exist and you had to use some other JS framework, would you port all of your XML handling to JS or switch over to JSON? Other folks with XML backend are welcome to add their thoughts as well. -Alex On 11/10/15, 8:30 AM, "Jim Norris" <jim.nor...@e-work.com> wrote: >Hello, > >I have been observing the progress on FlexJS as I am the developer for >an application built with Flex that my company deploys into large >enterprises. > >We have XML based content and use a significant number of E4X >expressions, so if there is a way to simplify the conversion of these >expressions to Flex JS that would certainly make an eventual conversion >of our application simpler. We also use the XML.hasOwnProperty method >to detect the existence of attributes that are used as configuration >switches in the XML. > > > > >Thanks, > >Jim Norris > >www.e-Work.com > > >-----Original Message----- >From: Alex Harui [mailto:aha...@adobe.com] >Sent: Tuesday, November 10, 2015 11:07 AM >To: dev@flex.apache.org >Subject: Re: [FALCONJX][FLEXJS] XML handling (was Re: [FlexJS] Back >port) > >Also, don’t spend too long on trying to create an XML class in the >default package. You can just code it in some package and manually map >it for now. And maybe we’ll just end up having the compiler inject the >mapping if that turns out to be easier. > >-Alex > >On 11/10/15, 6:18 AM, "Alex Harui" <aha...@adobe.com> wrote: > >>The key is in the build.xml and compile-asjs-config.xml in any of the >>already-backported SWCs. The js.swc from Falcon is used instead of >>playerglobal.swc/airglobal.swc. I have not tried to swap out a class >>in the default package yet, but it should be doable. We might need a >>compiler change if there are assumptions. And I have no idea if FB is >>making any assumptions. >> >>I forgot to add to that wiki page how to deal with platform-only >>components. I will add that this morning, but basically, you should >>add them to the as/src/XXXClasses.as and put COMPILE::JS or >>COMPILE::AS3 around it. There are examples, especially in the >>Core.swc and HTML.swc. >> >>FWIW, I don’t know why you can’t go from XML to JSON and back to XML. >>Both are hierarchical data structures. In the Flex SDK we have >>SOAPDecoder and SOAPEncoder that take XML to data objects and back, >>and generally that performs better if you are going to access a >>significant percentage of the data. >> >>HTH, >>-Alex >> >>On 11/10/15, 3:45 AM, "Harbs" <harbs.li...@gmail.com> wrote: >> >>>I’m a bit stumped here. We have externs for HTML and native >>>javascript APIs. Right? How do I import these externs so these >>>classes are recognized when using COMPILE::JS? >>> >>>Actually, I just searched for DOMParser and createHTMLDocument. >>>Neither searched turned anything up in FlexJS. So I’m wondering if I >>>was wrong about having externs for this. >>> >>>On Nov 10, 2015, at 10:48 AM, Harbs <harbs.li...@gmail.com> wrote: >>> >>>> I’m going to have to do some fancy footwork to get this working. >>>>Flash Builder is complaining that palyerglobal.swc already exists >>>>whe I try to create an XML class in the default package. >>>> >>>> Any ideas on how to do this? >>>> >>>> On Nov 10, 2015, at 9:39 AM, Harbs <harbs.li...@gmail.com> wrote: >>>> >>>>> OK. This approach is different than the approach I started on, but >>>>>it could be workable. >>>>> >>>>> I was going down the road where there would be a set of single new >>>>>classes which would proxy to XML and Document in Flash and HTML >>>>>respectively. You are suggesting we stick with XML and XMLList for >>>>>Flash and create new JS versions with the same public API as XML >>>>>and XMLList. >>>>> >>>>> Where would you go about creating those JS classes? Would I just >>>>>out it in an “as” folder and wrap the whole class in a COMPILE::JS? >>>>>Also, what package would this go into? I’m assuming none, since XML >>>>>and XMLList are both top level classes. >>>>> >>>>> BTW, I need to read and write XML files, so yeah, converting to >>>>>JSON is not an option. >>>>> >>>>> On Nov 10, 2015, at 1:28 AM, Alex Harui <aha...@adobe.com> wrote: >>>>> >>>>>> Renaming the thread >>>>>> >>>>>> On 11/9/15, 1:12 PM, "Harbs" <harbs.li...@gmail.com> wrote: >>>>>> >>>>>>> Well, I’d be interested in your findings. >>>>>>> >>>>>>> If operator definitions is possible .. will be easier than . >>>>>>>operators. >>>>>>> If we allow single dot operators, it will be difficult to >>>>>>>differentiate between E4X syntax and function calls. I’d really >>>>>>>like to drop the >>>>>>>() on >>>>>>> length and some of the other methods… Those are a course for >>>>>>>very common errors. >>>>>> >>>>>> Maybe we aren’t talking about the same thing, but let me explain >>>>>>in more detail what I’m saying. >>>>>> >>>>>> Here is some E4x: >>>>>> >>>>>> var a:XML = new XML(\"<top attr1='cat'><child >>>>>> attr2='dog'><grandchild >>>>>> attr3='fish'>text</grandchild></child></top>\”); >>>>>> var b:XMLList = a..child; >>>>>> var c:XMLList = a..grandchild.(@attr2 == 'fish'); >>>>>> >>>>>> >>>>>> (It would be nice to have others add in their favorite or common >>>>>>scenarios if they are different). >>>>>> >>>>>> The compiler already understands the “..” as well as the “@“. >>>>>>The way Falcon and FalconJX works is that there is a parsing >>>>>>phase that takes your source code and creates a tree of different >>>>>>kinds of nodes (ClassNodes, FunctionNodes, FunctionCallNodes, >>>>>>OperatorNodes, MemberAccessExpressionNodes, etc). Falcon then >>>>>>walks the tree and converts these nodes to ABC. FalconJX walks >>>>>>the tree and outputs JavaScript. >>>>>> >>>>>> I just ran a test and the above code was parsed into a tree where >>>>>>the “..” >>>>>> was the operator for a MemberAccessExpression. The “@“ was >>>>>>converted into a unary operator for an E4xFilter operator for >>>>>>another MemberAccessExpression. This is good for FalconJX, >>>>>>because that means we understand the semantics of this syntax and >>>>>>can then generate any JavaScript we want. >>>>>> >>>>>> IMO, given that folks are already wishing for a more Spark and >>>>>>MX-like component set, I think we should try to mimic as much of >>>>>>E4x as possible as opposed to inventing a new API that folks >>>>>>would have to migrate to. >>>>>> Performance-wise, I still think it would be worth everyone’s time >>>>>>to convert XML to JSON, but there are probably folks who can’t move. >>>>>> >>>>>> Given that FlexJS leverages the concept of replacing >>>>>>abstractions, if you create an XML and XMLList class in >>>>>>JavaScript and populate them with the same APIs as ActionScript, >>>>>>lots of things should work. The FalconJX compiler could easily >>>>>>be taught to convert “a..child” into “a.descendants()”. If the >>>>>>JS version has an extra >>>>>>filter() function, then FalconJX would convert >>>>>> >>>>>> a..grandchild.(@attr2 == 'fish’) >>>>>> >>>>>> into >>>>>> >>>>>> a.descendants().filter(function (node) { return >>>>>> node.attribute(‘fish’).length() }) >>>>>> >>>>>> or something like that. >>>>>> >>>>>> I think the part of XML in ActionScript that isn’t practical to >>>>>>do in JavaScript is handling change notifications. It might be >>>>>>possible to do some of it for known properties but I think it >>>>>>would be fragile. >>>>>> >>>>>> For example: >>>>>> >>>>>> var d:XML = a..child[0]; >>>>>> d.foo = <bar />; >>>>>> >>>>>> In ActionScript you can get a change notification when foo is >>>>>>assigned. >>>>>> With a bunch of work, if we know you are setting “foo” (which we >>>>>>do know in this case) I think we could use Object.defineProperty >>>>>>to define a property on d. >>>>>> >>>>>> What we can’t easily do is: >>>>>> >>>>>> var d:XML = a..child[0]; >>>>>> var s:String = “someRandomPropertyName”; d[s] = <bar />; >>>>>> >>>>>> If we don’t know what ’s’ is, we can’t define properties early on >>>>>>the XML node. I suppose with even more code we could generate >>>>>>code for that. >>>>>> >>>>>> BTW, for any sort of solution, we would have to know that “d” is >>>>>>XML and not Object and that would require more careful type >>>>>>handling in the code our customers write. If you have: >>>>>> >>>>>> >>>>>> public class MyClass extends EventDispatcher { public var >>>>>> someProp:XML; } >>>>>> >>>>>> Then in some other class you have: >>>>>> >>>>>> var instance:MyClass = new MyClass(); >>>>>> instance.addEventListener(“someEvent”, myHandler); >>>>>> >>>>>> function myHandler(event:Event):void { event.target.someProp.foo >>>>>> = <newnode />; } >>>>>> >>>>>> We have lost the notion that someProp is XML and not Object >>>>>>because event.target is defined as Object and not MyClass. Folks >>>>>>will have to fix up their code to be: >>>>>> >>>>>> (event.target as MyClass).someProp.foo = <newnode />; >>>>>> >>>>>> Which won’t be much fun and if you miss one, you won’t get a >>>>>>compile error. >>>>>> >>>>>> FWIW, we could probably put in a warning if you forget () on >>>>>>“length”, again if we know that length is being access on an XML >>>>>>node and not Object. >>>>>> >>>>>> HTH, >>>>>> -Alex >>>>>> >>>>>> >>>>> >>>> >>> >> > >
