I think he meant that it would be cleaner - from a hivemind/tapestry perspective - to let a service manage where the object goes. (Ie gives greater flexibility for ?? in the future, feels less icky )
that's what I thought at least. We use aso/user scoped objects in our app as well, but very rarely interact with them directly. Mostly services use them. (Like security/db auditing/etc services) On 1/23/06, Scott Russell <[EMAIL PROTECTED]> wrote: > > I thought the idea of Seam was to store the stateful state in an EJB3 > stateful > session bean. So really apart from replacing the JDF specific stuff with > Tapestry specific stuff, you'd only have to store the SessionBean > reference > in an ASO. > > -Scott > > > On Tue 24 January 2006 10:20, Howard Lewis Ship wrote: > > 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] > >
