The Java Object Validation Framework
Download (SourceForge Hosted)
Frequently Asked Questions
What is iScreen?
iScreen is a Java object validation framework (that is, it validates POJOs). iScreen means "information screen" where the "information" is contained within a Java object (or POJO: Plain Old Java Object). The "screen" aspect is to validate that the information is acceptable (for whatever that means). If not, an exception is thrown, effectively "screening" the flow of information from going forward (the caller must catch the exception and do something about it).
Why does iScreen use OGNL?
OGNL (www.ognl.org) stands for Object-Graph Navigation Language, which means that it is a pseudo language that allows you to access properties, call methods, and navigate an object graph to get to the information you need. It's much more powerful than using a simple properties getter/setter, like Apache Jakarta's commons-beanutils. It's fairly easy to use (when doing simple stuff), but can get hairy if you're doing some fairly complex stuff (but, at least you can do them!).
iScreen needed some way to set properties, map properties from one object to another, etc. OGNL seemed an excellent choice for that requirement.
iScreen also uses MVEL (meaning, use one or the other, but not both at the same time). MVEL is similar to OGNL, with some advantages in what it can do and how fast it can execute.
Why not use Apache Jakarta's commons-validator, or a rules engine, or annotations, or the validation framework of the web framework, or...?
There are many ways of approaching Java object validation, the most popular being the validation framework that's part of the web framework that you're using (all of them seem to have their own). Why iScreen? Because it's a better framework, providing more features, more flexibility, more power, and fewer dependencies on libraries or frameworks.
Let's look at the major problems of each of the more common validation approaches:
Why are Validators stateless? Doesn't that just make writing them harder?
There are a few reasons for this, and yes, it does create some additional complexity that makes writing Validators harder.
Ultimately, a Validator must access the fields that it needs to validate. One way to approach this is to make the Validator stateful and execute setters on the Validator directly. In this case, a new instance of the Validator must be created (otherwise, you have to worry about "un"-setting things, and that's a little tricky). It must be configured with constraints, services, and failure messages. It gets thrown away after validating. The other approach is to make the Validator stateless and pass in the fields that need to be validated. However, you don't want to force the Validator to access the fields via reflection (that's more work), so, instead, the Validator defines the object (typically a JavaBean) that will have the fields mapped to it (and the mapping is done in configuration). The Validator need only be created once (though the mapping object is created each time) and configured with constraints, services, and failure messages once.
iScreen went with the stateless approach, as it should be a little faster during execution (though probably not significantly). The stateless approach also means that the mapping beans (created by the Validator) can be reused (that is, the class definition can be reused).
Why is there so much configuration?
Imagine a continuum where on one side, all validation is done via code. The other side is where the validation is done via configuration. The approach iScreen took was to be as far along on the continuum toward the configuration as possible (and appropriate). If you have a framework that sits somewhere in the middle, you have to deal with a lot of code and a lot of configuration. Moving to one side of the continuum or the other would simplify the use of the framework since there's less "duplicity" in what the developer has to deal with.
iScreen chose the configuration extreme to minimize the impact on the code necessary to use the framework. Part of the reason for this is to allow different types of configurations to be used (right now, only a specific XML schema is used) with the same code/API. For example, the design of iScreen would allow it to use other file formats, such as Java property files, or Spring configuration, etc. It would require writing a parser or code to extract the configuration and construct the internals appropriately (thankfully, as a user of the framework, you don't need to worry about those details).