[weld-dev] A ConversationManager API

[Arbi Sookazian]

So a sample use case is a hotel or airplane booking (or even eBay) app where
the user has multiple tabs (and therefore multiple LRCs) running
simultaneously inside the same session.  If I could getTimeout() of a
non-current conversation then I could display to a user x seconds prior to
the LRC timing out a warning stating that "your work on tab Y is going to be
lost in 30 secs".  That way they know which conversations are going to
timeout when and won't lose work in important conversations.

In practical cases, I'm not sure how many apps actually need or use the
workspace switcher concept (org.jboss.seam.core.conversationEntries) that is
demonstrated in the hotel booking Seam example.  I have yet to use the
conversation switcher (conversationEntries and conversationList) in a
real-world Seam app.

What about the rest of the API related to conversations from the Seam core?

*Conversation<http://docs.jboss.org/seam/2.2.0.GA/api/org/jboss/seam/core/Conversation.html>
* Allows the conversation timeout to be set per-conversation, and the
conversation description and switchable outcome to be set when the
application requires workspace management functionality.  *
ConversationalInterceptor<http://docs.jboss.org/seam/2.2.0.GA/api/org/jboss/seam/core/ConversationalInterceptor.html>
* Check that a conversational bean is not being invoked outside the scope of
a long-running conversation.
*ConversationEntries<http://docs.jboss.org/seam/2.2.0.GA/api/org/jboss/seam/core/ConversationEntries.html>
* Manages a map of conversation id to ConversationEntry in the session
context.  *ConversationEntry<http://docs.jboss.org/seam/2.2.0.GA/api/org/jboss/seam/core/ConversationEntry.html>
* Metadata about an active conversation.
*ConversationIdGenerator<http://docs.jboss.org/seam/2.2.0.GA/api/org/jboss/seam/core/ConversationIdGenerator.html>
*    *ConversationInterceptor<http://docs.jboss.org/seam/2.2.0.GA/api/org/jboss/seam/core/ConversationInterceptor.html>
* Implements annotation-based conversation demarcation.
*ConversationList<http://docs.jboss.org/seam/2.2.0.GA/api/org/jboss/seam/core/ConversationList.html>
* Factory for the conversation list
*ConversationPropagation<http://docs.jboss.org/seam/2.2.0.GA/api/org/jboss/seam/core/ConversationPropagation.html>
* Overrideable component for extracting the conversation id from a request.
*ConversationStack<http://docs.jboss.org/seam/2.2.0.GA/api/org/jboss/seam/core/ConversationStack.html>
* Factory for the "breadcrumbs", a stack with all parent conversations of
the current conversation.
Are they going to be dismissed in the CDI API or slated for PE
implementations like in Seam 3?  Currently all I see in CDI API that is
conversation-related is Conversation interface and ConversationScoped
annotation.

And also, have you guys thought about using an abstract class rather than an
interface (or perhaps in addition to an interface) for some of the
conversation-related API?  So have the basic methods in the interface and
the "bonus" ones in an abstract class.

On Sat, Jan 30, 2010 at 11:22 AM, Nicklas Karlsson <nickarls at gmail.com>wrote:

> >> then NKarlsson's ConversationManager interface has more methods than the
> CDI version above, no?  So what do you mean by "These are already available
> on CDI's Conversation interface."?  I think that ConversationManager is a
> better name for a manager component than simply Conversation.
> >
> > These API are for different purposes, Conversation is for user control of
> the conversation, ConversationManager is an SPI that frameworks which
> integrate with Weld can use to control the built in conversation context.
>
> Yes, a Conversation is pretty much a plain parameter object that is
> tossed around and evaluated at the end of the request by the CM.
>
> >
> >>  What if I wanted to getTimeout() of a non-current conversation in the
> case there are multiple concurrent conversations in the current session?
> >
> > In that case, we need to know the use case.
> >
> > This can easily be solved by changing getConversations to return a Map.
>
> Hmm, I'm not that big of a fan of returning anything with a
> Conversation in it since the implementation is a request scoped bean
> and therfore proxied if stuck in a Map so it needs some "dehydration"
> anyway to a normal object with similar attributes (well, actually only
> the cid and the timout are interesting from a CM point of view)
>
> But do hit me with a usecase.
> ---
> Nik
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20100130/dcf0194f/attachment.html