The main reason to store properties in an ASO rather than directly use the session was that I found it nicer when cleaning up (no need to iterate over all session-attributes and match keys). The conversation manager is a plain hivemind service, same as in your solution.
> -----Original Message----- > From: Howard Lewis Ship [mailto:[EMAIL PROTECTED] > Sent: Tuesday, January 24, 2006 1:21 AM > To: Tapestry users > Subject: Re: Tapestry and Web Conversations (Seam / Spring WebFlow) > > > Seems to me, that if you have a "conversation id" string, you could > just store page properties with conversation scope state directly in > the session, but incorporate the conversation id into the session > attribute name. I did something not too dissimilar for tapestry-flash > (and refactored the "session" scope implementation to make it easier > to create new scopes that are ultimately stored in the HttpSession). > > Ideally, the conversation state manager could be a HiveMind service, > not an ASO, that would manage the storing of it internal state into > the HttpSession. > > Also, I should be saying WebSession, not HttpSession ... the value is > magnified if it is not dependent on the servlet API. > > On 1/23/06, Schulte Marcus <[EMAIL PROTECTED]> wrote: > > > Your approach seems interesting. But I don't know if it would > > > be cleaner > > > to implement that kind of ASO and declare it in Hivemind. > > > Something like this: > > > > > > <state-object name="some-conversation" scope="conversation"> > > > <create-instance class="xxx.some.builder.class"/> > > > </state-object> > > > > > > > Actually that's pretty much what I did. My previous > explanations were a bit > > incomplete. Currently my setup in kickstart is as follows: > > > > a) I have one "special", session-scoped ASO, the current > conversation, which > > is, basically, a Map, and an ASO-Manager which can be > called to clean out > > the map (=terminate the conversation). This is a plain > Tapestry ASO, no > > magic involved. > > > > b) Then I have a new ASO-scope "conversation", exactly as > you propose. The > > corresponding ApplicationsStateManger stores its > conversation-scoped ASOs in > > the session scoped conversation-ASO from a) > > > > c) And there' the PropertyPersistenceStrategy, of course. > It's also called > > "conversation" ;) and stores its inhabitants in _the_ > conversation-ASO from > > a) > > > > d) Finally there's a hivemeind service-model, somewhat > inappropriately > > called "stateful" which stores a service in ... the > conversation-ASO from > > a). > > > > So, it's really nothing new - just some wiring together - thanks to > > hivemind. > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: > [EMAIL PROTECTED] > > > > > > > -- > Howard M. Lewis Ship > Independent J2EE / Open-Source Java Consultant > Creator, Jakarta Tapestry > Creator, Jakarta HiveMind > > Professional Tapestry training, mentoring, support > and project work. http://howardlewisship.com > > --------------------------------------------------------------------- > 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]
