flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: [FALCONJX][FLEXJS] XML handling (was Re: [FlexJS] Back port)
Date Tue, 10 Nov 2015 16:35:56 GMT
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.


On 11/10/15, 8:30 AM, "Jim Norris" <jim.norris@e-work.com> wrote:

>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
>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.
>Jim Norris
>-----Original Message-----
>From: Alex Harui [mailto:aharui@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.
>On 11/10/15, 6:18 AM, "Alex Harui" <aharui@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.
>>On 11/10/15, 3:45 AM, "Harbs" <harbs.lists@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.lists@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.lists@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
>>>>> 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 <aharui@adobe.com> wrote:
>>>>>> Renaming the thread
>>>>>> On 11/9/15, 1:12 PM, "Harbs" <harbs.lists@gmail.com> wrote:
>>>>>>> Well, I’d be interested in your findings.
>>>>>>> If operator definitions is possible .. will be easier than .
>>>>>>> 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
>>>>>>>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 “@“.
>>>>>>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
>>>>>> 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
>>>>>>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
>>>>>> With a bunch of work, if we know you are setting “foo” (which
>>>>>>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”
>>>>>>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
>>>>>>node and not Object.
>>>>>> HTH,
>>>>>> -Alex

View raw message