[weld-dev] A ConversationManager API

[Arbi Sookazian]

Also, I remember a while back there was a use case and JIRA in which we
needed to restart the LRC after user selects a different value in a
HtmlSelectOneMenu component.  For some reason this was not possible due to
the JSF lifecycle IIRC.

http://omgili.com/mailinglist/seam-issues/lists/jboss/org/104215931222531050876JavaMailjiracloudprodatl2jbosscom.html

This JIRA has been deleted.  So I'm assuming a restart() is not in the
plans...

On Sat, Jan 30, 2010 at 4:37 PM, Arbi Sookazian <asookazian at gmail.com>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<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/0ef4265d/attachment-0001.html