Codebehind Plugin

The Codebehind plugin brings elements of the "Page Controller" design to Struts 2 for the purposes of reducing the amount of mundane configuration through conventions. There are two common situations for configuration that could be improved:

1. Pages with no Action - These are cases where the page is mostly static and doesn't require an Action class to execute logic. Common examples are index pages and those that heavily use JSP tags or JSF components.
2. Default results - The purpose of most Actions is to execute code to prepare the data for a specific page. The name of this page is usually the same as the Action itself.

To improve the first case, the Codebehind plugin will detect the presence of a page with no corresponding Struts Action and automatically substitute the ActionSupport class, which is basically a NO-OP Action. For the problem of default results, the Codebehind plugin will make it unnecessary to define those results by detecting the presense of a page for that Action and creating the appropriate configuration on-the-fly. In these ways, the Codebehind plugin allows you to follow a page-based development style, handing the linking of Struts Actions and pages or Results in a common way.

Pages with no Action

To better facilite a code-behind development approach, the Codebehind plugin will detect the case where the request has no defined Struts Action, yet there exists a page available. It will then create a dummy ActionSupport instance to substitute for the missing Action class, allowing the page to be displayed normally. Additionally, the default interceptor stack for the configured package will be applied, allowing
you to bring the workflow benefits of interceptor stacks to simple pages.

When no explicitly configured Action can be found for a request, the Codebehind Plugin searches the web application for a possible page. Specifically, the following pattern is used to locate a page:

/NAMESPACE/ACTION.(jsp|vm|ftl)

For example, if the request is for http://www.company.com/myapp/member/login.action, the Codebehind Plugin will look for the following pages, in this order:

1. /member/login.jsp
2. /member/login.vm
3. /member/login.ftl

If any of those pages are found, the plugin will construct an ActionConfig object on the fly, using the ActionSupport class for the Action and a single Result that points to the discovered page. The ActionConfig will be put in the configured package, meaning that it will inherit the default Interceptor stack for that package. The default package is codebehind-default, however, it can be configured in any configuration file (see Constant Element) via the struts.codebehind.defaultPackage constant.

Default Results

Eighty-percent of Results will be ones with the same name as the Action itself. To reduce this unnecessary configuration, the Struts plugin will try to guess the appropriate Result, if none is explicitly configured. This technique works for any result code, including success. When combined with the Zero Configuration style, the amount of configuration in your application goes to next to nothing.

When no explicitly configured Result is found for an Action and its returned result code, the Codebehind Plugin, again, searches the web application for a possible page. Specifically, the following patterns, in the following order, are used to locate a page:

1. /NAMESPACE/ACTION-RESULT_CODE.(jsp|vm|ftl)
2. /NAMESPACE/ACTION.(jsp|vm|ftl)

These two patterns are searched for each of the three possible page extensions: jsp, vm, and ftl. For example, if the request is for http://www.company.com/myapp/member/login.action, so that the action name is login and the namespace is member, and the Action returned a code of success, the Codebehind Plugin will look for the following pages, in this order:

1. /member/login-success.jsp
2. /member/login.jsp
3. /member/login-success.vm
4. /member/login.vm
5. /member/login-success.ftl
6. /member/login.ftl

If any of those pages are found, the appropriate Result will be constructed and processed.