On Wed, Jan 14, 2009 at 1:39 AM, Geoff Callender < geoff.callender.jumpst...@gmail.com> wrote:
> It would be great if Tapestry provided a really nice clear solution to > conversation state (and continuations), but in the meantime the workarounds > are actually not all that hard. Have you looked at the 3 Wizard examples > and the Conversations List at > http://jumpstart.doublenegative.com.au:8080/jumpstart/ ? I know, and obviously I've looked at your examples; where else would one learn T5 from :) Continuations actually have very little to do with it when the only problem I really want to solve is to have a scope longer than request but one that doesn't pollute the session till it expires. While continuations and RIFE is very innovative, it really is targeted to solve a different problem than what I'm after. > One modification I'd like to make to the Wizards is to defer assigning a > conversation id until you're on your way from the first page to the second > page. > Howard's talking about somehow making 5.1 work with Spring WebFlow. I'll > follow that one with great interest, but I'll be wearing my sceptics hat as > I fear that the SWF medicine might be worse than the problem it's trying to > solve. > Agree, flows complicate things and don't offer a generic solution to this problem. I've used SWF (and tried out Seam as well) but I really don't want to force developers to require configuring flows consisting of multiple pages when most of the time you just want that object to survive through a few requests so you can display the validation errors and/or the success message with the data the object contains. Personally I'm sold on ajax to a point where I don't see a need to worry about back buttons or design operation logic in a traditional way with multiple pages for a single operation/conversation. Pages/urls are useful for differentiating between separate logical operations like edit profile or search but if you click on back button you should go to the previous operation, not to a previous stage within the same operation. Wizards are of course a little different; you may want to even independently store the whole state once you are half-way through the wizard and go back and forth between the stages (where continuations are also very useful), but the conversations in my mind a really short-lived, happening for example on a single page/stage/url of a wizard. Thanks Geoff for the links as well; if we have any other threads about this on the Tapestry mailing list, please continue linking them here. Kalle > Here are some good discussions of the problem: > > > http://www.developertutorials.com/tutorials/java/develop-complex-web-applications-050422/page1.html > > http://rifers.org/blogs/gbevin/2005/4/11/continuations_continuations > http://www.artima.com/forums/flat.jsp?forum=226&thread=197351 > > http://debasishg.blogspot.com/2006/07/spring-web-flow-declarative-web.html > > Geoff > > > On 14/01/2009, at 5:25 PM, Kalle Korhonen 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 >>>> >>>> >>>> >>> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > >
