Re: Persistance
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 paramete
Re: Persistance
On Wed, Jan 14, 2009 at 1:29 AM, Ville Virtanen 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 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 >
Re: Persistance
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 ha
Re: Persistance
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 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
Re: Persistance
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 >> 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. >
Re: Persistance
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 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 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
Re: Persistance
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 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 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 >> > instance
Re: Persistance
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 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 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: user
Re: Persistance
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 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 > >
Re: Persistance
I think this feature would set Tapestry 5 even further apart from the rest, go
vote for it at:
https://issues.apache.org/jira/browse/TAP5-411
cheers,
Peter
- Original Message -
From: "Hugo Palma" <[EMAIL PROTECTED]>
To: "Tapestry users"
Sent: Thursday, 11 December, 2008 12:52:37 PM GMT +02:00 Athens, Beirut,
Bucharest, Istanbul
Subject: Re: Persistance
I myself have found the need for such a persistence strategy.
I would suggest creating an issue for this so that people can vote and
follow it.
On Fri, Nov 28, 2008 at 10:23 AM, Peter Stavrinides <
[EMAIL PROTECTED]> wrote:
> Hi,
>
> I have been thinking about persistence lately... and after moving all our
> apps from Tapestry 4 to Tapestry 5 this past year, I have noticed distinct
> patterns emerge in the way pages fit together and use persistence, and I
> have been searching all the while for best practices... here are some
> comments on how persistence evolved in my code:
>
> @Persist - I tended to use it a lot in the beginning, but far less now, I
> have found it optimal not to clutter the session, and therefore persist only
> a select few fields (mostly primitives).
>
> @Persist("flash") - I moved to flash persistence wherever I could, as it
> helps limit the number of queries required, but its not always feasible to
> use. On the odd occasion I also ran into problems with render methods when
> pages were complex.
>
> I now use mostly onActivate and onPassivate, this has proven to be the most
> reliable pattern, and the most scalable. It does require a bit more
> boilerplate code for checking that URL parameters are passed correctly,
> particularly for pages that have 'optional parameters'... the one downside
> is that I have a few more queries now.
>
> So whats missing in an ideal world? A read in a post some time ago that
> conversational patterns may be added in 5.1, that would be great! 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), I thought to at least to ask if it could be considered at
> some point if at all feasible. I would also love to hear other peoples
> thoughts/opinions on this.
>
> cheers,
> Peter
>
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Persistance
I myself have found the need for such a persistence strategy.
I would suggest creating an issue for this so that people can vote and
follow it.
On Fri, Nov 28, 2008 at 10:23 AM, Peter Stavrinides <
[EMAIL PROTECTED]> wrote:
> Hi,
>
> I have been thinking about persistence lately... and after moving all our
> apps from Tapestry 4 to Tapestry 5 this past year, I have noticed distinct
> patterns emerge in the way pages fit together and use persistence, and I
> have been searching all the while for best practices... here are some
> comments on how persistence evolved in my code:
>
> @Persist - I tended to use it a lot in the beginning, but far less now, I
> have found it optimal not to clutter the session, and therefore persist only
> a select few fields (mostly primitives).
>
> @Persist("flash") - I moved to flash persistence wherever I could, as it
> helps limit the number of queries required, but its not always feasible to
> use. On the odd occasion I also ran into problems with render methods when
> pages were complex.
>
> I now use mostly onActivate and onPassivate, this has proven to be the most
> reliable pattern, and the most scalable. It does require a bit more
> boilerplate code for checking that URL parameters are passed correctly,
> particularly for pages that have 'optional parameters'... the one downside
> is that I have a few more queries now.
>
> So whats missing in an ideal world? A read in a post some time ago that
> conversational patterns may be added in 5.1, that would be great! 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), I thought to at least to ask if it could be considered at
> some point if at all feasible. I would also love to hear other peoples
> thoughts/opinions on this.
>
> cheers,
> Peter
>
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
Re: Persistance
Hi
Yeah in our T4 app we don't use @Persist at all and we really control the
session-size ... we have been setting up to open source this code that
handles the session issues.
I have been wanting to get the code in better shape before releasing back to
the community ... but it is good enough. .. I just submitted the project to
sourceforge for consideration. I have to wait a few days for approval.
Patrick Moore
Amplafi
http://amplafi.com
650-207-9792
"copy/paste"
blog : http://www.sworddance.com/blog
On Sat, Nov 29, 2008 at 6:19 AM, Marcelo Lotif <[EMAIL PROTECTED]> wrote:
> I think this is very interesting too, and I have implemented something like
> this in a menu component I've made, but the solution is specific to my
> case.
>
> This persistence strategy would be a nice improvement, and would solve some
> problems we had with the session size.
>
> On Fri, Nov 28, 2008 at 7:23 AM, Peter Stavrinides <
> [EMAIL PROTECTED]> wrote:
>
> > Hi,
> >
> > I have been thinking about persistence lately... and after moving all our
> > apps from Tapestry 4 to Tapestry 5 this past year, I have noticed
> distinct
> > patterns emerge in the way pages fit together and use persistence, and I
> > have been searching all the while for best practices... here are some
> > comments on how persistence evolved in my code:
> >
> > @Persist - I tended to use it a lot in the beginning, but far less now, I
> > have found it optimal not to clutter the session, and therefore persist
> only
> > a select few fields (mostly primitives).
> >
> > @Persist("flash") - I moved to flash persistence wherever I could, as it
> > helps limit the number of queries required, but its not always feasible
> to
> > use. On the odd occasion I also ran into problems with render methods
> when
> > pages were complex.
> >
> > I now use mostly onActivate and onPassivate, this has proven to be the
> most
> > reliable pattern, and the most scalable. It does require a bit more
> > boilerplate code for checking that URL parameters are passed correctly,
> > particularly for pages that have 'optional parameters'... the one
> downside
> > is that I have a few more queries now.
> >
> > So whats missing in an ideal world? A read in a post some time ago that
> > conversational patterns may be added in 5.1, that would be great! 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), I thought to at least to ask if it could be considered at
> > some point if at all feasible. I would also love to hear other peoples
> > thoughts/opinions on this.
> >
> > cheers,
> > Peter
> >
> >
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> --
> Atenciosamente,
>
> Marcelo Lotif
> Programador Java e Tapestry
> FIEC - Federação das Indústrias do Estado do Ceará
> (85) 3477-5910
>
Re: Persistance
I think this is very interesting too, and I have implemented something like
this in a menu component I've made, but the solution is specific to my case.
This persistence strategy would be a nice improvement, and would solve some
problems we had with the session size.
On Fri, Nov 28, 2008 at 7:23 AM, Peter Stavrinides <
[EMAIL PROTECTED]> wrote:
> Hi,
>
> I have been thinking about persistence lately... and after moving all our
> apps from Tapestry 4 to Tapestry 5 this past year, I have noticed distinct
> patterns emerge in the way pages fit together and use persistence, and I
> have been searching all the while for best practices... here are some
> comments on how persistence evolved in my code:
>
> @Persist - I tended to use it a lot in the beginning, but far less now, I
> have found it optimal not to clutter the session, and therefore persist only
> a select few fields (mostly primitives).
>
> @Persist("flash") - I moved to flash persistence wherever I could, as it
> helps limit the number of queries required, but its not always feasible to
> use. On the odd occasion I also ran into problems with render methods when
> pages were complex.
>
> I now use mostly onActivate and onPassivate, this has proven to be the most
> reliable pattern, and the most scalable. It does require a bit more
> boilerplate code for checking that URL parameters are passed correctly,
> particularly for pages that have 'optional parameters'... the one downside
> is that I have a few more queries now.
>
> So whats missing in an ideal world? A read in a post some time ago that
> conversational patterns may be added in 5.1, that would be great! 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), I thought to at least to ask if it could be considered at
> some point if at all feasible. I would also love to hear other peoples
> thoughts/opinions on this.
>
> cheers,
> Peter
>
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
Atenciosamente,
Marcelo Lotif
Programador Java e Tapestry
FIEC - Federação das Indústrias do Estado do Ceará
(85) 3477-5910
Re: Persistance
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
