Download latest release

Download latest Struts examples using Integradata

Online Demo *NEW*

Integradata is a small, simple, portable, rules-based, declarative data validation system written in Java.

So what? There are many other packages that say they do as much or more than Integradata. The Jakarta's Commons Validator, for one, which is integrated into Struts. Another might be FormProc. Both are fine, but the authors of Integradata have more than a few bones to pick with them that we feel have been accomplished at least in part by Integradata. These are as follows (in no particular order):

• Other validation systems end up trying to do too much and their language becomes overly complex and baroque. You wanna mantain that? Integradata's langauge API is so small we can tell you in a few words what it is: For any bean, for any accessor on that bean, these rules must pass for the bean to be considered valid. Let's prove that right now:

  <integradata>
 <bean beanClass="com.acme.SomeBean">
  <field label="fieldName">
   <rule ruleClass="com.acme.SomeRule">
    <param name="someName" value="someValue"/>
    <!-- Optional, other parameters for rule may be added -->
   </rule>
   <!-- other rules may be added -->
  </field>
  <!-- other fields may be added -->
 </bean>
 <!-- other beans may be added -->
</integradata>


  That's it.

  There are plans to generate this file directly from your Java Beans source using XDoclet in the next release.

• Other validation systems are tightly coupled with whatever system they were born with. That's fine if you don't care about porting your business rules from one system to another when the time comes. On the other hand, Integradata was born to work with the Web while simultaniously provide the same business logic rules to a proprietary wireless handheld development framework. Hence it has no coupling to anything other than a subset of the Java Beans API.
• Other validation systems define a class whose methods provide validation logic. Integradata uses the Command Pattern to define one configuable business rule per class. You get the simplicity of encapsulation and promotion of reuse. This, in turn cleanly separates the declaration of versus execution of business rules with a consistent, rigorous API, instead of a free-form API that requires complex meta-data. These other systems make the decaration and definition of the rules feel very much like yet another execution language. Clearly they have gone too far.