iScreen is a Java Object Validation Framework, suitable for validating Java Objects (including JavaBeans) to ensure that they are "valid" according to some definition (usually via configuration). The term 'iScreen' means "information screen," where 'screen' means to protect or conceal. Information, represented by Java objects, are passed through the screen. If they are considered acceptable (i.e. valid), then nothing occurs. If not, then an exception is thrown, allowing the application to notify someone or something of the invalid information.

iScreen uses the Apache License Version 2.0.

10 November 2008 -- Release version 2.0.1 is available for download. This release includes some bug fixes for defects found in previous releases and hence is just a minor point release. Includes ability to use a ValidationService from multiple threads safely, some improvements on error checking for undefined references to validators/validation-sets. Includes some fixes/improvements to the DTD/XSD for the configuration file.

28 June 2008 -- Release version 2.0.0 is available for download. This new release makes some big changes to the API and configuration, hence the movement to a new major release number. New features include the addition of a conditional 'if' attribute on the use-validator, severity levels for failures, full trace from failure to validator and validation sets that caused it, and named messages associated with failure messages. Given the new severity levels, 'warnings' have been removed from the API (since warnings are defined as having a lower severity level, so the capability is still there). See the Javadoc for API changes (there were a number of changes), and the DTD for configuration changes (all additions).

11 April 2008 -- Release version 1.3.0 is available for download. This is a quick bug fix release with a small change to the ValidationFailure class. It now allows you to pull the trace of validation sets. For example, if a failure occurs within a set that is referenced from another set, etc., call the getServiceTrace() on the ValidationFailure class to find out which validation service reported the failure. Documentation should now be printable (changed the CSS), as a couple of other small fixes.

22 March 2008 -- Release version 1.2.0 is available for download. This new release adds some new features and fixes some defects. Support for meta data on validation sets has been added, which allows a different way of looking up a validation service (instead of a unique id, meta data can be used). In addition, a new validator for both OGNL and MVEL has been added that allows embedded OGNL or MVEL expressions to be used directly in validating an object. The DTD has been updated and fixed, as well as an issue finding a configuration file when using Axis2. Finally, the jars have been consolidated. This means that you only need two jars to use iScreen: OGNL and the iscreen-ognl.jar or MVEL and the iscreen-mvel.jar. Note that iScreen has been updated to use the latest versions (OGNL: 2.6.9 and MVEL: 1.2.24) of OGNL and MVEL (note that iScreen is compiled/tested against MVEL's JDK 1.5 version).

27 January 2007 -- Release version 1.1.0 is available for download. This release includes support for configuration documentation, as well as support for the MVFLEX Expression Language (MVEL). Additional features have been added, so check out the release notes on this release. This release can be downloaded at SourceForge.net.

24 August 2006 -- Release version 1.0.0 is available for download. This is the official, version 1 release! This release can be downloaded at SourceForge.net.

The main motivation for creating iScreen is the distinct lack of good open-source validation frameworks. The main "contender" is Apache Jakarta's commons-validator, which is useful, but lacks a number of important features (see The Importance Of Being Valid) which hobble it considerably.

The basic philosophy behind iScreen is to be as simple as possible (from a developer's perspective), yet flexible and powerful enough to handle fairly complex validations. The idea is to minimize the coding by maximizing the configuration (that doesn't mean requiring lots of configuration, but that if there's a choice between having something in configuration or in code, the choice will be in configuration).

Another important philosophical approach to iScreen is its independence. Though it's important to integrate with other frameworks (such as presentation frameworks or inversion of control containers), it's fundamentally important that iScreen remain independent enough that it does not get "locked" into working better with one framework over another.

Though validation frameworks are fairly simple and don't tend to be a high priority in Java development projects, it's still important to build sufficient capabilities that validation doesn't become a sore spot for developers (which they tend to be because of various issues). Though iScreen has many interesting initial features, there are many more to add. There is a lot of work to do in this area that is considerably neglected in current frameworks.

The following paragraphs define the current features of iScreen:

Java Object Validation

Validation is done via Java objects. Typically, these will be JavaBeans, but this is not required. OGNL (see www.ognl.org) is used to access object fields, which gives considerable flexibility in what is eventually validated.

Internationalization

Though currently somewhat weak (meaning, it needs a lot more work before it's done), basic internationalization support exists via resource bundles.

Multiple Fields

Fundamental support for pulling multiple fields from a Java object and validating them together is supported. The capability, unlike most validation frameworks, is not tacked on, but is supported as a natural configuration capability.

XML Configuration

Though the underlying engine supports configuration by other means, the primary configuration format is XML. In the future, additional formats will become available.

Configuration Reuse

The feature is tied to the XML configuration capability. This re-use allows validations to be referenced by other validations via delegation. This is interesting because it simplifies and minimizes the configuration.

Dynamic Failure Messages

Failure messages that are generated during validation are dynamically generated. Not only that, but each "validator" is configured with the message it will use (so, it's never hard-coded). These "validators" can also use multiple messages for different reasons (for example, imagine a validator that checks string lengths: it can use a different message for an invalid minimum length from the one it uses for maximum length).

Failures and Warnings

There are two types of errors that a validator can report: a failure and a warning. A warning is a failure that can be ignored (depending upon how the application wants to handle it).

Configuration-Based

Definitions of validations are done via configuration in order to minimize the required amount of code. In fact, the amount of code necessary is fairly minimal. It's recommended that an inversion of control container be used to further minimize the necessary code.

OGNL Access

OGNL (see www.ognl.org) is used for basic mapping and Java object access. This object navigation library is extremely powerful, providing considerable flexibility in what data is being validated and how messages are generated.

Though not available initially, the following are some interesting features that may be added at a later time:

Documentation

An Ant task can be run to generate human-readable documentation from the validation configuration. This can be extremely powerful, as it provides developers the ability to "read" the configuration without looking at it. It's also possible to publish this documentation as part of the production application, allowing the users to know what the validation rules are for a particular page or screen.

Direct Integration

For some frameworks (particularly web presentation frameworks), a more deep integration would go a long way to add the power of iScreen. When this work is eventually done, the priorities would probably be for Tapestry, Struts, Spring MVC, and JSF. Inversion of Control containers should be able to use iScreen without any deep integration, though they may require some configuration.

Scripting

At some point in the future, it would be good to be able to write validators in a scripting language (such as Python, Ruby, etc.). This would probably require a significant amount of work, so it's not a really high priority.

Interface-Specific Validators

One of the weaknesses of iScreen is that it is agnostic as far as user interfaces are concerned. For example, if using it for a web project, it doesn't support providing JavaScript for client-side validation. To a certain extent, this is on purpose, as it needs to remain independent. However, providing a method of tying in some form of integration of additional configuration that would allow for it would be a nice feature. However, since this isn't a core requirement, it's not a high priority.