Skip to main content

A simple library for Swing UI validation

Posted by timboudreau on April 14, 2009 at 2:14 PM PDT

I recently created a project for Swing UI validation, which is now available on Sun's new open source hosting site, Kenai. I'd love to get some feedback on it. If you have an existing Swing UI and want to add input validation with user feedback to it, you might find it useful.
duckLogo.png

The project can be found here, and there are JAR, source, javadoc and NetBeans library module downloads available. An overview of the project can be found in the project wiki.

I'm currently working on mobile and embedded tools for NetBeans - in particular a marathon race to get the new Java Card development tools ready for release (there's nothing in NetBeans source repository yet - we're waiting for the lawyers to give their okay to move it there).

In both the Java ME modules, and the Java Card modules, there are a lot of pieces of user interface where you want to show the user a “problem” if their input is not valid. In the case of the mobility modules, for a lot of the code, there is no validation implemented at all; for the Java Card modules, I wanted to replace many lines of code that look like

String text = fooTextField.getText();
if (text.trim().length() == 0) {
   setProblem ("Enter foo");
   return false;
}
text = barTextField.getText();
if (text.trim().length() == 0) { ...

This sort of thing is no fun to write, hard to test, and tends to grow like weeds in UI code.

Then there is the issue that some UIs live inside a wizard, and there is one API for showing problems in wizards in NetBeans; there is another API for disabling the OK buttons in dialogs, but there there is no API for showing the user problems; there is another API for showing problems in project customizers, and yet another for option panels. And some of these UIs are used more than one such place.

So I wanted a way to encapsulate and reuse that sort of validation logic, and make it simple to attach it to any UI. The result was the Simple Validation project.

I looked at some of the existing libraries for doing validation - particularly JGoodies Validation. The existing solutions are nice - and if I were probably writing a UI from nothing, I would use one of them.

The two main problems I had with the existing solutions are

  • They tend to want you to rewrite your UI from scratch - for example, to create a model for the data content of the entire UI - which would be nice to have, but is not cost-effective on existing code
  • They tend to be very concept-heavy - A theoretically complete description of UI validation might include problem severities from 0.0F to 1.0F and ProblemSources that extend MessageSources and reflection-based validation of ad-hoc Java Beans. However all of these concepts are just noise from the perspective of writing a simple, narrowly scoped library for validating user input and transparently handling conversion between Document, et. al., and String. The result is extensible, and should be widely useful, but it does not try to “save the world.”

While narrowly scoped, the result is extensible and should be useful in a wide variety of situations. I'd be very interested in feedback on the result - particularly there are a few design decisions that can only be finalized through use in the field:

  • Problem messages can be influenced by the component name and the input value; currently they are not customizable, but if you set a component name, you get a reasonable result (i.e. set the component name to "URL" and if the field is empty, the empty field validator will show a problem URL may not be empty). Messages are localized; do they really need to be customizable?
  • Is the psychadelic duck logo too weird? :-)
  • Are there other UI patterns for displaying problems to users that aren't covered here?
  • Are there concrete, non-estoteric use-cases for more than three levels of problem severity?

One of the goals of the project is to create useful validators for common cases in Swing UIs - i.e. everybody shouldn't have to write their own Validator for integers, or to require non-empty strings. If you have other common cases that would be useful to others, contributions are very welcome - writing a Validator simply requires implementing a single method. The framework takes care of things like adapting a javax.swing.Document to a Validator<String>.

With this project, I also got to try out Kenai for the first time. It is quite slick and speedy - much nicer to work with than java.net or netbeans.org - I'm pretty impressed. The only annoyance or bug that I noticed was that there seems to be no way to modify the content of the home page except for the 500 char project description and a logo image.

Related Topics >>

Comments

I think I could use this library for my project. I've filed a couple of issues for the project in jira. >>Is the psychadelic duck logo too weird?<< No, it's just too big. Simplify it, make it more abstract, make it smaller.

Well, it looks like JSR-303 is targeting every-side bean validation according to "Bean Validation for the Rest of Us – Emmanuel Bernard on JSR 303" http://java.dzone.com/articles/bean-validation-rest-us-%E2%80%93 Why not trying to reuse JSR-303 within the Swing context ?

Thanks Tim I've just seen that. However, some Swing developers want support for i18n "on the fly" (just have to repack/repaint after changing locale). Many UI frameworks (in-house or 3rd-parties) support this. But using SimpleValidation, this would require to change all properties (CLIENT_PROP_NAME) for all panels already visible (or hidden but cached for later reuse). Tha's why I was thinking about one indirection level, which would not make it mandatory to track all visible panels and call a special "initI18n()" method on each.

> using component names in error messages! That's totally disregarding i18n! Actually, the instructions suggest that you set a localized string as the component name. There is also the option to do it with putClientProperty (ValidationListener.CLIENT_PROP_NAME, localizedName) - this will take precedence over the component name if present - I know component names are sometimes used for other things; but I also want to keep it as simple as possible for the user for the common case, which is that it is possible to use a localized string for the component name.

Hi, I've just taken a quick look at the wiki, I will probably give this project a try (in a couple fo weeks, I am quite busy right now). However, there's one blocking point: using component names in error messages! That's totally disregarding i18n! In addition, many Swing developers (me at least) use component names for GUI testing (I used that with abbot and FEST) and most often they follow conventions to ensure unique names of components across the whole GUI. Would it be difficult to improve this point and have the library look up somehow (add one indirection level: by default using identity name->name) for a user-meaningful name from the component name? Just my 2 cents (after just 15')