Re: Validation Support

[John Neffenger]

On 3/9/24 10:30 AM, Marius Hanl wrote:
However, I found this old email thread. Two answers which reflect what 
we said:

https://mail.openjdk.org/pipermail/openjfx-dev/2013-September/010067.html
https://mail.openjdk.org/pipermail/openjfx-dev/2013-September/010094.html


Wow, good find! Thank you, Marius. I am pleasantly surprised to see some 
of the same people in that old discussion now participating in this one.


In reading the thread, it seems the decision to keep the JavaFX API so 
closed was made primarily by Richard Bair based on his own experience, 
and is perhaps best explained in Item 19 of /Effective Java, Third 
Edition./ by Joshua Bloch. Summary: inheritance violates encapsulation, 
so designing a class for inheritance "is not a decision to be undertaken 
lightly."


I don't have the experience to offer my own opinion, but with all the 
talk of opening things up, I thought it might be a good time to revisit 
the history. You know, "Those who cannot remember the past are condemned 
to repeat it," and all that. 


John

Aw: Re: Validation Support

[Pedro Duque Vieira]

Regarding the comment that the design of JavaFX is vastly superior to
Swing.. I would argue against bluntly stating that (not criticizing who
said that).

There are obviously cons and pros to each approach. On the one side Swing
was much easier for developers to extend and to add functionality on top
whereas JavaFX is harder. JavaFX on the other hand can evolve in a more
safe way since the implementation details are less exposed to developers. I
wouldn't say one is better than the other, I guess it depends on the
scenario you're in. There are pros and cons to each. There are certainly
lots of developers that preferred the Swing approach (myself included) and
others  would probably prefer the JavaFX one (not sure which one the
majority prefers).

When the JavaFX team first made this decision there were some
conditions that don't hold true anymore, so the underlying scenario has
changed.
Back then it was assumed that the user would be the one responsible for
installing and updating the JRE that was going to be used in the app (so
you were never sure which jre the user was on). That's no longer the case
as almost all apps ship with its own JRE.

More importantly, back then the javafx team was much bigger, so changes
could be made at a faster pace. Yes JavaFX was closed but if the JavaFX
team saw there was a need from developers for some feature/API it could be
added much more quickly while still not exposing too much of the
implementation.

I wonder if in some parts we can compromise if we see there's a need. Like
exposing some parts but adding a annotation or something saying that we're
still experimenting or/and some scenarios might not be supported, so be
careful using this, etc... (that's somewhat already happened in javafx 8
with the @treatAsPrivate annotation)
Just some food for thought...

I like the compromise that John Hendrikx suggested of copy pasting code and
changing the copy pasted code (given the internal API usage is solved). I
have done that sometimes. I just have one question though: does the license
of JavaFX permit a commercial app to have that in its own app (copy pasted
code from the JavaFX SDK)?

I have already said that, but what I really would like JavaFX to provide
would be more points of extension, things like the possibility to
extend the CSS parser and add more CSS primitives, etc...
Bottom line: make the API more powerful in terms of what the developer can
do. Right now if you want to do something slightly less standard you're
likely to hit a bunch of hurdles...

My 2 cents..





-- 
Pedro Duque Vieira - https://www.pixelduke.com

Re: Validation Support

[John Hendrikx]

On 08/03/2024 07:37, Robert Lichtenberger wrote:


One major pain point that we have at the moment is CSS performance, I 
think (but did not investigate yet) that some kind of performance 
regression happened somewhere between 17 and 21.


I think this was addressed already, see here: 
https://github.com/openjdk/jfx/pull/1314


The fix is in JFX22, not sure if it should perhaps be back ported to JFX21.

While I was looking at that regression, I also checked if there was more 
performance to be gained.  You can find those changes in 
https://github.com/openjdk/jfx/pull/1316


--John

Aw: Re: Validation Support

[Marius Hanl]

Yes, John made some good points about how the Behaviour API could look like, which I also agree on.


CSS will get performance improvements with the changes made by John in JDK-8322964, but I would agree that there is more in the CSS code which should/could be optimized.

 

-- Marius

 

Gesendet: Freitag, 08. März 2024 um 07:37 Uhr
Von: "Robert Lichtenberger" 
An: openjfx-...@openjdk.java.net
Betreff: Re: Validation Support


 

Am 08.03.24 um 00:40 schrieb Marius Hanl:



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.




Yes, I had such a problem yesterday. TableView uses + as shortcut to toggle selection of current row. I want to use that key combination as a "global" shortcut however. I have a regular menu bar with a menu item that has + as accelerator.

Now I need to remove that bit from the TableView's behavior. I've seen that there are efforts under way to make behavior public API. I would really welcome that :-).

 

BTW, https://bugs.openjdk.org/browse/JDK-8088068 is also an issue concerning accelerators that I currently need a separate class as workaround.

 

Other issues that I currently work around somehow (inconvenient, but no showstopper):

JDK-8092315, JDK-8087981, maybe also JDK-8123117, but I think that on is correctly closed as  "not an issue", will have to check.

To put this into perspective, we have a lot more references to JavaFX issues in our code, which have all been fixed :-).

 

One major pain point that we have at the moment is CSS performance, I think (but did not investigate yet) that some kind of performance regression happened somewhere between 17 and 21.

 

Overall speaking, with the ongoing efforts for a RichText-control and making behavior public API, I think JavaFX is definitely on the right track, at least from my perspective :-).

 

--Robert

Aw: Re: Re: Validation Support

[Marius Hanl]

I also remember that but not sure where I got this from as well.


 

However, I found this old email thread. Two answers which reflect what we said:

 

https://mail.openjdk.org/pipermail/openjfx-dev/2013-September/010067.html

https://mail.openjdk.org/pipermail/openjfx-dev/2013-September/010094.html

 

-- Marius

 

Gesendet: Freitag, 08. März 2024 um 02:49 Uhr
Von: "John Neffenger" 
An: openjfx-dev@openjdk.org
Betreff: Re: Aw: Re: Validation Support


On 3/7/24 3:40 PM, Marius Hanl wrote:


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.




That's what I remember, too, but I can't find any sources for it online, so maybe I'm just imagining things. 

Rather than subclasses breaking things, though, I remember reading that the decision to allow the Swing classes to be so extensible had made it difficult for Oracle to maintain and enhance Swing itself. The JavaFX developers decided early on not to repeat that mistake.

Do I remember correctly? Does anyone have links or even first-hand knowledge?

John

Aw: Re: Re: Validation Support

[Marius Hanl]

I second this.

By no means we should open up everything in the Skins.

Some things may makes sense, some of them probably do not and I also would rather advocate copying and adjusting it as needed for bigger changes.


 

-- Marius

 

Gesendet: Samstag, 09. März 2024 um 05:46 Uhr
Von: "John Hendrikx" 
An: openjfx-dev@openjdk.org
Betreff: Re: Aw: Re: Validation Support


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" 
An: openjfx-dev@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 co

Re: Aw: Re: Validation Support

[John Hendrikx]

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" 
*An:* openjfx-dev@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 f

Re: Re: Validation Support

[Andy Goryachev]

  *   Offtopic: Maybe we should collect the things which should be public in 
our opinion at one point to (better) get this started as well?


My sentiment exactly!  Marius, would you like to create a new thread?

Thanks!
-andy

From: openjfx-dev  on behalf of Marius Hanl 

Date: Thursday, March 7, 2024 at 15:40
To: Robert Lichtenberger 
Cc: openjfx-dev@openjdk.org 
Subject: Aw: Re: Validation Support
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" 
An: openjfx-dev@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

Re: Validation Support

[Robert Lichtenberger]

Am 08.03.24 um 00:40 schrieb Marius Hanl:

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.


Yes, I had such a problem yesterday. TableView uses + as 
shortcut to toggle selection of current row. I want to use that key 
combination as a "global" shortcut however. I have a regular menu bar 
with a menu item that has + as accelerator.


Now I need to remove that bit from the TableView's behavior. I've seen 
that there are efforts under way to make behavior public API. I would 
really welcome that :-).



BTW, https://bugs.openjdk.org/browse/JDK-8088068 is also an issue 
concerning accelerators that I currently need a separate class as 
workaround.



Other issues that I currently work around somehow (inconvenient, but no 
showstopper):


JDK-8092315, JDK-8087981, maybe also JDK-8123117, but I think that on is 
correctly closed as  "not an issue", will have to check.


To put this into perspective, we have a lot more references to JavaFX 
issues in our code, which have all been fixed :-).



One major pain point that we have at the moment is CSS performance, I 
think (but did not investigate yet) that some kind of performance 
regression happened somewhere between 17 and 21.



Overall speaking, with the ongoing efforts for a RichText-control and 
making behavior public API, I think JavaFX is definitely on the right 
track, at least from my perspective :-).



--Robert

Re: Aw: Re: Validation Support

[John Neffenger]

On 3/7/24 3:40 PM, Marius Hanl wrote:
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.


That's what I remember, too, but I can't find any sources for it online, 
so maybe I'm just imagining things. 


Rather than subclasses breaking things, though, I remember reading that 
the decision to allow the Swing classes to be so extensible had made it 
difficult for Oracle to maintain and enhance Swing itself. The JavaFX 
developers decided early on not to repeat that mistake.


Do I remember correctly? Does anyone have links or even first-hand 
knowledge?


John

Aw: Re: Validation Support

[Marius Hanl]

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" 
An: openjfx-dev@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

Re: Validation Support

[Johan Vos]

I second what John and Michael say (provide more APIs in OpenJFX that can
only realistically be implemented in OpenJFX).

I believe the experience from Robert as the creator of ValidatorFX is
extremely valuable to this. The key question that might help to see what we
need here is: "What would have made it easier to create ValidatorFX (I hear
the point of not using final everywhere)?"

- Johan



On Mon, Mar 4, 2024 at 10:03 AM Michael Strauß 
wrote:

> I would not be in favor of adding any particular data validation
> framework to JavaFX. Data validation comes in all kinds of different
> shapes and sizes, which makes it a good fit for (opinionated)
> third-party libraries. However, I fully agree with John that JavaFX
> should provide more APIs that can only realistically be implemented in
> FX. I've proposed a "significant interaction" API, which is crucial
> for many data validation scenarios:
> https://mail.openjdk.org/pipermail/openjfx-dev/2023-March/039327.html
>
>
> On Fri, Mar 1, 2024 at 12:50 PM 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
> >
>

Re: Validation Support

[Robert Lichtenberger]

Am 04.03.24 um 10:01 schrieb Michael Strauß:

I would not be in favor of adding any particular data validation
framework to JavaFX. Data validation comes in all kinds of different
shapes and sizes, which makes it a good fit for (opinionated)
third-party libraries.


I agree with that while at the same time trying to provide different 
options (opinions) with ValidatorFX.




However, I fully agree with John that JavaFX
should provide more APIs that can only realistically be implemented in
FX. I've proposed a "significant interaction" API, which is crucial
for many data validation scenarios:
https://mail.openjdk.org/pipermail/openjfx-dev/2023-March/039327.html


Shame on me, I totally missed that thread. It contains a lot of insight.

Interestingly, ValidatorFX (since 0.5.0) supports these different modes 
at the moment:


* immediate (which you call "Eager" in the thread above)

* explicit (which you call "Submit")

* immediate-after-submit: This leaves the user undisturbed until they 
first press the "submit" button. After that, the form changes into 
immediate mode, only then highlighting everything that has to be corrected.


* explicit with immediate clearing: Validation happens on submit, but as 
soon as the user changes any of the validated properties, validation is 
reset so that the user has some "breathing space" when correcting their 
input


An implementation of your "second" mode, which will redo validation on 
"significant user input" is missing at the moment. But I think this 
should be possible to do with sth. like a 
.checkedOn(ObservableValue userModifiedProperty) method.
That will still leave the burden of defining the userModifiedProperty to 
the application but that is probably for the best: For a "required" 
check, getting and losing the focus is not a significant user input, 
while a field that requires either no input at all or a valid SSN may 
use the lost focus for that.


To that end, I've just created 
https://github.com/effad/ValidatorFX/issues/37.


--Robert

Re: Validation Support

[Michael Strauß]

I would not be in favor of adding any particular data validation
framework to JavaFX. Data validation comes in all kinds of different
shapes and sizes, which makes it a good fit for (opinionated)
third-party libraries. However, I fully agree with John that JavaFX
should provide more APIs that can only realistically be implemented in
FX. I've proposed a "significant interaction" API, which is crucial
for many data validation scenarios:
https://mail.openjdk.org/pipermail/openjfx-dev/2023-March/039327.html


On Fri, Mar 1, 2024 at 12:50 PM 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
>

Re: Validation Support

[Robert Lichtenberger]

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

Re: Validation Support

[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

Re: Validation Support

[Dirk Lemmermann]

A quick look at the validator project readme should clarify things: 
https://github.com/effad/ValidatorFX

Dirk


> Am 02.03.2024 um 19:59 schrieb Dirk Lemmermann :
> 
> Ensuring that only valid characters are entered does not ensure that the 
> entered value is correct. What developers require is data validation / form 
> validation.
> 
> Dirk
> 
> 
> 
>> Am 02.03.2024 um 16:28 schrieb Nir Lisker :
>> 
>> Hi Dirk,
>> 
>> JavaFX has some input validation support in terms of focus control and 
>> rejecting invalid characters. Can you  explain what your proposal adds? Are 
>> there JBS issues asking for this?
>> 
>> Thanks, 
>> Nir
>> 
>> On Fri, Mar 1, 2024, 13:50 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
>>> 
> 

Re: Validation Support

[Dirk Lemmermann]

Ensuring that only valid characters are entered does not ensure that the 
entered value is correct. What developers require is data validation / form 
validation.

Dirk



> Am 02.03.2024 um 16:28 schrieb Nir Lisker :
> 
> Hi Dirk,
> 
> JavaFX has some input validation support in terms of focus control and 
> rejecting invalid characters. Can you  explain what your proposal adds? Are 
> there JBS issues asking for this?
> 
> Thanks, 
> Nir
> 
> On Fri, Mar 1, 2024, 13:50 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
>> 

Re: Validation Support

[Nir Lisker]

Hi Dirk,

JavaFX has some input validation support in terms of focus control and
rejecting invalid characters. Can you  explain what your proposal adds? Are
there JBS issues asking for this?

Thanks,
Nir

On Fri, Mar 1, 2024, 13:50 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
>
>