S2 Tip – Define base class constants for common Result names

The framework defines several constants that are used to identify common result use cases, such as, ERROR, INPUT, FAILURE, LOGIN. NONE, and SUCCESS.

When an application has common result cases of its own, such HELP, MENU, or CANCEL, the application should define additional constants to represent various result types.

The use of constants reduces programming errors, increases cohesion, and also documents an application’s common result types.

S2 Tip – Use global result handlers for common results

Often, actions will share a number of common results. Rather than configure redundant result elements for each action, share common results through a global result handlers.

/common/Error.jsp

/common/Error.jsp

Login_input

Using global result handlers ensures that common results will be
handled consistently, while reducing redundant code. Global results
increase coupling, but any action that needs to handle a result
differently can provide a local handler.

S2 Tip – If you are using JSPs, try to name the JSP folder after the namespace or Java package

Unlike template systems like FreeMarker and Velocity, JavaServer Pages cannot be served from a JAR or loaded from the classpath. The next best thing is to name the JSP folder after the namespace or Java package for the corresponding Action class.

By creating correlations between the pages and the Actions through a shared set of naming conventions, we increase cohesion within the application. If wildcards are used, consistent, shared naming conventions can reduce the number action elements an application needs.

S2 Tip – Use Exception handlers

Since Action classes tend to access the same business layer, most Actions often need to catch the same set of exceptions. Rather than sprinkle Actions with nearly identical try..catch blocks, configure an Exception handler to catch whatever exceptions an Action may throw.

<struts>

<global-results>

    <result name="error">/Error.jsp</result>

  </global-results>  <global-exception-mappings>

    <exception-mapping

      result="error"

      exception="java.lang.Throwable"/>

  </global-exception-mappings>

  <!-- ... -->

</struts>

Exception handlers can be either global or local to an action mapping.

<struts>

  <action name="Login"  class="actions.Login">

    <!-- ... -->

    <result name="expired" type="chain">

      ChangePassword

    </result>

    <exception-mapping

      exception="dao.ExpiredPasswordException"

      result="expired"/>

  </action>

  <!-- ... -->

</struts>

Use of exception handlers separates concerns and reduces redundant code. Each Action has fewer lines of code to maintain, and we know that exceptions are being handled consistently.

S2 Tip – If you are using templates, bundle the templates with the Actions.

Unlike Java Server Pages, FreeMarker and Velocity templates can be served from a JAR or loaded from the classpath. Rather than store Actions and templates in separate parts of the file system, consider maintaining both in the same Java package.

By storing together interelated members, we spend less time navigating the file system, and we also increase cohesion within the application.

S2 Tip – Maintain configuration files in a resource folder or Java package

The default struts.xml file is loaded from the root of the classpath. In a web application, the WEB-INF/classes folder is loaded to the root of the classpath.

To avoid maintaining files directly under WEB-INF, create a resource folder that can be copied to WEB-INF/classes when the appliication is compiled. If subfolders are also copied, then the resource folder can mirror the Java package system. The Struts Showcase application uses this common approach.

+ java

  + receivables

    - Deposit.java

    - Menu.java

  + payables

    - Menu.java

+ resources

  - payables.xml

  - receivables.xml

  - struts.xml

  + payables

    - Menu.properties

  + receivables

    - Menu.properties

+ webapp

  + payables

  + receivables

    - Deposit-error.jsp

    - Deposit-input.jsp

  + WEB-INF

Alternatively, maintain the configuration files alongside the Java packages, and have the build system copy resource files from the Java source root. The Struts Mailreader uses this alternative approach.

+ java

+ receivables

- struts.xml

- Deposit.java

- Menu.java

- Menu.properties

+ payables

- struts.xml

- Menu.java

- Menu.properties

- struts.xml

+ webapp

+ receivables

- Deposit-error.jsp

- Deposit-input.jsp

+ payables

+ WEB-INF

If FreeMarker templates are used in lieu of JSPs, then all the resources for a namespace can be kept in a single folder.

+ java

+ receivables

- struts.xml

- Deposit.java

- Deposit-input.ftl

- Deposit-error.ftl

- Menu.java

- Menu.properties

+ payables

- struts.xml

- Menu.java

- Menu.properties

- struts.xml

S2 Tips – Try to keep the Action classes for the namespace in a common Java package

As part of the Struts 2 from Square One project, I’ve been reducing the Struts 2 tips to a manuscript. One Struts Tip a week isn’t keeping up with the manuscript, so I’ll be running two a day for the rest of the week.

An element of Java style is to place types that are common used together into the same package. If namespaces are being used to organize an application, then the Actions within a namespace should be found in the same Java package.

But, wait there’s more …

This site is being used a part of my April “Tour de Blog“.

Visit JRoller for the complete Macaroni archive.