I dropped the Seam integration since it seems that it's too integrated with JSF for my linking (especially the use of ViewStates, I guess). I think conversation-scoped objects could be implemented in Tapestry using a new kind of ASO, the "conversation" kind. I don't know the mechanics of how it works though. My guess is that conversation-scoped objects uses the Viewstate to follow a single user conversation through several pages, but that has a lot of problems.

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>

So that would allow code to use the usual ASO machinery to access those conversations ;).


--
Ing. Leonardo Quijano Vincenzi
DTQ Software



Schulte Marcus wrote:
I've been trying to implement conversations on top of Tapestry/Hivemind
(currently no SEAM involved) in http://kickstart.sf.net.

My implementation, however, seems to fall short of your requirement of
multiple, simultaneously active conversations (same pages in different
browser-tabs). Currently a conversation in my approach is a session-scoped
aso which can be terminated using a conversation-manager. Also, there's a
ConversationPropertyPersistenceStrategy that persists page-properties in the
conversation instead of the session.

My first stab at this would be:
  1. allow for different conversations to be started/ended/accessed by id
  2. Implement a PropertyPersistenceStrategy storing the current
conversation context (id) on the client using
addParametersForPersistentProperties. Then, persist all properties in the
conversation denoted by this id.
  3. The conversation id would be set to a new one (fresh conversation) in
some listener corresponding to start conversation X semantics.

does this sound reasonable? I'd be very interested in details about how you
manage SEAM integration. I've thought about this myself, but was to short on
time for a new framework.

marcus



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to