Re: Validation Support
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
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
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
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
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
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
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 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 appli
Re: Re: Validation Support
* 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 a
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
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: 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 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 Java
Aw: Validation Support
I also like the idea of having some kind of Validation in JavaFX. But I'm also unsure how/what to implement. What I implemented for my application is some kind of Validator framework, which is: - Binding itself to the textProperty() of TextInputControls - Binding itself to the selected item for ComboBoxes I also implemented some kind of validation for tables, where cells report back to the table if there are invalid/valid, so that we can easily know if a table is considered valid or not. The user modified idea froma Michael is a good first start for an idea where JavaFX may help (in this case I can always bind to one property, making the Validator code at least easier). I still may need to implement when this property is set (for some Controls as least). Another usecase we often need is to show a graphic when a Control is considered invalid. This is actually very tricky. If you check ValidatorFX, it injects a so called GraphicDecorationStackPane as scene root (replacing your own root) in order to manage the error graphics that are shown when a Control is invalid. We use another approach (which I think I saw at ControlsFX - not sure though) where we 'hope' that the Control has a SkinBase skin, and if so access the children via #getChildren() to add our (unmanaged) graphic node and relocate it where needed (mostly bottom left, with a Tooltip attached to the graphic). It would be nice if JavaFX can help here as well so that we do not need to do rather questionable checks for SkinBase and that stuff. TLDR: - user modified API or something similar is a good first step - an easy way to add an e.g. error graphic node to an invalid Control, like in ControlsFX or ValidatorFX, without handling much ourself. - Marius Gesendet: Freitag, 01. März 2024 um 11:59 Uhr Von: "Dirk Lemmermann" An: "openjfx-dev" Betreff: Validation Support 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
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
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
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
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
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
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 > <mailto:dlemmerm...@gmail.com>> 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
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 <mailto:dlemmerm...@gmail.com>> 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
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 > >
Validation Support
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