But still the wizard example requires session in some form and thus the same conversation in two tabs scenario is not possible?
- Ville Geoff Callender-2 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/ > ? > > 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. > > 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 > > > -- View this message in context: http://www.nabble.com/Persistance-tp20732003p21454462.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
