In porting Tour De Flex, there were patterns like this (explorerTree is XML):
explorerTree..node.(hasOwnProperty("@app") && @app.length() > 0)
The compiler logic before I made any changes yesterday just assumed that the
first expression was a reference to the node parameter but other expressions
were not, but it looks like the expression "@app.length()" was allowed in Flex
as a reference to the node. So I think the compiler has to determine what
expressions evaluate to "nothing" which implies they are references to the
node, and what did resolve to something. This is all new logic and I don't
know how to determine all of the test cases up front, so we'll have to keep
tuning it as we find patterns that don't work as we want them to.
In your case, if the expression resolves to a VariableDefinition, that probably
means that isn't a reference to node. Not exactly sure, so you should debug
into it to see what the node pattern is and return false.
Thanks,
-Alex
On 8/6/18, 3:28 PM, "Harbs" <[email protected]> wrote:
Doesn’t it always need to be a method for it to reference the node?
I.e. child() should be node.child(), but foo.baz would not.
> On Aug 7, 2018, at 1:12 AM, Alex Harui <[email protected]> wrote:
>
> Yep, we need more intelligent understanding of when a reference is to the
node or not.
>
> Debug into EmitterUtils.writeE4xFilterNode and figure out the node
pattern you need.
>
> -Alex
>
> On 8/6/18, 3:09 PM, "Harbs" <[email protected]> wrote:
>
> var folderFolders:XMLList =
assetXML.folder.(child('key').indexOf(folder.key) == 0);
> var folderImages:XMLList =
assetXML.image.(child('key').indexOf(folder.key) == 0);
>
> Is now compiled as:
>
> var /** @type {XMLList} */ folderFolders =
this.assetXML.child('folder').filter(function(node){return
(node.child('key').indexOf(node.folder.key) == 0)});
> var /** @type {XMLList} */ folderImages =
this.assetXML.child('image').filter(function(node){return
(node.child('key').indexOf(node.folder.key) == 0)});
>
> “node.folder.key” is not correct. “folder” is a local variable of an
un related object type.
>
> I assume this broke with the recent XML filter changes.
>
> Harbs
>
