[API Review]: Node validation

[steve.x.northover at oracle.com]

I don't think I understand the answer.  Are you saying that what we are 
suggesting is wrong conceptually or hard to implement or ...?

Steve

On 11/07/2013 1:23 PM, Martin Sladecek wrote:
> No, I will change the dirty roots to dirty flags on every node. With 
> them, it's possible to use it the way you suggest (applyCSS & layout 
> on nearest layout root), but it's much more convenient if we could 
> identify the layout root of the subtree and apply the layout from 
> there downwards. I think it's something most of the usecases would 
> want (SB, snapshot) but it's not that simple to identify layout root 
> (we have private flag for that in every Node, so internally it's just 
> one boolean check).
>
> -Martin
>
> On 07/11/2013 05:15 PM, Richard Bair wrote:
>>>> This might work for CSS, but won't for layout. The second example 
>>>> won't work because you'd just do layout of the node itself. It 
>>>> might get a different size from it's parent during the next layout 
>>>> pass (and the parent from it's parent, etc...). So the layout will 
>>>> look different after the next pulse. This is why we need more than 
>>>> layout() call and it's not just about adding the CSS.
>>> If I understand properly this would be the correct behavior. If I 
>>> ask a subtree of nodes to layout after setting the size of the 
>>> subtree root, then go farther up the tree to an ancestor, ensure the 
>>> ancestor has a size and layout again, the original subtree might be 
>>> layed out differently and I would expect that.  If I need to take a 
>>> snapshot of a child and it has to be in context of the entire tree, 
>>> I do CC in the root, force layout in the root and then take a 
>>> snapshot of the child.
>> That was what I was thinking as well, I don't understand why we have 
>> to do more than provide a way to apply CSS in order to satisfy all 
>> the use cases? Note that the old implementation (with lists of dirty 
>> roots on the Scene, or is this still the way we do it?) might be 
>> problematic here, I don't know, but from an API point of view, it 
>> seems like this is exactly what you want.
>>
>> Richard
>