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