Page Comparison

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.

Don't duplicate domain objects in ActionBeans

...

Previous experience with other frameworks may have led you to dislike pre-actions due to the amount of work involved constructing them. In Stripes it's actually pretty trivial! In most cases there will need to be an ActionBean to process events (form submission) from a page, in which case it's as simple as adding a one line method to that class which forwards to the page. If the page is read-only it is a little more work (requiring it's own ActionBean) but is still pretty minimal:

public class MyPreAction extends MyBaseActionBean { 
    public Resolution view() {
        return new ForwardResolution("/my/view_only_page.jsp");
    } 
} 

Give the low cost of implementing pre-actions and all the benefits it brings we think it's really worth it!

...

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:

 
public UserProfile getUserProfile() { 
    return (UserProfile) getRequest().getSession().getAttribute("user_profile"); 
} 

public void setUserProfile(UserProfile userProfile) { 
    getRequest().getSession().setAttribute("user_profile", userProfile); 
} 

...

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:

 
@Before(stages = LifecycleStage.BindingAndValidation) 
public void rehydrate() { 
    this.domainObject = getHibernateSession().load(DomainObject.class, context.getRequest().getParameter("id")); 
} 

...