Moi Kalle, I would try to achieve something like that using:
Custom PersistentFieldStrategy (http://tapestry.apache.org/tapestry5/apidocs/org/apache/tapestry5/services/PersistentFieldStrategy.html) Custom LinkFactoryListener (http://tapestry.apache.org/tapestry5/apidocs/org/apache/tapestry5/internal/services/LinkFactoryListener.html) Custom ComponentEventRequestFilter + PageRenderRequestFilter (http://tapestry.apache.org/tapestry5/apidocs/org/apache/tapestry5/services/ComponentEventRequestFilter.html) Then in theory you can code the conversation id to all links and forms, use the filters to intercept the request and get the id back and finally use the id to retrieve the value from ConversationManager via the CustomPersistence strategy. The persistence strategy may use ehcache or something like that to actually persist the objects. The request object can be used to transmit the conversation id from the filter to the persistence strategy? This implementation could also be per client tab and not at all dependent of the session etc. Just some quick thoughts.. - Ville Kalle Korhonen-2 wrote: > > 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 >> > >> > >> > > -- View this message in context: http://www.nabble.com/Persistance-tp20732003p21452575.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
