The Sapia Open Source Organization has released Vlad, a flexible, dynamic, extendable, powerful validation engine implemented in Java. Vlad stands for "validation". This projects indeed aims at offering a simple, high-level, extensible, generic validation framework that can easily be integrated into existing applications.

Also released: Confix, which translates XML configuration files straight to objects - no more "manual" XML processing!

We are devoted to provide quality software to the community - and guess what: we have GOOD DOCUMENTATION

Visit us at http://www.sapia-oss.org

Its true, I will start using it in a project tomorrow. Very easy, thanks.

Could someone who is familiar with Vlad and the commons validator compare and contrast the two. What does one offer that the other does not? etc???

tx

Matt

I would not like to speak for the Validator people, but I think that Vlad is much less programmatic in terms of rule implementation/usage. You already have rule implementations built in that you only need to configure in XML (a bit like you use Ant's built-in tasks). The programming effort occurs at two places: a) when you want to implement your own rules (like you would implement your own custom Ant tasks); b) to glue your validation to your Java app - which is unavoidable. And, well, the doc...

I have check the website, and what I care now is the performance of this engine, did anyone used this engine?

We haven't done any benchmarks - so, you tell me ;-). Yet, as with everything we do, performance mattered less to us then a clean design, and extended usability. We use the BeanUtils library from Jakarta, for example, which uses Java reflection to map attributes to methods; this way, validation rules can work against any object that respect BeanUtils' method naming conventions. As far as performance goes, BeanUtils is the only reason why Vlad would perform less than otherwise, if you know what I mean... Yet, the code is stateless (no thread synchronization), and we worked with care. So we would tend to think that, yeah, it performs well. I guess that performance will, in the end, be more affected by the number of rules that are applied for a given validation.

I like the approach of hierarchical validation, and the separation of interface from implementation. I've been looking for an open source validation framework for years, I don't know why validation isn't a part of J2SE. I've written a couple of validation frameworks myself for projects, but I'd rather use something off the shelf. Some suggestions, in no particular order:
o Support data types and maximum/minimum values for different data types, including int, double, float, BigDecimal, BigInteger, long etc.
o Provide data type to display conversion as well as validation, the two tend to go together.
o Take a look at the validation interface in JavaServer Faces, consider positioning Vlad as a possible implementation, UI independent, for validation and conversion. See the validation and conversion interfaces. I would like to be able
to use the same validation, server side in EJB or POJO, without including JSF classes.
o Consider extending plugability using interfaces, implemenations and factory classes, to the Rules Source, so that the rules could be sourced from a database, for example.
o Incidentally the commons validation doesn't seem to provide much separation of interface and implementation, I feel this is important for a validation framework.
o I've never made up my mind as to whether it is better to use exceptions or messagess for validation; I like the ability to use both. I lean towards using exceptions as a cleaner approach, as a validation failure is logically an exception. Exceptions can carry information about the source of the problem, can be localised, can have properties, and can't be ignored. I know there is a potential performance problem, but I haven't done any benchmarking on this.

Regards

Andrew Harris

...I forgot to mention:

o A scripting facility would be useful, together with regular expressions, for writing rules such as masking, credit card validation, account numbers. Also for creation of complex rules in terms of primitives. Scripts could be embedded in the rules definition in place of a class name. Scripting language should provide simple access to bean properties, as in the JSP scripting language perhaps.

o Plugin support for rule editing well known IDEs: JBuilder, Eclipse, whatever. JBuilder has been demonstrated recently with JSF, I don't know how it handles mapping of validation to form fields, but it would be useful to have common support for this area across IDEs, perhaps.

o Use with Swing UIs, work with JFormattedTextField etc., provide common support for validation on form fields in IDEs for construction of Swing UIs. [Why didn't Sun provide a Swing independent validation then use it in Swing?]

Andrew

Andrew

Thanks for your suggestions! Implementing them will be a full time job ;-) I have a few work-around/suggestions of mine that could fullfill some of the goals you have suggested:

>> ...so that the rules could be sourced from a database, for example.

Well, if you look at the Vlad class - see the javadoc, you can see it has a load method that takes an InputStream as an argument; thus, you could have rule
definition files basically anywhere - including in a database BLOB - or CLOB.

>> Support data types and maximum/minimum values for different data types, including int, double, float, BigDecimal, BigInteger, long etc.

You can easily add rules to the current base by simply implementing your own rule classes (in the same way as you would implement your Ant tasks to fullfill specific needs). We encourage people like you to share their ideas (in the form of code, if possible ;-) so that we can post it on the site, and make the rules available to all. In fact, this is one of the stated goals of the project, and is indeed why we introduced XML namespaces in the rule definitions - see the Vlad site for more on this.

>>A scripting facility would be useful

Indeed, I am a fan of Jython myself. This is definitely on the TODO list...

Thanks again for your interest.