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.

Why I ‘Admire’ & ‘Respect’ Google?

After penning down topics on ‘hard core’ technology, I am attempting to write something off-track.

Being a hard core Java/J2EE consultant & a strong supporter of open-source technologies, I try to keep myself updated with technology innovations that happen in & around the world. At the same time, consume these services as an end user and appreciate the technology, service offerings that benefits millions of people.

As people say, ‘Inventors’ make up something completely new from scratch but ‘Innovators’ introduce things as if they're new. When I think of ‘Innovation’, first thing that strikes my mind is ‘Google’. For sure, I am not the first to admire ‘Google’. Many people have written about it & experienced their products.

I am one of the million consumers who use Google products in day today life. I can’t imagine life without ‘Google Search’, consumed by millions of users on this earth.

I really admire Google products & their innovative ideas. I admire people at Google, who dare to think through & implement these ideas. Every concept or an idea from Google is ‘Classic’ & realization of an idea through high quality products is still worth flattering. I have seen very few companies who share & let millions of users consume services free of cost and Google is an exception.

I have personally experienced many Goggle products - Gmail, Google Maps, Picasa, Blogger, Google Talk to name a few and trust me, they are super cool & outstanding. One common observation among all these products is – quality & performance. These products are classic in nature & speedy in response.

Like many other, I admire and respect Google because of their outstanding, exceptional thinking & technological innovations.I Love Google.

Choosing Apt Web Layout Technology

Over the years, I have designed and implemented two popular web layout technologies – Struts Tiles and SiteMesh. In the beginning, I was very new to layout technology and had very little knowledge. Once my project architect asked me to use Struts Tiles for JSPs. I was wondering why to use such technology if everything can be done in a single JSP or separate the components of single JSP into bits & pieces and finally include it in main JSP page. After completing & supporting application for some time, it struck my mind “real benefits” using layout technology.

Every web application has common look and feel & has common content to be displayed such as header, footer, side menu, copyright footer etc and these pages appear in almost all functional pages. Layout technology makes managing & maintaining these common resources easier with minimum effort & less impact.

From my experience, I see lot of real benefits using layout technology.

Merits:
a) Separate content from layout
Layout allows you to decouple content from the structure. Layout deals with how content should be presented & content deals with ‘what gets displayed’. So, essentially we are NOT mixing functional pages with commonly included pages. This makes life easier during application maintenance because you know where to concentrate & isolate the problem.

b) Allows to structure or divide the page logically ( ex: header should come on top, footer on bottom etc)
Layout provides more control in designing how content should be displayed.
No doubt, logical division of components can be done using JSPs, but there is no central control or involves more time if modifications are to be done. Imagine, if you want to change the structure say move the copy right footer above general footer, then you end up making changes to all your JSPs which takes away your time.

c) Reuse the layouts across site
Once layouts are designed & coded, they can be reused across sites for functional JSPs.

d) Single or central place for modification
Instead of including JSPs, if we use layout and include pages dynamically , duplication in functional pages can be avoided. So, the catch is – if you include individual JSPs in your functional JSPs, it takes effort to modify & re-compile as you are touching many JSPs. Instead, if you have a single layout & include your JSPs , there is only one place where you can modify & changes are propagated across all functional JSPs within no time. Also, if you want to add any conditional statements around your included JSPs, it can be very well done in single layout rather than touching all JSPs.

BIG question? Which layout technology suits my application?

Well, from my experience Tiles is good but after working with SiteMesh, i see lot of plus points using SiteMesh over Tiles.

Tiles is an implementation of ‘composite’ pattern where is SiteMesh is a ‘decorator’ pattern implementation.

One issue with Tiles is - for each JSP forward, you need to configure ‘Path’ in struts.xml under action mapping & end up repeating ‘path’ for all JSP forwards even though your layout is same. For whatever reason, if you change the path name, you will have to change in all places. So, your JSP is tightly tied to path and all JSPs are tightly coupled to tiles layout. If you want to change the layout technology, you have significant changes in the configuration.

On the contrary, if you use SiteMesh, there is no JSP tie up with layout at least in struts.xml. You can create a single decorator & apply this decorator for a set of JSPs. If you want to use different decorator, just remove the JSP entry from decorator.xml and add it to other one. So, there is ‘loose coupling’ & switching to newer layout technology is much much easier.

Overall, maintenance of application is easier in SiteMesh than in tiles since SiteMesh has fewer configurations & not tied to any view technology. But, Tiles has some features such as decorating error pages like 404,500 etc which is not there in SiteMesh.

I have used SiteMesh. It’s Simple Yet Powerful !!!.

Struts2 Pain Points & Remedies

Recently, I worked on Struts2 based web application and discovered some pain points. Below are the pain points & remedies:

a) Performance:

Problem:
Struts2 comes with lot of goodies but at the same time slows down performance especially page response times. If you closely look at Struts2 architecture, there are many layers and that's why Struts2 is able to give lot of flexibility & control at all levels since there is ‘loose coupling’ across all layers including page rendering. Struts2 internally uses freemarker templates (.ftl) with OGNL EL for page rendering. Each web component such as textfield, label, form, checkbox etc have separate ftls grouped under ‘themes’ (Struts2 has themes – simple, xhtml (default), css html and Ajax)

While OGNL is more 'powerful' and 'robust' but consumes more processing time due to its inherent nature - Object traversal for indexed properties. While OGNL is very good where there are complex object structures such as table, Tree etc (where traversal is complicated), but for applications with simple properties, it turns out to be expensive.

Remedy:
i) If you have more text fields & labels on the form, better write a separate tag library similar to Struts1X and modify tag class in struts-tags.tld.
ii) Try to use freemarker template cache which caches page processing for a time interval specified in the freemarker.properties.
For other optimization techniques visit Struts2 site - http://struts.apache.org/2.x/docs/performance-tuning.html

b) Presentation Component Placing:

Problem:
In Struts2, if default theme – XHTML is used, you cannot put two text fields or any other components side by side or adjacent to each other. Reason is – Struts2 uses freemarker templates internally to render the components and these components have extra html table row - tr , which makes components appear on next line instead on same.
Remedy:
To solve this, you need to customize all freemarker templates ( text.ftl,form.ftl,label.ftl etc). You need have your own ‘theme’ and put all the customized templates under theme. Specify the customized theme in your struts.xml against ‘struts.ui.theme’ property.

c) Decorate Field & Action Error Messages:

Problem:
Struts2 has built-in field & action errors for displaying form validation & action validation errors.Howeever, doesn’t give more control over decorating (put your own border around message, put an error image etc) or customizing error messages through any of its tag libraries.
Remedy:
If you need to customize your error messages, you need to modify fielderror.ftl & actionerror.ftl templates. Add your own presentation or display logic. Of course, you need to know bit of freemarker syntax.

Why I 'Love' Spring?

Though Spring was born to provide light-weight container solution & alternative to EJB, it has made lot of things easier for managing object life cycle.I have worked around 4 years in Spring and belive me , it made lot of things simpler which otherwise would have been time consuming. Thus, Spring could potentially be a 'one-stop-shop' for building enterprise ready applications.

I "Love" Spring because of following reasons:

- Spring IOC & Factory : Spring can be used anywhere in the application - right from web tier to business tier to resource tier. Entire Life Cycle of an object can be managed through Spring IOC.It provides object factory to configure & inject dependent objects.

- Spring Context : Provides 'Service Locator' Pattern to look up EJBs & data sources through JNDI.

- Spring DAO : Provides out-of-the-box support for JDBC & DAO with transaction management.

- Spring ORM: Provides support for Hibernate,iBatis,JDO.

- Spring AOP : Provides AOP ( Aspect Oriented Programming) support. AOP reduces cross-cutting concern code that would otherwise be repeated throughout your code base.

- Spring MVC : Web framework for developing applications using different view technologies such as JSP,FreeMarker,PDF,Velocity etc.

- Spring Remoting : Support for distributed & remote application invocation.

- Spring Security : Support for Authentication & Authorization.

When to Choose Struts2?

Wondering when to choose Struts2.x over Struts1.x?. Here are the tips:
- Your application demands view technology changes such as from JSP to FreeMarker or Flex or PDF then Struts2 is way to go.

- Your application consumes heavy AJAX functionalities. Struts2 supports heavy AJAX tags.

- Your request needs to go through set of pre-defined , pre-processors before hitting an action class. Struts2 interceptors will do all the pre-processing for You!.

- You want your action classes to be executed in non-web containers. Your Action classes are POJOs & do not depend or tied to web containers.

- Easy form validation. Struts2 XWork Validation Framework makes it easy by tieing up action class with validation XML. One Validation XML per action class.

Apart from above mentioned , Struts2 offers features such as Easy unit testing , Reduced XML configurations , No 'Form' beans , out-of-box Spring , SiteMesh/Tiles support. By and large , Struts2 aims at making web development easier & maintenable.

I recently worked on Struts2 based web application, and believe me, Struts2 is awesome.