Friday, April 23, 2010

Persist Sessions and Clients

Tapestry 5 provides the @Persist annotation. I think something like this actually showed up in T4. In T5 there are three modes:

@Persist(PersistenceConstants.SESSION)
@Persist(PersistenceConstants.CLIENTS)
@Persist(PersistenceConstants.FLASH)

SESSION is the default, so you can just specify it as:

@Persist
private String username;

As with the "Visit" in tapestry 3 the Session Persistence is supported with a cookie that acts as a key to the actual session data.

FLASH persistence is useful because of the way form submits are handled. The Page object processes a set of methods specifically for handling form submissions, then at the end of every form submission a client redirect is performed. This means that following every submit, the browser is told to request a new page (it can be the same page if there were errors on the form).

That redirected request will like involve a completely different instance of a page, even if it is the "same" page. FLASH persistence saves data for exactly one render cylce. Error messages are passed to the redirected page using FLASH persistence. Also if you want to redisplay the values that were entered into the form so that the user can make changes to clear the error instead of retyping everything, then you will have to either FLASH persist all of fields or FLASH persist a primary key which will allow you to retrieve the data.

Fortunately it looks like error messages stored using "recordError" and properties linked to Form templates (i.e. input tags) are all automatically FLASH persisted. Exactly what else is FLASH persisted is still a mystery to me.

What I do know is if you create a private property to use as a form "context" for the purpose of maintaining a "primary key" for the life of the form, and that property has a custom getter because it is a complex class that requires serialization, then you will have to define it using:

@Persist(PersistenceConstants.FLASH)
private Key _key;

If you have other one time messages or text besides the ones saved using the "record.Error" function, like maybe something that says "Changes saved" then you will need to apply the @Persist(PersistenceConstants.FLASH) annotation to those as well.

CLIENT persistance is almost useless. I guess if there was no way to keep track of a session it might be helpful. The problem with it is any data placed in CLIENT persistence must be serialized into every link and every form POST on the page. If the data is a little bit big then your page will become huge and the URLs too long. So long in fact that data might get truncated by some browsers.

No comments:

Post a Comment