Fixes an issue with find not returning the correct node

[scottnc27603]

@eric79 @youngca
this.find stopped returning the correct node. This is a temporary fix to get the parent node of the obejcts to be drawn.

[davideaster]

@scottnc27603, what happened with find?

The only change I know of is that it find now won't search into child nodes that haven't completed construction. So if you do node.children.create( ... ), then node.find( ... ) won't search the new child unless its completion callback has fired. This happened in f456f7b.

[scottnc27603]

@davideaster
The drawing behavior which is added to the index-vwf had a this.find call and it stopped working.

 this.find( "//clientID//baseLayer//shapes" ) 

Does that look like the correct way to call find? The clientID is the moniker for each client. The recursive function I wrote is working so I know the path is correct, but I wasn't sure from tracing through the code if the leading '//' was correct or not. This was working at the end of last week. This is not during node.children.create, since I can go into the editor and see nodes. Unfortunately, you would need to grab development, and then the internal project in order to test this.

[davideaster]

The leading / anchors the search to the top of the application, regardless of the node you call it from.

The double // at the start (or within the query) indicates a recursive search from that point. You probably don't want to do that unless you don't know anything at all about the tree. It's extra work, and the implementation isn't terribly smart about it.

If the application creates one child per client, and each is named with its moniker--0123456789ABCDEF, for example--and each child has a baseLayer child that further contains a shapes child, then this query should work:

this.find( "0123456789ABCDEF/baseLayer/shapes" )

Your query should work too though (with clientID replaced with the actual node name). I don't see anything that might have caused it to break.

[scottnc27603]

@davideaster @youngca
Now I cannot get the find call to fail, so I don't know what the problem was. I've made no changes, and even added the other was to call find that you mentioned and they all work. I am using my macbook pro instead of my mac pro, and that's the only difference. Chris had mentioned that he was seeing the issue only when the debugger was active.

[davideaster]

Gremlins.

If it happens again, it would be interesting to see the steps the resolver takes. Recording the step and contextID parameters and the return value from xpathResolver in vwf.js should be enough.

An easy way to do this is to add a conditional breakpoint on the return resultIDs line in xpathResolver. Like this:

console.warn( step, contextID, resultIDs )

[scottnc27603]

@eric79 @youngca
Can you guys review please? I'll update the internal branch as well.

[eric79]

👍 to merge