[API Review]: Node validation

Thu Jul 11 07:21:10 PDT 2013

On 11/07/2013 3:16 AM, Martin Sladecek 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.

Steve

>
> Regards,
> -Martin
>
> On 07/10/2013 08:25 PM, steve.x.northover at oracle.com wrote:
>> Hi Martin,
>>
>> How about exposing the concept of applying CCS to the programmer? 
>> Let's say we add  applyCSS() that does exactly what it says (applies 
>> CSS when called).
>>
>> Here are a few use cases:
>>
>> 1) Positioning a popup:
>>
>>     node.applyCSS()
>>     node.autosize();
>>     // width and height are now valid
>>
>>     node.applyCSS();
>>     // pref width and height are now valid
>>
>> 2) Taking a snapshot:
>>
>>     node.applyCSS();
>>     node.autosize();
>>     node. layout()
>>     // take the snapshot (when talking multiple snapshots, don't need 
>> to reapply CSS)
>>
>> 3) Find the location of a child control:
>>
>>     node.applyCSS();
>>     node.autosize();
>>     node.layout();
>>     // find the child control by id, the bounds are valid
>>
>> Richard had talked about applying the CSS automatically so that when 
>> you ask for the width etc., if the width is not calculated, it gets 
>> calculated and returned.  There is nothing in the applyCSS() API the 
>> precludes us from writing this automatic code in the future. In that 
>> case, applyCSS() would become a hint or a no-op.
>>
>> Steve
>>
>>
>> On 10/07/2013 2:50 AM, Martin Sladecek wrote:
>>> +1
>>>
>>> -Martin
>>>
>>> On 07/09/2013 05:06 PM, Pavel Safrata wrote:
>>>> To me this sounds best so far. Perhaps updateVisuals() would be 
>>>> even better?
>>>> Pavel
>>>>
>>>> On 8.7.2013 18:45, Scott Palmer wrote:
>>>>> validateVisuals() ?
>>>>> Or something with the word "visual" as it combines layout and 
>>>>> other CSS
>>>>> information.
>>>>>
>>>>> Scott
>>>>>
>>>>>
>>>>> On Mon, 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
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>
>>>>
>>>
>>
>