Input validation in Swing application

[Lars-Otto Nymoen]

Hi!

I was hoping someone here could give me some help on how to handle
input validation in a Swing application. The structure (layering) of
the app is something like this: SwingForm --> DataAccessObject -->
Database

My main question is where to put the validation code. Two scenarios
come to mind:

1. Let the DataAccessObject handle the validation, an throw an
exception when it fails. The exception would be caught by the
SwingForm which then gives the user a response.

2. Let the SwingForm itself handle the validation without the use of
exceptions.

So the bottom line is: who should be responsible of handling the
validation. I think scenario 1 seems like a good aproach, but I'm not
sure it's "correct" to handle form validation as exceptions. Bear in
mind that I'm quite new at Java programming, so if you have other
scenarios please let me know.

 

[Karsten Lentzsch]

I was hoping someone here could give me some help on how to handle
input validation in a Swing application. The structure (layering) of
the app is something like this: SwingForm --> DataAccessObject -->
Database

I provide a validation demo that highlights problems,
concepts and solutions around data validation, see
http://www.jgoodies.com/freeware/validationdemo/

The underlying tutorial compares different approaches:
Who shall validate?
When to validate?
How to provide hints for the required data?
How to present validation results?
How to render components with invalid data?

The validation project's focus is to collect
these problems, not my reference solution.

I've found it useful to validate on the server side,
or in the domain layer, in the presentation layer,
or in a middle layer between the domain and views
(where the view models are located).
All these positions make sense. In the domain
and in the model layer, I met two approaches:
one where the domain object can validate itself,
and another where a separate domain validator
validates an associated domain object.

Basically you can reuse validation better if
it is closer to the domain layer. On the other
hand, sometimes you have views that have no
representation in the domain, so you must validate
closer to the view layer.

I'm in the process of extending the library
and will likely update the demo next week.

Hope this helps. Best regards,
Karsten

 

[Chris Smith]

I was hoping someone here could give me some help on how to handle
input validation in a Swing application. The structure (layering) of
the app is something like this: SwingForm --> DataAccessObject -->
Database

My main question is where to put the validation code. Two scenarios
come to mind:

1. Let the DataAccessObject handle the validation, an throw an
exception when it fails. The exception would be caught by the
SwingForm which then gives the user a response.

2. Let the SwingForm itself handle the validation without the use of
exceptions.

The answer is to definitely do #2, and then do a variation on #1 as
well.

For #2, simple type validation (such as that a field is a number, or is
non-empty) belongs directly in the GUI code. In fact, it would be ideal
if you could choose input components that make violation of types
impossible (such as spinners for number entry, calendars for dates,
etc.) If the validation involves business rules, though, then your
business model layer should expose the capability to validate an entry
*without* actually modifying the data.

Your #1, wherein the interface to actually modify the data would throw
an exception, ideally goes in the database as a second check to ensure
that the validation in the front-end GUI was successful. Databases are
good at that kind of thing. If such an exception is thrown, it should
be treated as a code error, not as a validation error. If the database
doesn't allow you to define sufficient validation using triggers and
constraints, then you should define this data integrity check in the
data access object (at least until you switch to a database that is
capable of doing so).

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Lars-Otto Nymoen]

The answer is to definitely do #2, and then do a variation on #1 as
well.

For #2, simple type validation (such as that a field is a number, or is
non-empty) belongs directly in the GUI code. In fact, it would be ideal
if you could choose input components that make violation of types
impossible (such as spinners for number entry, calendars for dates,
etc.) If the validation involves business rules, though, then your
business model layer should expose the capability to validate an entry
*without* actually modifying the data.

It was the simple type validation you mention above I was thinking
about, and what you say makes sense. By the way, do you know of any good
calendar components?

Your #1, wherein the interface to actually modify the data would throw
an exception, ideally goes in the database as a second check to ensure
that the validation in the front-end GUI was successful. Databases are
good at that kind of thing. If such an exception is thrown, it should
be treated as a code error, not as a validation error. If the database
doesn't allow you to define sufficient validation using triggers and
constraints, then you should define this data integrity check in the
data access object (at least until you switch to a database that is
capable of doing so).

The database is capable of doing this integrity check, so that will not
be a problem. One last thing: Should the DataAccessObject be responsible
for handling the SQLException (for example during an insert operation),
or should it just throw it for the gui to catch. The latter seems like
the best approach, since the gui eventually has to give some kind of
understandable response to the user.

Thank you very much for your input.

 

[Lars-Otto Nymoen]

Lars-Otto Nymoen wrote:

I provide a validation demo that highlights problems,
concepts and solutions around data validation, see
http://www.jgoodies.com/freeware/validationdemo/

I will certainly take a look at this. I recently downloaded your Looks
and Forms libraries, and plan to incorporate them into my application. I
really appreciate your work, and it is very nice that you offer them
free of charge.

 

[Bent C Dalager]

It was the simple type validation you mention above I was thinking
about, and what you say makes sense. By the way, do you know of any good
calendar components?

You can use a JSpinner with an appropriate date format. Of course,
this is not as much a calendar component as it is a date component.

Cheers
Bent D