While Stripes was designed to provide the flexibility often needed in complex situations, it was also developed to make a number of things extremely easy. This document describes some of the best practices that fit in with the model the author intended for Stripes applications.
Stripes' binding and validation system was designed from the ground up to make it easy to work with existing domain/value/JavaBean objects because you shouldn't have to duplicate properties from your domain objects in to a presentation specific class just to get things done. Stripes will happily set nested properties within your existing domain objects, many levels deep, and instantiate objects along the way as necessary. So, just embed your domain objects (or Lists, Arrays of Maps of them) in your ActionBean and provide a simple getter/setter pair for the object (or List or Array or Map).
Many presentations frameworks encourage pre-actions as the means to populate the data for a page. This leads to all sorts of complications when you want to do something else, then render a page that needs it's own pre-action. Stripes implements a simple view-helper pattern which allows an ActionBean to be reused as the view helper. The standard flow would be to either navigate directly to the page, or when another action is called first, return a RedirectResolution to the page. The <stripes:useActionBean ... /> tag will then instantiate the ActionBean, perform binding and optionally run a handler method to prepare data for the page. In cases where the ActionBean is already present, the useActionBean tag will not create a duplicate, but simply re-use the already present bean.
One area where projects often get into trouble, or have unwieldy code, is in accessing attributes store in HttpSession. One goal of Stripes is to ensure that ActionBeans remain independent of the Http* classes, so that they can be easily unit tested. By subclassing ActionBeanContext and configuring Stripes to use your subclass you can provide type safe centralized access to session. And since all access is in one class, it's easy to swap out the implementation with a mock implementation for unit testing. Your class might contain methods like:
When creating screens to edit existing persistent objects it's nice to be able to avoid copying all the properties from the nested domain object to the persistent one that you just looked up from the database. If you pre-populate the object from the database, Stripes will just bind the values from the request like normal, leaving you with an updated object ready to save. Such an implementation might look like:
While Sitemesh is great for applying sitewide decorators and such, sometimes you just want a simpler solution. The layout tags allow you to define simple re-usable layouts using JSPs and then use them to drive the layout of your sites pages. By centralizing your layouts (instead of say, including the header and footer on each page) you make it much easier to change your layout later, perhaps from a standard c-clamp layout to something a little different. And since it's all done with JSP and a couple of custom tags, there's no external configuration or new syntax to learn. See the Tag Library Documentation for more information.
Most classes in Stripes log information that is very useful in figuring out what is going wrong when you are having problems. Stripes logs a lot of information at the DEBUG and TRACE levels, and quite sparse information at INFO and below. In development it is recommended that you either always have Stripes logging at DEBUG level, or be able to switch this on easily. In most logging implementations this can be done by configuring loggers under net.sourceforge.stripes to output at DEBUG level.
However, it should be noted that leaving logging turned up seriously impacts performance! For example, reducing the logging level from DEBUG to INFO on the Bugzooky example app cuts processing time in five in some cases! For this reason you should probably set the log level at INFO or WARNING for production usage.