Action2 Apps Best Practices

* Link only to actions, never to server pages or templates

* Do not expose the action extension in your tags. Use the action parameter instead.

* Use namespaces to organize your application into logical "modules" or units of work.

* Place each namespace into it's own Xwork config.
 ** Try to keep the Actions classes for the namespace in a common package.
 ** Store the Xwork configuration for that namespace with the Actions.
 ** If you are using JSPs, try to name the JSP folder after the Action package.
 ** If you using templates, bundle the templates with the Actions.
 ** Remember, if the namespace needs to change, you do not need to change packages or JSP folders, if you don't want to.

* Within a namespace, reuse names for common concepts. If each namespace has an entry page, use the same action name in each namespace. For example, each namespace in the Cookbook has an "Open" action.

* Unit test actions before trying them in a web application.
  ** Since JUnit is integrated in most IDEs now, there is no excuse.

* Consider using WebCanoo, HtmlUnit, or HttpUnit to test navigation, as the application is being developed.

* Use SiteMesh, or the equivalent, to separate application "chrome" from the core utility of the server pages.

* Specify the POST method for forms, unless there is a reason to use the default GET method.

* If an image, or other swatch of markup, is being used by multiple pages, remove it to its own server page and include it where necessary.
 ** Better yet, encapsulate the markup in its own UI tag.

* Extend the UI tags as needed.

* Consider using the message resources for page titles, control labels, and so forth, even if the application is not being localized.
 ** It is often useful to seperate the concern of what message to display from the concern of where to display it.

* Use the XML framework to validate input.

* Do not embed business logic in action classes.
 ** Remove business logic to a business facade that the actions can call. (Spring is an excellent way to build a business facade.)
 ** Actions are a necessary evil. Every line of code in an Action is guilty until proven innocent. Ideally, there should be one line of code that calls the business facade, and every other line of a code in an action should be bound to the framework.

* Centralize other application and business logic into a base class that action can share. 


----

Other Best Practice Resources 

* Showcase Best Practices thread - http://forums.opensymphony.com/thread.jspa?messageID=24691&#24691

* Original "Action 1" Catalog - http://husted.com/struts/catalog.html

* Wiki version - http://wiki.apache.org/struts/StrutsCatalog

* "Action 1" Best Practices - http://opensource.atlassian.com/confluence/oss/pages/viewpageattachments.action?pageId=829