[API Review]: Node validation
Scott Palmer
swpalmer at gmail.com
Mon Jul 8 09:45:01 PDT 2013
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
> >>>>>>
> >>>>>
> >>>>>
> >>>
> >>
>
>
More information about the openjfx-dev
mailing list