Open Source Form Validation Library FormProc 1.0 Released


News: Open Source Form Validation Library FormProc 1.0 Released

  1. FormProc 1.0 is an open source Java library designed to make handling and validating forms easy. Includes example WARs demonstrating server-side validation. Forms are represented as objects which manage a collection of form elements.

    FormProc version 1.0 is now available at

    Thank you to all who have contributed to FormProc.

    More info
    FormProc is an open source Java library designed to make handling and validating forms easy. Forms are represented as objects which manage a collection of form elements. Submitted data can be validated through several mechanisms including regular expressions, BSF supported scripting languages and custom Java classes.

    This release includes the following changes: Improved handling of null and empty values. Conversion skipped if value is null while the store mechanism will try to handle null values. Added optional flag to FormElement. Added ValidationResult.getValidator() method. Added originalData Map to FormResult. Added getOriginalValue() and getOriginalValueAsString() to FormResult. Added methods for getting messages for specific fields. Fixed NPE in IsIntRule. Fixed error on null in Fixed potential NPE in Form class. Added LongConverter implementation. Added missing JavaDoc comments. Removed ant libraries and build scripts. You must now have ant installed to build FormProc from source.

    For more information please visit You can also join the FormProc mailing list at
  2. Can u highlight the differences with jakarta/commons/validators ?
    Nice piece of code btw,
  3. I have not used the Jakarta Commons Validation library (hereafter known as JCV), but I did look over it briefly this morning in order to try to answer your question. Here are the major differences that I see:

     - According to the README in the JCV it is designed to work with Struts, although the proposal speaks of use in other systems (EJB for example). FormProc is not tied to any framework. It includes examples accessing it from both JSP pages and a Swing application.

     - JCV deals solely with validation. FormProc also provides type conversion and automatic object population both of which can be extended with custom logic.

     - JCV is five months old whereas FormProc has been in development for more than a year.

     - Both support internationalized error messages. FormProc's message system is extensible allowing for messages to be inline in the config, in ResourceBundles, or using any other custom mechanism.

    These are my observations from a quick glance at JCV. Apologies in advance if I have made any invalid observations.

    Anthony Eden
  4. I should take a look at this when I have a spare moment. Tapestry also includes a pretty sophisticated framework for performing validations and conversions for text fields, along with the ability to report errors and highlight fields that are in error.

    I would bet that you could easily build a bridge between Tapestry's validation and FormProc to leverage FormProc's wider set of validations, scripting, etc.
  5. It shouldn't be too hard to build the bridge.

    I have a module for integrating FormProc into JPublish as well as an initial implementation of a Turbine service. As I understand it some work has also been done on integrating FormProc into WebWork.

    Anthony Eden
  6. Anthony,

    did you have a chance to performance test your validation library? It seems there is a whole lot object instantiation, reflection, casts and xml tree traversing involved.

    I had something very similar implemented in my last project and had to cut back a lot on the above, which made the design suffer (me unhappy) and performance increase (manager happy).

  7. No, I have not evaluated the performance of it. If you or anyone else is interested in evaluating the performance of FormProc I would be happy to see the results.

    While developing FormProc I was concious about some potential performance bottlenecks. XML parsing only occurs once for each XML file and then kept in memory. Reflection only occurs using the ReflectionStorer (using a MapStorer for example requires no use of reflection).

    Personally I would almost always be willing to trade some performance hits for an improved design. In most cases I have seen the biggest performance bottlenecks are the network and database access anyhow. However, if someone does find any serious performance issues then please let me know and I will try to address them.

    Anthony Eden
  8. I downloaded this package and looked thru it with some interest. However I noticed, for instance, in the Rule interface, there's a method called configure:

    void configure(com.anthonyeden.lib.config.Configuration configuration)

    which has a dependency on Anthony Eden's personal library. So I go looking for javadocs to this library - there are none. Then I look for the source - that's not there either. No reference in the documentation to this com.anthonyeden.lib library's documentation. So I Googled for it and found it.

    I also noticed in AbstractRule (which implements the Rule interface) that the method is imelemented like so:

    public void configure(Configuration configuration) throws Exception{


    In fact that's all that's in the abstract class.

    So my question is, why put out a 1.0 release of a product that is dependent on a library for which you supply no documentation or sourcecode? (That's aside from the very questionable design decision here - you're really want to force users to implement that method? Yah I know there's an abstract class, but its value is bascially zilch.) (furthermore...throws Exception? geez). I looked around CVS and couldn't find any unit tests either.

    I think I'll stick to jakarta commons validator, thanks.
  9. First of all, EdenLib source code is available at The JavaDoc is there as well. If you look at the license for EdenLib you will also see references to the EdenLib site.

    Second, yes there is a dependency on EdenLib. Keep in mind though that this is the same as a dependency on other parts of Jakarta commons such as digester (which EdenLib config package is similar to), logging (which EdenLib log package is similar to), etc.

    Abstract implementations are provided to simplify development of concrete classes. Just because the abstract class only has one implementation at this point does not mean that it could not be modified in the future. Interface->Abstract Base Class->Implementation is a fairly common design.

    You are entitled to your opinion though, and if you would prefer to use the Jakarta Commons validator then so be it. I will take all of your comments into consideration though for future releases of FormProc.

    Anthony Eden
  10. "(furthermore...throws Exception? geez)." etc...

    Steve, this is not constructive critisism. Although you obviously have a point, the product's own mailing lists are more appropriate for this kind of comments.

    We want to encourage the development of free software, not ridiculise it. Can you point us to your own contributions of perfect software to the free software community?

  11. Aslak says:

    "Steve, this is not constructive critisism. Although you obviously have a point, the product's own mailing lists are more appropriate for this kind of comments. "

    I apologize if my comments didn't come across as constructive. I'd just point out that important parts of this api are meant to be implemented and extended, which means a higher impact to someone's codebase than, say, log4j. So seemingly "small" things like "throws Exception" absolutely are a big deal when you expect someone to implement an interface or extend a class.

    For example, what is the exceptional situation that you want clients of classes that implement this interface to recover from? Are clients supposed to use a series of if-instanceof statements on the exception to figure out what happened?

    My personal expectations of the quality of a 1.0 release of an open source product weren't met. There's a lot that's appealing in here - I think that the core functionality of the your validation process, and how the xml config files work is better than jakarta commons validator. However, you sort of only get one shot when writing an interface (there are examples of poorly designed interfaces in the java core api's that sun and all java programmers have just had to live with), and I don't think the the design has been well thought out (just my opinion). Other people may disagree, or may agree but think the core validation features outweigh the less-than-clean interface contracts.

    On a side note, Aslak's appeal to authority is ultimately counterproductive to your goal of writing a good api. By those standards you discount criticism from a large segment of software engineers who know what they're talking about but don't necessarily contribute to OSS projects in their free time. There's a lot of precedence for criticism like this on these forums. (And anyway, I'm guessing that Aslak votes, but has never run for office. Same thing.).

  12. Steve C just doesn't understand Opensource. Get with the program buddy.