I don't know if there's a better thread for discussing page scope and conversation (if you know other threads, please link them in) but I'm just doing research on this topic for supporting conversations in Trails. Shortly, I'm hoping that it'd be possible to have a generic implementation for conversations by dictating that a conversation should always happen on a single "page" or url with asynchronous calls. From my point of view, assuming that only the beginning of a conversation can be bookmarkable and that a conversation has one-to-one mapping with a url are reasonable conventions and will greatly simplify the required logic (compared to xml-based navigation flow configurations). These conversations could also be cleaned from session before the session expires and can have individual timeout values.
Regarding the problem with multiple pages that others have already pointed out, with or without using cookies the urls need to be different (so the page contexts can be kept separate). Typically when editing a single object, you don't even want to allow multiple windows and this can be easily dealt with cookies transparently to the user. The only good example of where multi-window support is actually useful that I can come up with is search (say when you are trying to find the best flight to a destination). There, I wouldn't even like to necessary have a conversation identifier as part of the url, but as a parameter (e.g. /travelsearch?conversationId=123) since it's not meaningful to bookmark a url with a conversationId in it, but T5 doesn't allow one to easily manipulate urls and the page context is extremely handy way of making sure all subsequent action requests (from the same page) are participating in the same conversation. However, one of the issues with T5 I haven't been able to satisfactorily solve is forcing a page to use an additional context parameter. I've tried with returning the same page from onActivate then setting a conversation id in onPassivate, which works in principle but only if I persist the conversation id which kind of defies the point. Anybody happen to have a good, generic solution for automatically adding parameters to the activation context (so they are visible in the url)? I'd be also interested to know if anybody has thoughts on these ideas or is further along in providing a generic implementation for conversations in T5. Kalle On Fri, Dec 12, 2008 at 11:00 AM, Daniel Jue <teamp...@gmail.com> wrote: > In the past I manually implemented this behavior by mixing server side and > client side persistence. My code-fu was probably not very elegant. > > In my case, a user could open a report page after filling out a page of > variables. These report pages would open in a new browser window/tab. So > instantly you have the situation where two reports can be open but use > different data. I would store a client side string on each report page, > and > LRU hash map on the ASO side would match it to the relative data, just > before the report was run and a new page opened. If it was in the LRU, I > could grab the cached report. If not, I still had enough information to > run > the report again. If the report page needed to be refreshed (such as > sorting something on the page, non-async), the client side key would look > up > the data. > > I used a small LRU limit (like 5) to keep the size down. > > Daniel > > On Fri, Nov 28, 2008 at 10:18 PM, thermus <msch...@gmail.com> wrote: > > > > > I'm interested in this as well. Specifically if a user has two page > > instances open, how can T5 persistence be used reliably? > > > > I found on Safari and Firefox (not sure about IE, but likely a problem > > there > > as well) that the persisted session properties are shared between page > > instances and each page can overwrite the another. My searches didn't > come > > up with a definitive answer although I did see that the question has been > > asked several times. Can anyone comment on this or provide a workaround? > > > > > > > > Peter Stavrinides wrote: > > > > > > ... but what would be ideal in my humble view is a proper page > > persistence > > > Strategy, where a value is retained until the user leaves the page. In > > > truth someone posted such a solution which used a cookie, and it seemed > > to > > > behave exactly as it should, nevertheless I am still against relying on > a > > > cookie. I understand this may be difficult to implement due to > Tapestry's > > > inner workings, particularly the way pages are pooled, but since > > > conversational state covers some of this ground (the difference being a > > > conversation is tied to not only the page, but the window so each tab > is > > > treated as a new conversation)... > > > > > > > -- > > View this message in context: > > http://www.nabble.com/Persistance-tp20732003p20743522.html > > Sent from the Tapestry - User mailing list archive at Nabble.com. > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > > For additional commands, e-mail: users-h...@tapestry.apache.org > > > > >
