JavaFX Form Validation

[Randahl Fink Isaksen]

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