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. ConversationalInterceptor Check that a conversational bean is not being invoked outside the scope of a long-running conversation. 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. ConversationList Factory for the conversation list ConversationPropagation Overrideable component for extracting the conversation id from a request. ConversationStack 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@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.Yes, a Conversation is pretty much a plain parameter object that is
>
> 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.
tossed around and evaluated at the end of the request by the CM.
Hmm, I'm not that big of a fan of returning anything with a
>
>> 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.
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