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