[API Review]: Node validation

Martin Sladecek martin.sladecek at oracle.com
Tue Jul 9 23:49:01 PDT 2013 

On 07/09/2013 10:59 PM, David Grieve wrote:
> Since there is already a "requestLayout()" which defers to the next 
> pulse, what about "demandLayout()"? Or why can't getBoundsInParent() 
> or getBoundsInLocal() do this?
>
> Even with this function, there is still the problem where the 
> dimensions of a node won't be right if called before the node is added 
> to the scene.
>
>     Button button = new Button("Hello World!");
>     root.getChildren().add(button);
>
>     button.demandLayout();
>     double width0 = button.getWidth();
>
>     Scene scene = new Scene(root);
>
>     button.demandLayout();
>     double width1 = button.getWidth();
>
> Note that width0 != width1 because the layout at width0 has no css 
> styles until the button is in the scene-graph, which doesn't happen in 
> this example until 'new Scene(root)'. Should the "validate" throw an 
> exception if the node isn't in the scene-graph?
I guess it should.

>
> I still think it is worth holding out for something like 'public 
> static Bounds getBounds(Scene scene, Parent parent, Node child)' which 
> would return the Bounds of the child if it were a child of the given 
> parent in the given scene.
While I agree this is something that would be useful, I don't think it 
should replace the "validate" method. Such method shouldn't probably 
change CSS/layout on place and everything would have to be recomputed 
separately. This would require additional methods for CSS and layout.

-Martin

>
> On Jul 8, 2013, at 1:01 PM, Richard Bair <richard.bair at oracle.com 
> <mailto:richard.bair at oracle.com>> wrote:
>
>> So this was also my first desire. I wanted to actually make it so 
>> that nobody would ever have to invoke a CSS pass manually, but 
>> instead we would just do it lazily on first request as needed. If 
>> this is possible then we can only think of the layout problem in 
>> isolation. In this case, just reusing the existing layout() method 
>> seems like the right thing to do.
>>
>> I can't remember on this Monday morning why I decided it wasn't 
>> possible to handle CSS lazily in this manner. But it is *really* what 
>> I want to do if it is possible. I'm sure there are lots of 
>> possibilities for strange performance issues with this approach when 
>> you bind certain properties.
>>
>> Richard
>>
>> On Jul 8, 2013, at 9:52 AM, David Grieve <david.grieve at oracle.com 
>> <mailto:david.grieve at oracle.com>> wrote:
>>
>>> I'm wondering why this "validate" can't just be implicit in any call 
>>> that uses or returns layout bounds. Surely we can tell from the 
>>> dirty bits whether or not something needs layout and/or css.
>>>
>>> On Jul 8, 2013, at 12:31 PM, Richard Bair <richard.bair at oracle.com 
>>> <mailto:richard.bair at oracle.com>> wrote:
>>>
>>>> OK, just throwing something wild out there. Right now we have a 
>>>> layout pass and a css pass. Can they be combined? Can we combine 
>>>> them just into something that happens during layout? And can the 
>>>> existing "layout()" method be the thing that kicks it all off?
>>>>
>>>> Wild and crazy but just throwing it out there (personally I'm 
>>>> uncomfortable conflating CSS and layout as I believe there will be 
>>>> use cases to do one and not the other at times).
>>>>
>>>> Richard
>>>>
>>>> On Jul 8, 2013, at 9:27 AM, Scott Palmer <swpalmer at gmail.com 
>>>> <mailto:swpalmer at gmail.com>> wrote:
>>>>
>>>>> Since CSS is implicitly tied to layout, validateLayout() seems to 
>>>>> be enough.
>>>>>
>>>>> I don't like "verify" or "check" - To me, these imply a method that is
>>>>> doing checks only and not changing state.  A "verify" method would be
>>>>> something that returns a boolean or throws an exception.
>>>>>
>>>>> Scott
>>>>>
>>>>>
>>>>> On Mon, Jul 8, 2013 at 9:07 AM, Ali Ebrahimi 
>>>>> <ali.ebrahimi1781 at gmail.com <mailto:ali.ebrahimi1781 at gmail.com>>wrote:
>>>>>
>>>>>> just my suggestions:
>>>>>> validation is a side effect free concept. but your validate 
>>>>>> contains css &
>>>>>> layout processing for  Node, so validate is very poor name in 
>>>>>> this case.
>>>>>> May be better use computeBounds instead.
>>>>>> But alternates for validate( if method is a side effect free):
>>>>>> verify()
>>>>>> verfifyNode()
>>>>>> verifyBounds()
>>>>>> checkNode()
>>>>>> checkBounds()
>>>>>>
>>>>>> best Regards
>>>>>> Ali Ebrahimi
>>>>>>
>>>>>>
>>>>>> On Mon, Jul 8, 2013 at 4:50 PM, Martin Sladecek
>>>>>> <martin.sladecek at oracle.com 
>>>>>> <mailto:martin.sladecek at oracle.com>>wrote:
>>>>>>
>>>>>>> The plan is to have a final validate() method.
>>>>>>> Anyway, does anybody have a better suggestion? The validate 
>>>>>>> should do
>>>>>> both
>>>>>>> CSS and layout and I would like to avoid method name that's too
>>>>>> descriptive
>>>>>>> (like validateLayoutAndCSS()) if possible.
>>>>>>> I think the most important thing about the method is that it 
>>>>>>> validates
>>>>>> the
>>>>>>> bounds/metrics of the Node, so maybe validateBounds() ?
>>>>>>>
>>>>>>> -Martin
>>>>>>>
>>>>>>>
>>>>>>> On 07/08/2013 01:52 PM, Anthony Petrov wrote:
>>>>>>>
>>>>>>>> +1
>>>>>>>>
>>>>>>>> The validate()/isValid() in AWT/Swing are often overridden by 
>>>>>>>> user apps
>>>>>>>> for tasks that have nothing to do with the layout. And this 
>>>>>>>> causes a
>>>>>> lot of
>>>>>>>> problems.
>>>>>>>>
>>>>>>>> --
>>>>>>>> best regards,
>>>>>>>> Anthony
>>>>>>>>
>>>>>>>> On 07/08/13 15:20, Pavel Safrata wrote:
>>>>>>>>
>>>>>>>>> Hello,
>>>>>>>>> one more discussion topic: perhaps the "validate" name is too 
>>>>>>>>> general?
>>>>>>>>> Maybe we can come up with more descriptive name? There are all 
>>>>>>>>> kinds of
>>>>>>>>> nodes and sometimes this name can be misleading (not ringing 
>>>>>>>>> the layout
>>>>>>>>> bell at all). For example TextField.validate() may look like 
>>>>>>>>> validating
>>>>>>>>> the input. Also I wouldn't be surprised if users run into 
>>>>>>>>> problems with
>>>>>>>>> custom nodes having their "validate" methods for different 
>>>>>>>>> purposes.
>>>>>>>>> Pavel
>>>>>>>>>
>>>>>>>>> On 3.7.2013 14:33, Martin Sladecek wrote:
>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> JIRA: https://javafx-jira.kenai.com/**browse/RT-31133<
>>>>>> https://javafx-jira.kenai.com/browse/RT-31133>
>>>>>>>>>>
>>>>>>>>>> I propose a single method "public final void validate()" to 
>>>>>>>>>> be added
>>>>>>>>>> to Node class. The validate method would ensure that the metrics
>>>>>>>>>> (layout bounds) of the Node are valid with regards to the current
>>>>>>>>>> scenegraph (CSS & layout).
>>>>>>>>>>
>>>>>>>>>> Together with this change, Parent.layout() will be deprecated.
>>>>>>>>>>
>>>>>>>>>> In my current implementation, validate() method works only if 
>>>>>>>>>> the Node
>>>>>>>>>> is in a Scene. To make it work without a Scene, we'd need to 
>>>>>>>>>> do do
>>>>>>>>>> some small adjustments to CSS (doesn't work with getScene() 
>>>>>>>>>> == null).
>>>>>>>>>> But I'm not sure if such feature would be useful.
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> -Martin
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>
>>
>

More information about the openjfx-dev mailing list