JavaFX Form Validation

[Daniel Zwolenski]

I'm going to echo some previous comments (including my own) on this topic. 

My vote is for JFX to provide low level building blocks for developers to hook in to and then for open source tool kits (like Jfxtras) to provide the higher level tools. So JFX would have no validation framework but instead would provide ways to, for example, visually highlight nodes, and a community built toolkit would use this to provide a validation framework. 

The reason for this: there is no one-size-fits-all solution. Different platforms, GUI styles and application domains will want to do something different. Some people will want component validation, some domain, some want to highlight error cells, others show error messages on submit; annotations, external validators, kinetic feedback on mobile devices, etc, etc. 

The passionate, varied opinions we've seen on this thread have demonstrate well the diverse approaches out there already. Few of them are 'wrong', most have merit. 

When trying to put together my own little validation framework based on JSR303, the raw tools in JFX were nearly perfect. The only thing I was really in need of was a way to visually annotate a Node (eg add a layer on top such as a red X). It would also be useful to be able to access the 'value' of a control in a consistent way and to be able to remove CSS styles and have the corresponding attributes be removed. These were suggestions I raised in this forum when I first joined it. 
I imagine I could dig up the email if it helped (although I think someone might have linked to it already in this thread). 

I'd prefer to see effort by the core JFX team put into these sorts of low level enhancements than in high level toolkits. Only the JFX team can do the low level stuff, and if the low level stuff is there then the community can do the high level stuff. 

For super bonus points, it would be really cool if the JFX team then helped the community develop the third party toolkits. Ie Jonathon, instead of you building a validation framework, I'd love it if you could shepherd those on this forum who are keen to build an external toolkit(s). There might be one group wanting to build something based on the JSRs and another wanting to build something around the Controls themselves. If you were involved in these architectures then you would be able to evolve the core jfx base features in a way that supported these. 

With Oracle sanctioning these could become defacto standards, similar to what the SwingX stuff became. These would be as good as a 'built in' solution but with none of the limitations, such as not being able to use 3rd party jars, having to be only one official version, and having to be tied to the JFX/JRE release schedule. 

That's my two cents anyway. 



On 13/06/2012, at 9:44 PM, "Will Hoover" <java.whoover at gmail.com> wrote:

> +1 for JSR-349
> 
> -----Original Message-----
> From: openjfx-dev-bounces at openjdk.java.net
> [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Randahl Fink
> Isaksen
> Sent: Wednesday, June 13, 2012 6:00 AM
> To: openjfx-dev at openjdk.java.net; jonathan.giles at oracle.com
> Subject: Re: JavaFX Form Validation
> 
> Jonathan, I think there is an important aspect of form validation which we
> have not yet discussed. In traditional web-based UI's, validating data at
> the UI layer may be considered sufficient, since the organization has total
> control over the UI layer validators, as they are executed server side. With
> JavaFX this is quite different, as the UI layer is running outside the
> server on an end user's PC.
> 
> So, if the validity of certain fields is critical to system data integrity,
> it would be wrong to only run the validators in the JavaFX client
> application, since the application could have been modified, the network
> communication could have been compromised, etc. Consequently, the JavaFX
> validation system must be one, which allows rerunning the validators
> server-side, to ensure that developers will not have to rewrite validation
> code in multiple layers of the same application.
> 
> As an example, if my application has specific requirements for user
> passwords, I would like to be able to define some kind of PasswordValidator
> and have JavaFX run it before data is sent to the server side; but
> obviously, I would want to rerun this PasswordValidator on the server before
> updating a user's password, to ensure that a malicious person could not have
> circumvented the validation by, say, altering the JavaFX application Java
> code.
> 
> I noticed this topic is also discussed in JSR-349, the specification for
> Bean Validation:
> 
> Validating data is a common task that occurs throughout an application, from
> the presentation layer to the persistence layer. Often the same validation
> logic is implemented in each layer, proving to be time consuming and error-
> prone. [...]
> 
> The validation API developed by this JSR is not intended for use in any one
> tier or programming model. It is specifically not tied to either the web
> tier or the persistence tier, and is available for both server-side
> application programming, as well as rich client Swing application
> developers. This API is seen as a general extension to the Java- Beans
> object model, and as such is expected to be used as a core component in
> other specifications. Ease of use and flexibility have influenced the design
> of this specification.
> 
> Now, I believe we should think twice before ditching the years of work which
> has gone into developing first JSR-303 and then the follow-up JSR-349.
> Making JavaFX compatible with these standards would mean
> 
> 1. JavaFX validation would be recognizable to those Java EE developers who
> are already familiar with the Bean Validation standard.
> 2. JavaFX would avoid fragmenting the Java platform once again by
> introducing yet another solution to the same problem.
> 3. JavaFX applications would be able to reuse validators written for other
> (non-JavaFX) Java systems.
> 4. The validators used in JavaFX would be rerunnable in any application
> layer.
> 
> On our openjfx-dev mailing list the JSR-303 and JSR-349 have been critizised
> for requiring annotations in the domain model classes, as in the following
> example:
> 
> public class Address {
>     @NotNull(message="the city is mandatory", payload=Severity.Error.class)
>     String getCity() {...}
> }
> 
> Having thought about this for a while, I disagree with the critics. The
> domain model classes are part of the API contract which the server presents
> to clients, so what would be more natural than strengthening this contract
> by adding validation constraints to it? Ideally, The PasswordValidator I
> mention above should be delivered alongside my domain model User class so
> both the JavaFX client application layer as well as the server business
> logic layer of my application could run it and be certain that the password
> specified lives up to system requirements.
> 
> As we all know, JavaFX is but a single piece in the large technology puzzle
> upon which our applications are built. It is crucial, that JavaFX fits with
> the other pieces.
> 
> Yours
> 
> Randahl
> 
>