Maybe the Storage versions should be renamed to some other name to avoid confusions...
just my 2ctns 2018-08-09 0:12 GMT+02:00 Harbs <[email protected]>: > OK. I think I cherry-picked the files, although there were some conflicts. > I hope I resolved them correctly. > > > On Aug 9, 2018, at 12:45 AM, Alex Harui <[email protected]> > wrote: > > > > The ones in Storage seem to have very different APIs that the flash > versions and are in a different package. I'm not sure it is worth worrying > about right now. > > > > AIUI, the ones in Network are intended to mimic the flash versions and > are what our users are looking for. > > > > My 2 cents, > > -Alex > > > > On 8/8/18, 2:43 PM, "Harbs" <[email protected]> wrote: > > > > It looks like we have duplicate classes in Storage and Network. I > think we need to pick which package these classes belong in. > > > > > >> On Aug 9, 2018, at 12:38 AM, Alex Harui <[email protected]> > wrote: > >> > >> There's an IDataInput/IDataOutput in the Network.swc in the develop > branch that would be useful to have in the feature/MXRoyale branch. I > don't want to stop to do a full merge right now. > >> > >> -Alex > >> > >> On 8/8/18, 2:36 PM, "Harbs" <[email protected] <mailto: > [email protected]>> wrote: > >> > >> What’s the issue with IDataInput/IDataOutput? Cherrypicked from where? > >> > >>> On Aug 8, 2018, at 11:48 PM, Alex Harui <[email protected]> > wrote: > >>> > >>> Won’t know until we try it. I'll adjust XMLList as needed. I have an > actual test case with Tour De Flex to work with. > >>> > >>> If you have time to cherrypick IDataInput/IDataOutput for our users > that would be helpful. > >>> > >>> Thanks, > >>> -Alex > >>> > >>> On 8/8/18, 1:31 PM, "Harbs" <[email protected]> wrote: > >>> > >>> Are you sure the logic to reassign this will work here? > >>> > >>> I’m willing to rewrite the code in XMLList to use call if you think > it’ll make things easier in the compiler… > >>> > >>>> On Aug 8, 2018, at 11:03 PM, Alex Harui <[email protected]> > wrote: > >>>> > >>>> > >>>> > >>>> On 8/8/18, 12:59 AM, "Harbs" <[email protected] <mailto: > [email protected]>> wrote: > >>>> > >>>> Does “this” in call/apply even work for a function which is not a > prototype function? I thought in that case “this” is the global context. > >>>> > >>>> From my testing, the 'this' can be re-assigned as we want it. > >>>> > >>>> I think 6a is kind of ambiguous. Why do you think there’s a > difference between the following (other than avoiding ambiguous this > references)? > >>>> > >>>> Because there is already code that distinguishes when 'this' is > supposed to be used. So we should use it instead of crafting a whole other > set of code that has a more difficult problem to solve, like whether an > expression is relative to a parameter and if so, which parameter? > >>>> > >>>> My 2 cents, > >>>> -Alex > >>>> > >>>> function() { return (over40(parseInt(this.age))) } > >>>> and > >>>> function(node) { return (over40(parseInt(node.age))) } > >>>> > >>>> Although in fact, I think it would need to be: > >>>> > >>>> function(node) { return (over40(parseInt(node.child(“age”)))) } > >>>> > >>>>> On Aug 8, 2018, at 10:33 AM, Alex Harui <[email protected]> > wrote: > >>>>> > >>>>> EmitterUtils.writeThis seems to be working ok. I think it would be > better/correct to use it here. I'm not sure if node as a parameter creates > the same scope chain as node being the this pointer. I think no, I don't > think parameters are involved in lexical scoping. IMO, 6a in the spec is > saying we should make node the 'this' pointer in JS. > >>>>> > >>>>> My 2 cents, > >>>>> -Alex > >>>>> > >>>>> On 8/7/18, 10:54 AM, "Harbs" <[email protected]> wrote: > >>>>> > >>>>> I’m not following you. Wouldn’t we need the same logic to figure out > where to insert “this”? I’m not sure what practical difference there would > be between “node" and “this”, other than using apply or call. Passing in > the XML node seems cleaner to me. > >>>>> > >>>>>> On Aug 7, 2018, at 6:50 PM, Alex Harui <[email protected]> > wrote: > >>>>>> > >>>>>> Yup. After thinking about it some more, it occurs to me that we > took the wrong starting point. Right now code like: > >>>>>> > >>>>>> over40(parseInt(age)) > >>>>>> > >>>>>> Results in: > >>>>>> > >>>>>> function(node) { return (over40(parseInt(age))) } > >>>>>> > >>>>>> And then the XML filter calls that function passing itself in as > the node. > >>>>>> > >>>>>> And this discussion has been about trying to figure out where to > add the "node" parameter. But now I think that 6a in the spec is really > saying that the 'this' pointer should be the node. We should transpile > that filter expression like any other function body but assume it is a > function run in the context of the node, like a new method on XML/XMLList, > or maybe more like an anonymous function. > >>>>>> > >>>>>> So if I'm right, then the output should be: > >>>>>> > >>>>>> function() { return (over40(parseInt(this.age))) } > >>>>>> > >>>>>> This is what the transpiler would have output if you had subclassed > XML and added this method to it. And then the code in XML.SWC that applies > the filter has to use Function.apply/call passing the node as the 'this' > pointer. > >>>>>> > >>>>>> If we do that, then the EmitterUtils.writeE4xFilterNode would go > away, and JSRoyaleEmitter.emitE4xFilter would temporarily change the > model.currentClass and maybe a few other things to reference an XML object. > >>>>>> > >>>>>> Thoughts? > >>>>>> -Alex > >>>>>> > >>>>>> PS: Regarding adding tests, the filter tests have two variables. > "var a" sets up the XML, "var b" is the result of the filter. getVariable > returns the nodes for "a" then we go get child(1) which is "b" and then > emit it to see what we get. > >>>>>> > >>>>>> On 8/7/18, 3:51 AM, "Harbs" <[email protected] <mailto: > [email protected]>> wrote: > >>>>>> > >>>>>> I’m also pretty sure that the following from Mozilla’s page[1] will > not work correctly: > >>>>>> > >>>>>> var people = <people> > >>>>>> <person> > >>>>>> <name>Bob</name> > >>>>>> <age>32</age> > >>>>>> </person> > >>>>>> <person> > >>>>>> <name>Joe</name> > >>>>>> <age>46</age> > >>>>>> </person> > >>>>>> </people>; > >>>>>> > >>>>>> function over40(i) { > >>>>>> return i > 40; > >>>>>> } > >>>>>> > >>>>>> alert(people.person.(over40(parseInt(age))).name); // Alerts Joe > >>>>>> > >>>>>> https://na01.safelinks.protection.outlook.com/?url= > https%3A%2F%2Fdeveloper.mozilla.org%2Fen-US%2Fdocs%2FArchive%2FWeb%2FE4X% > 2FProcessing_XML_with_E4X&data=02%7C01%7Caharui%40adobe.com% > 7Cba4001f9a9d4406f28c708d5fd77ee9b%7Cfa7b1b5a7b34438794aed2c178de > cee1%7C0%7C0%7C636693613904214807&sdata=f1j% > 2BqxKd5WDPLl8d41i2XcLUMxLvNLmuyy%2BFV6GePtc%3D&reserved=0 < > https://na01.safelinks.protection.outlook.com/?url= > https%3A%2F%2Fdeveloper.mozilla.org%2Fen-US%2Fdocs%2FArchive%2FWeb%2FE4X% > 2FProcessing_XML_with_E4X&data=02%7C01%7Caharui%40adobe.com% > 7Cba4001f9a9d4406f28c708d5fd77ee9b%7Cfa7b1b5a7b34438794aed2c178de > cee1%7C0%7C0%7C636693613904214807&sdata=f1j% > 2BqxKd5WDPLl8d41i2XcLUMxLvNLmuyy%2BFV6GePtc%3D&reserved=0> < > https://na01.safelinks.protection.outlook.com/?url= > https%3A%2F%2Fdeveloper.mozilla.org%2Fen-US%2Fdocs%2FArchive%2FWeb%2FE4X% > 2FProcessing_XML_with_E4X&data=02%7C01%7Caharui%40adobe.com% > 7Cba4001f9a9d4406f28c708d5fd77ee9b%7Cfa7b1b5a7b34438794aed2c178de > cee1%7C0%7C0%7C636693613904214807&sdata=f1j% > 2BqxKd5WDPLl8d41i2XcLUMxLvNLmuyy%2BFV6GePtc%3D&reserved=0 < > https://na01.safelinks.protection.outlook.com/?url= > https%3A%2F%2Fdeveloper.mozilla.org%2Fen-US%2Fdocs%2FArchive%2FWeb%2FE4X% > 2FProcessing_XML_with_E4X&data=02%7C01%7Caharui%40adobe.com% > 7Cba4001f9a9d4406f28c708d5fd77ee9b%7Cfa7b1b5a7b34438794aed2c178de > cee1%7C0%7C0%7C636693613904214807&sdata=f1j% > 2BqxKd5WDPLl8d41i2XcLUMxLvNLmuyy%2BFV6GePtc%3D&reserved=0>> < > https://na01.safelinks.protection.outlook.com/?url= > https%3A%2F%2Fdeveloper.mozilla.org%2Fen-US%2Fdocs%2FArchive%2FWeb%2FE4X% > 2FProcessing_XML_with_E4X&data=02%7C01%7Caharui%40adobe.com% > 7Cba4001f9a9d4406f28c708d5fd77ee9b%7Cfa7b1b5a7b34438794aed2c178de > cee1%7C0%7C0%7C636693613904214807&sdata=f1j% > 2BqxKd5WDPLl8d41i2XcLUMxLvNLmuyy%2BFV6GePtc%3D&reserved=0 < > https://na01.safelinks.protection.outlook.com/?url= > https%3A%2F%2Fdeveloper.mozilla.org%2Fen-US%2Fdocs%2FArchive%2FWeb%2FE4X% > 2FProcessing_XML_with_E4X&data=02%7C01%7Caharui%40adobe.com% > 7Cba4001f9a9d4406f28c708d5fd77ee9b%7Cfa7b1b5a7b34438794aed2c178de > cee1%7C0%7C0%7C636693613904214807&sdata=f1j% > 2BqxKd5WDPLl8d41i2XcLUMxLvNLmuyy%2BFV6GePtc%3D&reserved=0> < > https://na01.safelinks.protection.outlook.com/?url= > https%3A%2F%2Fdeveloper.mozilla.org%2Fen-US%2Fdocs%2FArchive%2FWeb%2FE4X% > 2FProcessing_XML_with_E4X&data=02%7C01%7Caharui%40adobe.com% > 7Cba4001f9a9d4406f28c708d5fd77ee9b%7Cfa7b1b5a7b34438794aed2c178de > cee1%7C0%7C0%7C636693613904214807&sdata=f1j% > 2BqxKd5WDPLl8d41i2XcLUMxLvNLmuyy%2BFV6GePtc%3D&reserved=0 < > https://na01.safelinks.protection.outlook.com/?url= > https%3A%2F%2Fdeveloper.mozilla.org%2Fen-US%2Fdocs%2FArchive%2FWeb%2FE4X% > 2FProcessing_XML_with_E4X&data=02%7C01%7Caharui%40adobe.com% > 7Cba4001f9a9d4406f28c708d5fd77ee9b%7Cfa7b1b5a7b34438794aed2c178de > cee1%7C0%7C0%7C636693613904214807&sdata=f1j% > 2BqxKd5WDPLl8d41i2XcLUMxLvNLmuyy%2BFV6GePtc%3D&reserved=0>>> < > https://na01.safelinks.protection.outlook.com/?url= > https%3A%2F%2Fdeveloper.mozilla.org%2Fen-US%2Fdocs%2FArchive%2FWeb%2FE4X% > 2FProcessing_XML_with_E4X&data=02%7C01%7Caharui%40adobe.com% > 7Cba4001f9a9d4406f28c708d5fd77ee9b%7Cfa7b1b5a7b34438794aed2c178de > cee1%7C0%7C0%7C636693613904224812&sdata=%2Bgtjz1494OOAafpuAJnfbsRXDLi% > 2FqwXpEIjzJZQ0AAY%3D&reserved=0 <https://na01.safelinks. > protection.outlook.com/?url=https%3A%2F%2Fdeveloper. > mozilla.org%2Fen-US%2Fdocs%2FArchive%2FWeb%2FE4X% > 2FProcessing_XML_with_E4X&data=02%7C01%7Caharui%40adobe.com% > 7Cba4001f9a9d4406f28c708d5fd77ee9b%7Cfa7b1b5a7b34438794aed2c178de > cee1%7C0%7C0%7C636693613904224812&sdata=%2Bgtjz1494OOAafpuAJnfbsRXDLi% > 2FqwXpEIjzJZQ0AAY%3D&reserved=0> <https://na01.safelinks. > protection.outlook.com/?url=https%3A%2F%2Fdeveloper. > mozilla.org%2Fen-US%2Fdocs%2FArchive%2FWeb%2FE4X% > 2FProcessing_XML_with_E4X&data=02%7C01%7Caharui%40adobe.com% > 7Cba4001f9a9d4406f28c708d5fd77ee9b%7Cfa7b1b5a7b34438794aed2c178de > cee1%7C0%7C0%7C636693613904224812&sdata=%2Bgtjz1494OOAafpuAJnfbsRXDLi% > 2FqwXpEIjzJZQ0AAY%3D&reserved=0 <https://na01.safelinks. > protection.outlook.com/?url=https%3A%2F%2Fdeveloper. > mozilla.org%2Fen-US%2Fdocs%2FArchive%2FWeb%2FE4X% > 2FProcessing_XML_with_E4X&data=02%7C01%7Caharui%40adobe.com% > 7Cba4001f9a9d4406f28c708d5fd77ee9b%7Cfa7b1b5a7b34438794aed2c178de > cee1%7C0%7C0%7C636693613904224812&sdata=%2Bgtjz1494OOAafpuAJnfbsRXDLi% > 2FqwXpEIjzJZQ0AAY%3D&reserved=0>> <https://na01.safelinks. > protection.outlook.com/?url=https%3A%2F%2Fdeveloper. > mozilla.org%2Fen-US%2Fdocs%2FArchive%2FWeb%2FE4X% > 2FProcessing_XML_with_E4X&data=02%7C01%7Caharui%40adobe.com% > 7Cba4001f9a9d4406f28c708d5fd77ee9b%7Cfa7b1b5a7b34438794aed2c178de > cee1%7C0%7C0%7C636693613904224812&sdata=%2Bgtjz1494OOAafpuAJnfbsRXDLi% > 2FqwXpEIjzJZQ0AAY%3D&reserved=0 <https://na01.safelinks. > protection.outlook.com/?url=https%3A%2F%2Fdeveloper. > mozilla.org%2Fen-US%2Fdocs%2FArchive%2FWeb%2FE4X% > 2FProcessing_XML_with_E4X&data=02%7C01%7Caharui%40adobe.com% > 7Cba4001f9a9d4406f28c708d5fd77ee9b%7Cfa7b1b5a7b34438794aed2c178de > cee1%7C0%7C0%7C636693613904224812&sdata=%2Bgtjz1494OOAafpuAJnfbsRXDLi% > 2FqwXpEIjzJZQ0AAY%3D&reserved=0> <https://na01.safelinks. > protection.outlook.com/?url=https%3A%2F%2Fdeveloper. > mozilla.org%2Fen-US%2Fdocs%2FArchive%2FWeb%2FE4X% > 2FProcessing_XML_with_E4X&data=02%7C01%7Caharui%40adobe.com% > 7Cba4001f9a9d4406f28c708d5fd77ee9b%7Cfa7b1b5a7b34438794aed2c178de > cee1%7C0%7C0%7C636693613904224812&sdata=%2Bgtjz1494OOAafpuAJnfbsRXDLi% > 2FqwXpEIjzJZQ0AAY%3D&reserved=0 <https://na01.safelinks. > protection.outlook.com/?url=https%3A%2F%2Fdeveloper. > mozilla.org%2Fen-US%2Fdocs%2FArchive%2FWeb%2FE4X% > 2FProcessing_XML_with_E4X&data=02%7C01%7Caharui%40adobe.com% > 7Cba4001f9a9d4406f28c708d5fd77ee9b%7Cfa7b1b5a7b34438794aed2c178de > cee1%7C0%7C0%7C636693613904224812&sdata=%2Bgtjz1494OOAafpuAJnfbsRXDLi% > 2FqwXpEIjzJZQ0AAY%3D&reserved=0>>>> > >>>>>> > >>>>>>> On Aug 7, 2018, at 1:41 PM, Harbs <[email protected]> wrote: > >>>>>>> > >>>>>>> OK. I fixed the issue, but there’s a couple of loose ends: > >>>>>>> > >>>>>>> 1. I don’t know how to add unit tests for these cases. In the > current unit tests, I see “getNode” and “getVariable” being used. I don’t > know the logic in setting up tests. > >>>>>>> 2. I’m not quite sure what "parentNode.getChild(0)” does. What is > the parent node and will this cause my second case of e.employee.(1 == @id) > to fail? Removing the check against firstChild caused the > testXMLFilterWithAttribute test to fail because it prepended “node.” to > “length()”. > >>>>>>> > >>>>>>> P.S. I finally got debugging from Eclipse working on the compiler, > so hopefully I’ll have a much easier time fixing compiler issues in the > future. :-) > >>>>>>> > >>>>>>> Thanks, > >>>>>>> Harbs > >>>>>>> > >>>>>>>> On Aug 7, 2018, at 10:51 AM, Harbs <[email protected]> wrote: > >>>>>>>> > >>>>>>>> Well, it looks like I was wrong. > >>>>>>>> > >>>>>>>> I just tested the following in Flash, and then both give the same > results (i.e. return the attribute): > >>>>>>>> > >>>>>>>> var emp = e.employee.(@id == 1).@name; // name of employee with > id 1 > >>>>>>>> var foo = e.employee.(1 == @id).@name; // name of employee with > id 1 > >>>>>>>> > >>>>>>>>> On Aug 7, 2018, at 10:27 AM, Harbs <[email protected]> > wrote: > >>>>>>>>> > >>>>>>>>> Your example does not seem to be right to me. > >>>>>>>>> > >>>>>>>>> Here’s the overview of how filters are supposed to work from the > spec: > >>>>>>>>> > >>>>>>>>>> Overview > >>>>>>>>>> When the left operand evaluates to an XML object, the filtering > predicate adds the left operand to the front of the scope chain of the > current execution context, evaluates the Expression with the augmented > scope chain, converts the result to a Boolean value, then restores the > scope chain. If the result is true, the filtering predicate returns an > XMLList containing the left operand. Otherwise it returns an empty XMLList. > >>>>>>>>>> When the left operand is an XMLList, the filtering predicate is > applied to each XML object in the XMLList in order using the XML object as > the left operand and the Expression as the right operand. It concatenates > the results and returns them as a single XMLList containing all the XML > properties for which the result was true. For example, > >>>>>>>>>> > >>>>>>>>>> var john = e.employee.(name == "John"); // employees with name > John > >>>>>>>>>> var twoemployees = e.employee.(@id == 0 || @id == 1); // > employees with id's 0 & 1 > >>>>>>>>>> var emp = e.employee.(@id == 1).name; // name of employee with > id 1 > >>>>>>>>>> > >>>>>>>>>> The effect of the filtering predicate is similar to SQL’s WHERE > clause or XPath’s filtering predicates. > >>>>>>>>>> For example, the statement: > >>>>>>>>>> > >>>>>>>>>> // get the two employees with ids 0 and 1 using a predicate > >>>>>>>>>> var twoEmployees = e..employee.(@id == 0 || @id == 1); > >>>>>>>>>> > >>>>>>>>>> produces the same result as the following set of statements: > >>>>>>>>>> // get the two employees with the ids 0 and 1 using a for loop > >>>>>>>>>> var i = 0; > >>>>>>>>>> var twoEmployees = new XMLList(); > >>>>>>>>>> for each (var p in e..employee) { > >>>>>>>>>> with (p) { > >>>>>>>>>> if (@id == 0 || @id == 1) { > >>>>>>>>>> twoEmployees[i++] = p; > >>>>>>>>>> } > >>>>>>>>>> } > >>>>>>>>>> } > >>>>>>>>> > >>>>>>>>> The question is what is "the front of the scope chain of the > current execution context”? I’m pretty sure that means the start of > sub-expressions. I don’t see how that can apply to the right-hand of > comparison expressions. There is nothing in the spec about figuring out if > a part of an expression is referring to XML or XMLList. > >>>>>>>>> > >>>>>>>>>> On Aug 7, 2018, at 9:45 AM, Alex Harui <[email protected]> > wrote: > >>>>>>>>>> > >>>>>>>>>> I don't get what portion of the spec has to do with whether we > append "node" to various expressions. IMO, the changes I made only affect > 6b. 6a is handled by generating a function with "node" as the parameter > (because node is list[i] in the spec). The task in 6b is to correctly > evaluate any e4x filter expression. I'm not sure what the limits are on > what you can have in a filter expression, but if you can have just plain > "@app" anywhere in the filter expression, I don't believe scoping rules > would know to apply that to the "node" parameter without generating the > "node" before "@app". > >>>>>>>>>> > >>>>>>>>>> There is a chance that the Flex Compiler was using "magic" to > generate the "node" and really should have reported an error. I do > remember being told that the filter function can be "anything". Even: > >>>>>>>>>> (var foo:int = @app.length(); foo > @bar.length()) > >>>>>>>>>> > >>>>>>>>>> If there are actual rules in the spec about evaluating the > expression, that might apply to how we handle these expressions, otherwise > I think the right thing is to resolve each expression and if the expression > does not resolve to anything else, assume that it applies to the node. I > know the logic in EmitterUtils.writeE4xFilterNode isn't covering all > cases. It is trying to see what the expression resolves to, and returns > false for known conditions (like a member of a class). Just make it return > false for your case (and feel free to add that case to the tests). > Eventually we'll have enough cases to either call it "good enough" or > figure out a better way to determine when the expression applies to "node". > >>>>>>>>>> > >>>>>>>>>> My 2 cents, > >>>>>>>>>> -Alex > >>>>>>>>>> > >>>>>>>>>> On 8/6/18, 11:20 PM, "Harbs" <[email protected]> wrote: > >>>>>>>>>> > >>>>>>>>>> I just looked at the spec. I think it’s correct to append > “node” to the first statement of the expression only. The only exception > seems to be expressions which use boolean expressions (i.e. || or &&) in > which case each piece of the boolean expression should be considered a > self-contained expression. So in your example, there are really two filter > expressions: > >>>>>>>>>> 1. hasOwnProperty("@app”) > >>>>>>>>>> 2. @app.length() > 0 > >>>>>>>>>> > >>>>>>>>>> Both of those should have node appended to the front, but > nothing else. > >>>>>>>>>> > >>>>>>>>>> Here’s the relevant semantics in the spec (the important bit > being 6a): > >>>>>>>>>> > >>>>>>>>>>> 6. For i = 0 to list.[[Length]]-1 > >>>>>>>>>>> a. Add list[i] to the front of the scope chain > >>>>>>>>>>> b. Let ref be the result of evaluating Expression using the > augmented scope chain of step 6a > >>>>>>>>>>> c. Let match = ToBoolean(GetValue(ref)) > >>>>>>>>>>> d. Remove list[i] from the front of the scope chain > >>>>>>>>>>> e. If (match == true), call the [[Append]] method of r with > argument list[i] > >>>>>>>>>>> 7. Return r > >>>>>>>>>> > >>>>>>>>>> Makes sense? > >>>>>>>>>> > >>>>>>>>>> Harbs > >>>>>>>>>> > >>>>>>>>>>> On Aug 7, 2018, at 1:39 AM, Alex Harui > <[email protected]> wrote: > >>>>>>>>>>> > >>>>>>>>>>> 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 > > > > > > > > -- Carlos Rovira http://about.me/carlosrovira
