[weld-dev] A ConversationManager API

[Pete Muir]

On 31 Jan 2010, at 00:37, Arbi Sookazian wrote:

> 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	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.

This exists.

> ConversationalInterceptor	Check that a conversational bean is not being invoked outside the scope of a long-running conversation.

Is this really useful?

> ConversationEntries	Manages a map of conversation id to ConversationEntry in the session context.
> ConversationEntry	Metadata about an active conversation.
> ConversationIdGenerator	 
> ConversationInterceptor	Implements annotation-based conversation demarcation.

Implementation detail.

> ConversationList	Factory for the conversation list

Yes, possibly useful for the workspace switcher, however lets address that there (but it does indicate that getting the current conversations is useful).

> ConversationPropagation	Overrideable component for extracting the conversation id from a request.

Now more tightly spec'd

> ConversationStack	Factory for the "breadcrumbs", a stack with all parent conversations of the current conversation.

Related to nested conversations, which we may add.

> 
> 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.

How is this useful? Conversation/ConversationManager are container provided beans.

> 
> 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
> 
> _______________________________________________
> weld-dev mailing list
> weld-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev