Login | Register   
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Extend the JDK Classes with Jakarta Commons, Part I

Explore the components in the Jakarta Commons set of reusable classes and you'll be convinced that most of them should be part of the JDK. Learn which ones you should use in your projects.


advertisement
y now, almost everyone in the Java community has heard about Jakarta Commons, the set of reusable classes that various Jakarta projects use. But did you know that these classes also are available as separate components, which you can use in your Java projects? This article is the first in a three-part series that explores the various Jakarta Commons components and presents real-world example applications to illustrate how to use them. The examples don't only illustrate the Commons components; they are complete, modular applications that highlight the useful features you can reuse in typical Java projects.

In particular, this first installment explores the following components:

  • Validator
  • Collections
  • Chain
  • Functors
  • Lang

The article also includes complete source code that you can run by launching the test cases with JUnit for each of the examples.



Author Note: A basic knowledge of object-oriented programming (OOP) and the Gang of Four design patterns (Command, Decorator, Singleton, Factory, Chain of Responsibility, and Composite) will be very helpful for understanding the Commons components architecture and usage.

Validator

Commons Validator is the component Struts uses to validate forms in a Web application. This component is designed to validate any Java Bean, but you can use it to validate data (e.g., a domain layer object or user input to a Swing application, or XML-formatted data submitted to a Web service) as well.

In most projects I have seen, the validations are written in one of three ways:

  1. In domain objects
  2. In utility classes
  3. As custom frameworks

The first two approaches lead to bad design since developers tend to write their own copies of validation methods. The validation code gets scattered throughout the application even though its sole purpose is to log the error, throw an exception, or display it to the user. The other disadvantage is while raising error messages by reading from the resource bundle, the code written for this will be duplicated all over, though its purpose is the same for all validations.

As an example, I use Commons Validator to validate the user input to a Java Swing application. Figure 1 shows a snapshot of the GUI, which captures registration details from the user.

Click to enlarge
Figure 1. Snapshot of the Swing Application

Before getting into the details of the application's Commons Validator usage, let's look at some important classes to explain its design (Refer to the complete source code for a better understanding). The following classes are part of the package in.co.narayanan.commons.validator:

  • RegistrationScreen: A singleton class and the main frame, which contains other GUI components
  • Registration: A domain object that represents a user registration
  • Listeners: An adapter class for handling GUI events and delegating them to the appropriate commands
  • SubmitCommand: Uses Command pattern to represent a submit operation (The validation will be initiated from this class.)
  • RegistrationContext: Uses Mediator pattern to pass the necessary context information for the event listener and command classes
  • ValidatorEngine: Uses Commons Validator to validate the Registration bean and processes the result

The objective of this example is to validate the 'proposedLoginName' and 'mailAddress' values the user gives during registration. The Registration domain object gets populated with the values the user enters in the SubmitCommand.



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap