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:

• Web Framework Validation Framework: Most (if not all) web frameworks have their own validation framework. Some are fairly poor (like Struts') and some are more elaborate (like Tapestry's). However, they are all tied to their respective frameworks. This, and the general lack of features, are their primary weaknesses. Their main strength over iScreen, other than being integrated into the framework, is the fact that they serve a dual purpose of server-side and client-side validation (iScreen currently only supports server-side validation).
• Apache Jakarta's commons-validator: Initially tied to Struts, this validation framework, though making progress, lacks many features and capabilities. Unfortunately, given its legacy, it will take considerable work to get it to where it needs to be (that is, having as many features and capabilites that iScreen has).
• Annotations: With the addition of annotations to JDK 1.5, it seems lots of people are trying to find a problem to apply them to. One of those is validation. Though it seems to make sense on a cursory view, once you look closer, you notice some fairly glaring holes, such as: lack of good multi-field support, issues with error message generation, validation reuse, etc.
• Rules Engine: Certainly, a rules engine approach will get the job done. However, a rules engine is about making decisions, not about validating data, so it's not optimized for the kind of work a validation framework would be. A rules engine can do the job, but it's overkill, and will require a considerable amount of work to "make it easy" to do validations, since it's not built to handle error message generation, reuse, etc. the way a good validation framework should (meaning, you'd have to build some infrastructure to the engine to get it to work the way it should). Also, a rules engine is a code-approach and is more difficult to configure (without having to write that infrastructure yourself).
• AOP: This is less a validation framework and more a way to get existing validation to where it needs to be. Hence, it can be used along side an existing framework (like iScreen) to enhance it, rather than replace it (it doesn't provide configuration, error message generation, reuse, etc.).

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).