Shifting from ‘Form’ to ‘Action’ based Validation Approach – Pros & Cons

Most of the web frameworks such as Struts1x & Struts2x provide out-of-the-box implementation for ‘form‘ validations. There are two ways to implement validations.

a) Manual Validation: This involves overriding validate() method on form bean or an action class, coding for all validation rules & adding error messages programmatically.

b) File Based Validation: In this approach, validation rules are externalized to XML files & are configured for a form bean or domain object or value object (any POJOs). Even error message keys can be picked from resource bundle & configured in xml. Since it’s a configuration based, provides more control & better manageability over manual validation.

Let’s deep dive into file based validation approach and analyze its merits & de-merits.

In Struts1x, validation revolves around ActionForm beans where form bean is configured in a validation xml (validation.xml) & all validation rules are configured for form attributes.

Pros:

a) Central validation xml. No hard coding in java code; everything can be configured.
b) Form bean validation rules can be re-used across different modules. For example: if form bean with standard set of validation rules is used in create flow, it can be reused in modify flow as well (to re-use the same form across flows, use ‘page’ concept)
c) Single Java class with multiple methods can act as custom validator class.
d) Maintenance of form & validation xml is easier.

Cons:

a) Maintaining ‘state’ of form bean is bit tricky since same form used across different modules can cause session data corruption. Utmost care should be taken to clean up or update the session form values. If same form is not used, then separate forms have to be kept in session or any other scope in order to achieve desired functionality.
b) Form beans are tied to particular validation framework ie, each form bean should extend ActionForm or ValidatorForm (if commons validation framework used) class in order to fire validation rules. Form beans in isolation cannot be re-used.

Let’s look at validation approach adopted in Striuts2x.Struts2x uses XWORK Validation framework. Here validation is action based and not form based i.e., each action class has validation xml (Action-validation.xml).

Pros:

a) Modular page design i.e., one action class per page & one action-validation per page.
b) No from beans. Any POJO (domain object or value object) can act as form to capture form input values.
c) Action class or separate POJO that captures input values is not tied to any web container or validation framework. Therefore, they can be reused without any second thought.
d) Reusability of custom validators.
e) Supports validation chaining.

Cons:

a) Many validation configuration files. One per action class.
b) Cannot have single custom validator class with multiple methods.
c) By default, all action classes are ‘prototype’ scoped but if separate domain object is used to capture form input values & is reference from an action class, then maintaining of ‘state’ becomes tricky.

I have worked on both Struts1x & Struts2x & here is my final take.

- Struts1x commons-validation framework is very well matured & has lot of in-built validators & information available through community site, discussion forums & discussion threads. On the contrary, Struts2x validation framework has not matured enough & has very few built-in validators. Very little information is available through different input sources. But, one can meet desired validation requirements through trial & error, own learning’s.

- Struts1x is tied to web container & validation framework. On the other side, Struts2 validation framework is not tied any container. Action classes, domain objects can be re-used in isolation.

My Suggestion:

Both Struts1x, Struts2x has pros & cons and is up to enterprise architects to decide which one suits the BEST. But, I would recommend you to use Struts2x since it offers lot of features over Struts1x such as plugging-in different view technologies other than JSP, heavy AJAX tag support, POJO based action class, in-built spring, sitemesh, tiles support, interceptor concept, reduced configuration etc.

Like any other web frameworks, Struts2x doesn’t provide more options/features/control in terms of form validation compared to Struts1x in my opinion but this can be resolved through proper design of validators or by writing custom validators. If one is getting elephant minus tail, I would say, still it’s a good deal. So, embrace Struts2x without second thought & move away from ‘form’ based to ‘action’ based validation approach.