[weld-dev] A ConversationManager API

[Nicklas Karlsson]

On Mon, Feb 1, 2010 at 4:01 PM, William Draï <william.drai at graniteds.org>wrote:

> Right for the ConversationManager.beginConversation, there is already
> Conversation.begin. I've been mistaken by the
> ConversationManager.endConversation of Niklas' proposal.
>
> I can maybe explain how we use the currently existing API, and in fact we
> are relatively happy with what exists today, except for one thing :
>
> start() {
>     ConversatonManager manager = { get from BeanManager };
>     manager.beginOrRestoreConversation(cid);
>     Conversation conversation = { get from BeanManager };
>
>     // Beginning of the ugly part !!
>     String cid = ((ConversationImpl)conversation).getUnderlyingId();
>     ConversationContext ctx =
> Container.instance().deploymentServices().get(ContextLifecycle.class).getConversationContext();
>     ctx.setBeanStore(new ConversationBeanStore(httpSession, cid));
>     ctx.setActive(true);
>     // End of the ugly part
>
>     if (cid != null && conversation.isTransient())  // Don't remember why I
> need this, beginOrRestore should be enough
>         conversation.begin(cid);
> }
>
> end() {
>     ConversationManager manager = { get from BeanManager };
>     manager.cleanupConversation();
> }
>
> The main thing is that I would prefer not having to mess with bean stores
> and contexts, so the manager.activateContext() looks fine. Ideally here what
> I would like to do (I know, I'm too lazy :-)) :
>
> start() {
>     ConversatonManager manager = { get from BeanManager };
>     manager.startupConversation();
>
>     if (cid != null && conversation.isTransient())
>         conversation.beginOrRestoreConversation(cid);
> }
>
> end() {
>     ConversationManager manager = { get from BeanManager };
>     manager.cleanupConversation();
> }
>
> From Flex, there is no need to switch the conversation in a particular
> request, but getting the list of the currently existing conversations with
> ConversationManager.getCurrentConversationIds() can be useful.
>
>
The beanstore-thingie with underlyingId will most likely go away soon as we
are tuning the contexts to survive session invalidation with a two-stage
BeanStore (that doesn't require id:s for transient conversations) so you
will probably get away with a single call to activate the conversation
context to start with a fresh transient conversation.



> Finally I really think it's necessary to be able to share a conversation
> instance between different UIs and use the same ConversationContext
> implementation for all. We could obviously ship a FlexConversationContext
> with GraniteDS/CDI but we want to make possible to build applications where
> a part of the UI uses JSF, another part uses Flex and why not another uses
> ZK or the iPhone SDK.
>
>
"Sharing a conversation instance" as in "running it on several UI:s
simultaneously" might be a bit tricky as the conversations don't pass the
session boundary (per spec) when running in JSF

-- 
---
Nik
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20100202/bdd05b88/attachment.html