its getting really interesting.... Josh+Davor: your're right.... "flash" should as well be part of the conversation context.
a small summary of my implementation so far: if a conversation is started a ConversationContext is created and stored in a ConversationTracker and the created conversation id is appended to the URL. The ConversationTracker itself is then stored as an ASO using the ApplicationStateManager. In implicit mode every field with an @Persist annotation is stored in the ConversationContext (if a conversation is active). ASOs are not part of the conversation because they are considered global, application-wide data objects. I did not replace the Session because it seemed to invasive to me. What do you think about this approach? is it viable? Should some ASOs be marked as part of the conversation? I hope i can make my source available in 3 weeks when i get approval from my superior. btw. i could solve my originally stated question by providing a Decorator for the PersistentFieldManager that intercepts postChange method calls and rerout every persistent field to the ConversationFieldStrategy implementation. just a sidenote... my conversation implementation will then be used for pageflows :) "Josh Canfield" <[EMAIL PROTECTED]> Gesendet von: [EMAIL PROTECTED] 21.12.2007 00:43 Bitte antworten an "Tapestry users" <users@tapestry.apache.org> An "Tapestry users" <users@tapestry.apache.org> Kopie Thema Re: [T5] overriding persistence strategy of all fields to conversation strategy Yeah, I'm not convinced either. Also, ApplicationState for instance should probably be stored outside of the context of a conversation as well... Josh On Dec 20, 2007 2:03 PM, Davor Hrg <[EMAIL PROTECTED]> wrote: > you are right, that is more usefull. > > instead introducing conversation to field level, > it should be set at page/component level. > > flash is I suppose already session specific and should be > also conversation specific, > but I'm still not convinced that something should be done to > those that explicitly state @Persist("session") > > Davor Hrg > > On Dec 20, 2007 7:03 PM, Josh Canfield <[EMAIL PROTECTED]> wrote: > > Hello, > > > > I think Flash persistence would also want to be in the context of the > > conversation, otherwise couldn't messages show up in the second window > that > > were intended for the first (perhaps with a slow connection to the > server?) > > > > Without having spent much time thinking about this (and never having > used > > Seam), it feels like a promising direction would be to redefine what a > > session means for your application. > > > > Tapestry already wraps the javax.servlet.http.HttpSession when it's > created > > in the Request object. Would it make sense to replace that > implementation > > with a ConversationSession that implements the Session interface but > > compartmentalizes the session by whatever it is that you are using for > > context? > > > > So in > > > http://tapestry.formos.com/nightly/tapestry5/apidocs/src-html/org/apache/tapestry/internal/services/SessionImpl.html > < > http://tapestry.formos.com/nightly/tapestry5/apidocs/src-html/org/apache/tapestry/internal/services/SessionImpl.html#line.29 > > > > 038 public Object getAttribute(String name) > > 039 { > > 040 return _session.getAttribute(name); > > 041 } > > becomes > > 038 public Object getAttribute(String name) > > 039 { > > 040 return _session.getAttribute(_myContextId).get(name); > > 041 } > > where _myContextId results in a map of context specific attributes... > > > > Admittedly I haven't coded anything around this idea so there could be > some > > fatal flaws, I just thought I'd throw it out there. > > > > Josh > > > > > > On Dec 20, 2007 12:25 AM, Davor Hrg <[EMAIL PROTECTED]> wrote: > > > > > It seems you are trying too hard to fix user mistakes, > > > > > > a developer using the conversation persistence strategy must be aware > of > > > it > > > and code accordingly. Forcing a specific persistence strategy can also > > > cause > > > undesired behaviours (for example error messages that use > > > @Persist("flash")) > > > > > > these are just my thoughts on the subject, I haven't really looked > deeper > > > into > > > persistence strategies... > > > > > > Davor Hrg > > > > > > On Dec 20, 2007 9:20 AM, Kristian Marinkovic > > > <[EMAIL PROTECTED]> wrote: > > > > hi filip, > > > > > > > > @Meta("tapestry.persistence-strategy=conversation") only works if > the > > > > @Persist annotation does not specify a strategy. I want to override > the > > > > strategy even if > > > > the developer has set it to a specific strategy.... so whenever a > > > > conversation is started > > > > the values of all persistent fields will be saved in the > conversation. > > > And > > > > i want to be able > > > > to switch it on or off during runtime because it should be able to > use > > > the > > > > same page with > > > > or without a conversation context. > > > > > > > > I think i've too look harder :) ... If i succeed i'll put my > solution > > > > open-source somewhere... :) > > > > > > > > g, > > > > kris > > > > > > > > > > > > > > > > > > > > "Filip S. Adamsen" <[EMAIL PROTECTED]> > > > > 19.12.2007 18:29 > > > > Bitte antworten an > > > > "Tapestry users" <users@tapestry.apache.org> > > > > > > > > > > > > An > > > > Tapestry users <users@tapestry.apache.org> > > > > Kopie > > > > > > > > Thema > > > > Re: [T5] overriding persistence strategy of all fields to > conversation > > > > strategy > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Stick a @Meta("tapestry.persistence-strategy=conversation") > annotation > > > > on your page class? > > > > > > > > -Filip > > > > > > > > Kristian Marinkovic skrev: > > > > > > > > > > Hi all, > > > > > > > > > > i'm currently implementing a conversation module (similar to seam) > by > > > > > defining an own persistence strategy. i thought of an explicit and > an > > > > > implicit mode for conversations. The explicit mode requires that > every > > > > > persistent field within a conversation is annotated with > > > > > @Persist("conversation"). the implicit mode would replace the > given > > > > > persistence strategy of any annotated field in a page with > > > > "conversation". > > > > > > > > > > Can someone help me how to solve this problem? The > > > > > PersistentFieldManager sets default strategies (@Meta) but cannot > be > > > > > overriden on a per page base. > > > > > > > > > > any suggestions? thanks > > > > > > > > > > g,kris > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > 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] > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > -- > > -- > > TheDailyTube.com. Sign up and get the best new videos on the internet > > delivered fresh to your inbox. > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- -- TheDailyTube.com. Sign up and get the best new videos on the internet delivered fresh to your inbox.