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.b...@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 <swpal...@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.ebrahimi1...@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.slade...@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 > >>>>>> > >>>>> > >>>>> > >>> > >> > >
