Aw: Re: Validation Support

Sat Mar 9 04:46:22 UTC 2024

I think there is definitely room for improvement here, but I think most 
controls can currently be build externally, if you are willing to do all 
the work.  Your control may suffer however when you need to integrate 
with event, focus handling or keyboard navigation.  Skins and Behaviors 
are not something that are a requirement to use to build a custom 
control, although they can make it easier to adapt existing controls, up 
to a point.

The problem with making things public is that this means they must be 
specified, and that we must be **very** sure that it is a solid API that 
will stand the test of time. That's often a significant time investment 
that could seriously delay building a complicated control like TableView.

I think Skins especially are very hard to design in such a way that they 
have sensible public/protected methods. They often deal with very 
specific layout or design problems, that could restrict the evolution of 
the control if there is a fundamental change in how the Skin is 
constructed. Just imagine if the very first TableViewSkin had all its 
methods public, and that they couldn't be changed up to this day because 
the Skin may have been subclassed by 3rd parties.

This is why I would advocate instead to make it easier to replace Skins 
entirely (by being able to copy the code). The biggest issue there is 
that Skins contain many non-public helpers, primarily their Behaviors.  
Making Behaviors public would first require unblurring the lines between 
what is Skin and what is Behavior (not doing so will just make it a bad 
API that will cause many bugs and problems over the coming years).  That 
would also mean that some controls need some rework to divide the work 
over their Skin and Behavior correctly, as for many controls the split 
is there only in name, and is discarded as soon as it was inconvenient.

With Behaviors public and some helpful API's (like Font measurement) 
having a public equivalent, the route to just copy only a Behavior or 
Skin opens up.  Being able to copy them means that you don't need to 
fully open up and specify every private method in Skins/Behaviors 
(designing API's is hard, but designing API's that can be sub classed 
while not restricting an endless set of possibilities that a Skin 
subclass may need is impossible).

--John

On 08/03/2024 00:40, Marius Hanl wrote:
> One note here regarding that a lot of things are final in JavaFX:
> The problem is not that everything is final - this is intended and 
> makes sense, since we speak mostly of properties here. Overriding 
> those will not give you any benefit.
> You mostly want to override e.g. Controls if you add something new to 
> it (a new property) or may just want to set another default skin.
> This design is mostly superior than e.g. Swing, where you can override 
> things and easily break something if not too careful.
> Pretty sure that this were some lessons learned from the development 
> of Swing.
> The biggest problem is rather that a lot of methods are package 
> private or 'Accessors' are used to call specific methods, which is not 
> just a questionable design but also restrict the usage.
> It is often not possible to override even a minor feature inside the skin.
> So you may rather want to recreate the skin then, and copy the 
> existing skin and just change some stuff. But this will mostly not 
> work either, as there is a lot of internal API usage, e.g. Accessors 
> or some com.sun.javafx.scene.control.skin.Utils usage.
> Want to set the width of a TableColumn? Well, the internal 
> com.sun.javafx.scene.control.TableColumnBaseHelper.TableColumnBaseAccessor can 
> do that, you can not.
> Get the width of a text String? Well, you can use 
> com.sun.javafx.scene.control.skin.Utils.computeTextWidth...
> Offtopic: Maybe we should collect the things which should be public in 
> our opinion at one point to (better) get this started as well?
> -- Marius
> *Gesendet:* Montag, 04. März 2024 um 08:13 Uhr
> *Von:* "Robert Lichtenberger" <r.lichtenberger at gmail.com>
> *An:* openjfx-dev at openjdk.org
> *Betreff:* Re: Validation Support
> First off, as the original author of ValidatorFX I feel flattered by the
> suggestion of including it into the JavaFX core :-).
>
> Some thoughts / insights I gained from developing ValidatorFX:
>
> * ValidatorFX is (with the possible exception of GraphicDecoration.java)
> rather trivial code and also very small (< 1k lines of library code).
> But it seems to have filled a market gap according (a few thousand
> unique ip downloads every month, issues from ca. a dozen people so far,
> even a few PRs). These "market gaps" get filled rarely because they are
> not a commercially attractive opportunity. On the other hand if you
> decide (like I did with ValidatorFX) to take your closed source solution
> and make it open source, you are "rewarded" by increased overhead at
> first. But the market gaps exist and hinder broader JavaFX adoption.
>
> * ValidatorFX is probably only one part needed for application
> developers. The other part is a form library that allows to layout
> fields, have buttons (that are connected to field validation, etc.). It
> looks like this is written again and again by every application developer.
>
> * To answer John's question if JavaFX could do more to help make tools
> like ValidatorFX easy to build:
>
> ** There's the TooltipWrapper class in ValidatorFX which works around
> JDK-8090379. Not a big deal but something many application developers
> will probably be annoyed by.
>
> ** On a more general note, if I were the king of the JavaFX universe for
> one day, I would forbid anyone to make classes or methods final. As an
> application developer I prefer to be able to tweak things easily, even
> if they may break in the future (which they will anyway ...). Don't take
> that decision away from me, it's patronizing. But I guess this is one of
> those things that depend very much on which side of the equation you
> are, so don't take my troll bait :-).
>
>
> --Robert
>
>
> Am 03.03.24 um 02:10 schrieb John Hendrikx:
> > Hi Dirk,
> >
> > That is a very nice framework, and although I wouldn't be against its
> > inclusion in FX, I'm more wondering if JavaFX could do more to help
> > make tools like ValidatorFX easy to build.
> >
> > I'm not quite sure how one can use not having validation as an
> > argument against using FX, when there clearly are free alternatives
> > available.  Surely not everything can or should be part of the base
> > framework?  A line must be drawn somewhere, especially when there are
> > very few core FX developers.
> >
> > I'd much rather see work being done on things that can't be provided
> > by 3rd parties, preferably by opening up more parts of FX with well
> > specified API's.
> >
> > --John
> >
> > On 01/03/2024 11:59, Dirk Lemmermann wrote:
> >> Hi everyone,
> >>
> >> I updated the validation framework ValidatorFX today in our project
> >> to the latest release and I really like it a lot. It is a small
> >> compact API and works with any observable as opposed to the
> >> validation support provided by ControlsFX.
> >>
> >> Using it made me wonder whether it would make sense to bundle it or
> >> something like it directly with JavaFX. Developers often mention
> >> missing validation support as a drawback of using JavaFX. Adding this
> >> would take one item off from the list of arguments against using 
> JavaFX.
> >>
> >> Many UI frameworks do have built-in validation support, e.g. Vaadin
> >> [0], Angular, [1], or QT [2]
> >>
> >> What do you think?
> >>
> >> —Dirk
> >>
> >> [0]
> >> 
> https://vaadin.com/docs/latest/binding-data/components-binder-validation
> >> [1] https://angular.io/guide/form-validation
> >> [2] https://doc.qt.io/qt-6/qtquick-input-textinput.html
> >>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240309/fbe8b34f/attachment-0001.htm>