Guidelines for Struts2 projects – part 1

May 14th, 2008 · Peter Paul Bakker · java, Software No comments - Tags: , , ,

Struts2 is a very flexible framework. And with so much flexibility, consistency may be at stake.

Lot’s of freedom brings rules to adhere to. As a team.

Here are some of the rules that I found after some team meetings on how to work with Struts2. As the application architect, some guidelines needed to be put on paper.

Rule: do not use interceptors for business related code and logic; interceptors are the Framework

It is very tempting to create lots of interceptors that will gather all kinds of almost always needed data. For instance to always pull the main object for you application from the database and insert it into the current Action. This results in Actions being dependent on a certain interceptor stack, otherwise it is missing business information. This information can be very specific to (one part of) the application. And if more interceptors are needed to process business information, your action cannot considered to be one coherent component.

So consider Interceptors being the Web Framework. In Struts 1 you would know the exact sequence of calls to the Forms and Actions ( validate, execute, …). In Struts2 this sequence can be tweaked by simply changing the interceptor stack. All developers should have a clear view on what the framework is, and not be dependent on specific interceptor stacks to have their Actions work correctly.

Not following this rule will make

  • Action code harder to read and understand, because there are hidden dependencies
  • testing more difficult, because you need the interceptor stack for testing your Action
  • struts2 configuration more complex, because you will probably end up with many different interceptor stacks

    • Think of it this way: interceptors should only deal with infrastructural concerns, such as logging, calling lifecycle methods on the Actions, transforming values from web pages to actions, security, and others. So if you write an interceptor, check if the interceptor can also be used in other applications, and have no dependencies on the business model of the application you are working on.

    Also watch for having too many parameters on interceptors. Sometimes business logic can creep into an interceptor this way. You will notice that for some actions you will need to set a param of the interceptor to false to exclude some logic from running in that particular interceptor stack. Maybe you are better of to include the logic explicitly in the Action, or in some component that the Action can delegate to. This will make the logic in your Action explicit and better to understand.

    More guidelines will follow…