JavaFX Form Validation

[Will Hoover]

+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