Tapestry - Persistent data is overridden when user opens a new tab

Question

I am using annotation @Persist(PersistenceConstants.SESSION) to make some data persistent.

Problem is that, when user opens a new tab of the same page type, the persistent data is overridden.

I want the data to be persistent per page and not per session so that each page has its own set of persistent data. How can I achieve this in Tapestry?

Answer 1

The first question I always ask when someone wants to use the session is "do you really need to use the session?"

Without seeing your code it's difficult to help you but I always solve these problems without using the session. If you always pass the identifiers in the URL then you can have the same page open in multiple browser windows for different entities and everything will just work.

Option 1: Use Page activation context (for page loads) and the event context (for eventlink / actionlink) to maintain the entity id's between requests.

Option 2: Use @Persist(PersistenceConstants.CLIENT) which will use request parameters to pass the entity id's between client and server each time.

If you really want to use the HTTPSession, you can use tapestry-conversations but please consider this a last resort after considering the two stateless / URL based approaches I've mentioned above.

Answer 2

Define a page property as: @Persist(PersistenceConstants.SESSION) means it is stored in the user session in the web container and shared by all requests for the same user. Opening a new tab in the browser will identify it as the same client to the server thus reuse the same user session.

I want the data to be persistent per page and not per session so that each page has its own set of persistent data.

This is probably not something that can be supported by Tapestry out-of-box unless you implement you own persist strategy, which takes a client page id that is unique among multiple tabs of the same pages. But this sounds like bad idea and I will probably never try to do something like that.

Refer to the suggested answer above. If you don't find what you want and you're building something that is client-heavy, I think you might need to resort to use the browser local storage in JavaScript to achieve what you want.