Apache Tapestry - Storage

Advertisements

Previous Page
Next Page  

Every web application should have some way to store certain user data like user object, user preferences, etc. For example, in a shopping cart application, the user's selected items / products should be saved in a temporary bucket (cart) until the user prefers to buy the products. We can save the items in a database, but it will be too expensive since all users are not going to buy the selected items. So, we need a temporary arrangement to store / persist the items. Apache Tapestry Provides two ways to persist the data and they are −

  • Persistence page data
  • Session Storage

Both has its own advantages and limitations. We will check it in the following sections.

Persistence Page Data

The Persistence Page Data is a simple concept to persist data in a single page between requests and it is also called as Page Level Persistence. It can be done using the @Persist annotation.

@Persist 
public int age;

Once a field is annotated with @Persist, the field's value will be persisted across request and if the value is changed during request, it will be reflected when it is accessed next time. Apache Tapestry provides five types of strategy to implement the @Persist concept. They are as follows −

  • Session Strategy − The data is persisted using the Session and it is a default strategy.

  • Flash Strategy − The data is persisted using Session as well, but it is a very short lived one. The data will be available in only one subsequent request.

@Persist(PersistenceConstants.FLASH) 
private int age;

  • Client Strategy − The data is persisted in the client side such as URL query string, hidden field in the form, etc.

@Persist(PersistenceConstants.FLASH) 
private int age;

  • Hibernate Entity Strategy − The data is persisted using the Hibernate module as Entity. The entity will be stored in Hibernate and its reference (Java class name and its primary key) will be saved as token in HttpSession. The entity will be restored by using the token available in HttpSession.

@Persist(HibernatePersistenceConstants.ENTITY) 
private Category category;

  • JPA Entity Strategy − The data is persisted using a JPA module. It will only able to store Entity.

@Persist(JpaPersistenceConstants.ENTITY) 
private User user;

Session Storage

Session storage is an advanced concept used to store data which needs to be available across pages like data in multiple page wizard, logged in user details, etc. The Session Storage provides two options, one to store complex object and another to store simple values

  • Session Store Object − Used to store complex object.

  • Session Attributes − Used to store simple values.

Session Store Object (SSO)

An SSO can be created using @SessionStore annotation. The SSO will store the object using type of the object. For example, the Cart Object will be stored using a Cart class name as token. So, any complex object can be stored once in an application (one per user).

public class MySSOPage { 
   @SessionState 
   private ShoppingCart cart; 
}

An SSO is a specialized store and should be used to store only complex / special object. Simple data types can also be stored using an SSO, but storing simple data types like String makes it only store one “String” value in the application. Using a single “String” value in the application is simply not possible. You can use simple data types as Apache Tapestry provides Session Attributes.

Session Attributes

Session Attributes enable the data to be stored by name instead of its type.

public class MyPage { 
   @SessionAttribute  
   private String loggedInUsername; 
}

By default, Session Attributes uses the field name to refer the data in session. We can change the reference name by annotation parameter as shown below −

public class MyPage { 
   @SessionAttribute("loggedInUserName") 
   private String userName; 
}

One of the main issues in using name as session reference is that we may accidentally use the same name in more than one class / page. In this case, the data stored maybe changed unexpectedly. To fix this issue, it will be better to use the name along with class / page name and package name like com.myapp.pages.register.email, where com.myapp.pages is the package name, register is the page / class name and finally email is variable (to be stored) name.

Advertisements