On Wed, Jan 14, 2009 at 1:29 AM, Ville Virtanen <ville.virta...@cerion.fi>wrote:
> 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 > ) > Moi moi Ville, thanks for the links. A custom PersistentFieldStrategy is certainly something I'm currently looking into. > 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? I think its a minor detail whether the id is part of the url a parameter. EHCache doesn't really come to play, I actually want to keep the conversation as part of the session (you log out, it'll end all conversations). In my view, users would have lots of short-lived conversations going on, each using session but so they don't step on each other. This implementation could also be per client tab and not at all dependent of > the session etc. >From my opinion, a session is one of the biggest things going for Java webapps compared to two-tier db-backed architectures like PHP, we just have to learn to use it the right way. Kalle > 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 > >
