Ok, it uses currentMillis inside the session to differentiate the conversations. It works, but as we are seasoned T5 users we expect everything to just work without all that scary java code :)
- Ville Ps. Seriously I appreciate greatly your effort and just want to say Thank you. (I've learned quite a bit reading through jumpstart examples.) Geoff Callender-2 wrote: > > Try it! > > What you'll see is that if you open two tabs or windows and then start > the Wizard in each one then they will get different conversations. > This allows you, for example, to work on two orders at once. > > If, however, you start the Wizard AND then open a new tab or window > AND your browser preferences are set to open with the current URL AND > the browser is not IE or Chrome, then they will share the > conversation. I think this is reasonable because it's the preference > you have set. To avoid it, I guess some javascript would be required > to detect the situation in the new tab or window or perhaps to prevent > new tab or window being started? But maybe that's going too far? > > Geoff > > On 14/01/2009, at 10:45 PM, Ville Virtanen wrote: > >> >> 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 >> > > > --------------------------------------------------------------------- > 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-tp20732003p21455977.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
