[API Review]: Node validation

[Richard Bair]

> The thing is that in order to compute the layout correctly, you have to start from the layout root.

I think where you start the computation from depends on what you are trying to do. I think that "validate" or whatever we would call it would just be a convenient wrapper that did whatever we consider the most common steps. But it seems like we should expose the specific steps as well such that a developer can do what they want rather than just what we provide.

So for example, most of the time I would assume these APIs would be called on the layout root, naturally. So I am going to try to position the content of a popup and need to measure the size of the content. This is easily and naturally done by calling the APIs on the content root itself. On the other hand, even if I were to measure the size of things on the layout root, once it is popped into a scene which has a stylesheet that changes all of the CSS applied to that node (or to a different parent which changes what CSS is applied) then my previous measurements are toast anyway.

Is there any reason why I might want to measure a node independent of the layout of its parent? If I have a Button in a StackPane, is there a time I might want to measure the Button independent of the StackPane? I suppose so, if for example I wanted to get snapshots of it at its min size, max size, and pref size, regardless of what the layout container might do with the button. That seems reasonable.

> The concept of layout roots is not documented well in the API ( we use the term in few place, but never define it) and people would have to know how to identify the layout root and also know that they need to start from the layout root. Also, there's no way to check which Node is the layout root, although you can identify it using managedProperty(), it's parent and/or sub scene.

Hmmm. OK, so today suppose I have a scene graph with a root node and someplace down in the hierarchy is an unmanaged node. If I call layout() on the root node, then it will layout everything except for the unmanaged node. If i wanted to get a list of all the dirty layout roots, well, there is no public API to do so.

After your change, the semantics of layout would be the same -- calling layout on the root node isn't going to cause the unmanaged node to be laid out. So for what Steve and I are proposing to make sense (just expose applyCSS), we also have to expose either another method (layoutEverythingForTheLove) that will force everything in the tree to be laid out, or we have to have another method (getLayoutRoots) which will accumulate the layout roots so that you can then call layout() on them all manually.

> The validate methods finds the layout root of the subtree where the Node resides and does the layout from that layout root. If somebody needs more precise control over layout, we can leave the layout() methods public. But I expect people will be confused that simply calling the layout() on a Node will not result in the layout they will see after pulse.

So, calling layout on this node's layout root isn't sufficient, it also has to call layout on all layout roots that are beneath this node, right?

BTW, I think we need to expose in API (not in this release) the concept of layoutRoot, such that you can have a node be unmanaged which is not also a layout root. Or did we do that already? Sometimes I just want a node to never participate in layout. Ever. Because I am personally in charge of the node and its children and either am using binding or am going to manage the position of everything in that graph manually myself.

Richard