[API Review]: Node validation

Martin Sladecek martin.sladecek at oracle.com
Mon Jul 8 11:08:24 PDT 2013

I think there would be a problem with property invalidation at least. A 
property (like layoutBounds or any property set by CSS) would change on 
get() although there was no invalidation notification (unless we'd 
invalidate all affected properties on CSS/layout change - but most of 
them would NOT change probably).

This would also affect bindings. Unless we'd invalidate everything that 
might be affected, the bindings would not trigger the CSS/layout pass 
when needed.


On 07/08/2013 07:01 PM, Richard Bair 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> 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> 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> 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>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>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