Tapestry5.2.4 中 PersistenceConstants 的源码

Tapestry5中对一个属性使用下列语法

@Persist(PersistenceConstants.FLASH) private FlashMessage flashMessage; //其他Set和Get方法

第一点：@Persist的意思是在不同的页面之间，也就是不同的请求之间数据保存的策略，使用的策略是由常量tapestry.persistence-strategy来配置的，如果配置了这个常量值，则以这个值为准，否则就以session策略为准。

第二点：类PersistenceConstants有三个静态常量，分别是session、client和flash。

/** * The field's value is stored in the {@link org.apache.tapestry5.services.Session}. */ public static final String SESSION = "session"; /** * The field's value is stored on the client, as a query parameter or hidden form field. */ public static final String CLIENT = "client"; /** * A that stores data in the session, but only until the next request. This is often * used for confirmation messages presented to the user. */ public static final String FLASH = "flash";

 

session策略：第一点中就说明了，如果未指定tapestry.persistence-strategy的时候使用session策略，也就是上面代码中的第一种策略，存储的数据是保存在session中的。

 

flash策略：这样的属性数据是存储在客户端，作为查询或者隐藏 form 域用。

 

flash策略：client策略下的数据也是存储在session中的，但仅仅是持续到下一个请求，通常用来提供给用户的确认信息。

 

---

 

以下是官方对于Tapestry5中的页面持久化数据的介绍

 

Persistent Page Data

Most instance variables in Tapestry are automatically cleared at the end of each request.

This is important, as it pertains to how Tapestry pages are pooled and shared, over time, by many users.

However, you often want to store some persistent data on a single page, and have access to it in later requests. Long term storage of data should go in a database of some form, but server-side state for the duration of the as user's interaction with the application should go in the HttpSession (though Tapestry provides a few other options as well).

Note: To store values that may be accessed across multiple pages, uses a session state object.

Making a field persistent is accomplished with the Persist annotation. Again, this does not refer to database persistence, it refers to session persistance.

This annotation is applied to private instance fields of components.

  @Persist
  private int value;

Annotated fields will store their state between requests. Generally, speaking, this means that the value is stored into the session (but other approaches are possible).

Whenever you make a change to a persistent field, its value is stored.

On later requests, the value for such persistent fields is reloaded from storage.

Persistence Strategies

The value for each field is the strategy used to store the field between requests.

session strategy

The session strategy stores field changes into the session; the session is created as necessary.

A suitably long session attribute name is used; it incorporates the name of the page, the nested component id, and the name of the field.

Session strategy is the default strategy used unless otherwise overridden.

flash strategy

The flash strategy stores information in the session as well, just for not very long. Values are stored into the session, but then deleted from the session as they are first used to restore a page's state.

The flash is typically used to store temporary messages that should only be displayed to the user once.

  @Persist(PersistenceConstants.FLASH)
  private String message;

client strategy

The field is persisted onto the client; you will see an additional query parameter in each URL (or an extra hidden field in each form).

Client persistence is somewhat expensive. It can bloat the size of the rendered pages by adding hundreds of characters to each link. There is extra processing on each request to de-serialize the values encoded into the query parameter.

Client persistence does not scale very well; as more information is stored into the query parameter, its length can become problematic. In many cases, web browsers, firewalls or other servers may silently truncate the URL which will break the application.

Use client persistence with care, and store a minimal amount of data. Try to store the identity (that is, primary key) of an object, rather than the object itself.

  @Persist(PersistenceConstants.CLIENT)
  private String message; 

Persistence Search

By default the value for the Persist annotation is the empty string. When this is true, then the actual strategy to be used is determined by a search up the component hiearchy.

For each component, the meta-data property tapestry.persistence-strategy is checked. This can be specified using the Meta annotation.

If the value is non-blank, then that strategy is used. This allows a component to control the persistence strategy used inside any sub-components (that don't explicitly use a different strategy).

In any case, if no component provides the meta data, then the ultimate default, "session", is used.

Default Values

Fields marked with @Persist may not have default values (whether set inline, or inside a constructor).

Clearing Persistent Fields

If you reach a point where you know that all data for a page can be discarded, you can do exactly that.

The method discardPersistentFieldChanges() of ComponentResources will discard all persistent fields for the page, regardless of which strategy is used to store the property. This will not affect the page in memory, but takes effect for subsequent requests.

Clustering Issues

The Servlet API was designed with the intention that there would be only a modest amount of server-side state, and that the stored values would be individual numbers and strings, and thus, immutable.

Many web frameworks do not use the HttpSession this way, and store large and mutable objects in the session.

This is not an issue for single servers, but in a cluster, anything stored in the session must be serialized to a bytestream and distributed to other servers within the cluster, and restored there.

Most application servers perform the serialization and distribution as part of HttpSession.setAttribute().

This creates a problem for mutable objects, because if you read a mutable session object, change its state, but don't invoke setAttribute(), the changes will be isolated to just a single server in the cluster.

Tapestry attempts to solve this: any session persisted object that is read during a request will be re-stored back into the HttpSession at the end of the request. This ensures that changed internal state of those mutable objects is properly replicated around the cluster.

This can be a problem in a cluster as all those calls to setAttribute() may impact performance, as often the internal state of the mutable object don't have changed.

Tapestry has solutions to this.

Immutable Objects

Tapestry knows that Java's String, Number and Boolean classes are immutable. Immutable objects do not require a re-store into the session.

You can mark your own session objects as immutable using the ImmutableSessionPersistedObject annotation.

OptimizedSessionPersistedObject

The OptimizedSessionPersistedObject interface allows an object to control this behavior. An object with this interface can track when its mutable state changes. Typically, you should extend from the BaseOptimizedSessionPersistedObject base class.

SessionPersistedObjectAnalyzer

The SessionPersistedObjectAnalyzer service is ultimately responsible for determining whether a session persisted object is dirty or not (dirty meaning in need of a restore into the session). This is an extensible service where new strategies, for new classes, can be introduced.

Session Data

When integrating Tapestry with legacy applications it is often required to read or to write some data from or into the HttpSession.

public class Page
{
    @Inject
    private Request request;
    
    public User getUser()
    {
        return (User) request.getSession(true).getAttribute("user");
    }

} 

Since 5.2 this can be accomplished just by annotating a page or component property with @SessionAttribute. This annotation is used to map a property of a page or component to value stored in session. The name of the annotated property is used as the name of the session attribute to look for. You can also provide a name by binding the value parameter of the annotation.

 

public class Page { @SessionAttribute private User user; }

 

官方地址：http://tapestry.apache.org/tapestry5.2-dev/guide/persist.html