Also please don't forget that it's _REALLY_ simple to just add another scope.
That's a matter of 30 minutes. And au contraire to many other DI containers, you can
ship your new context impl easily within the war.
So I personally am not a big fan of trying to make the provided conversation an all seeing
eye (which can fly and breath under water), because the various needs are too different
(See [1] for a description of my current favourite conversation).
LieGrue,
strub
[1]
http://wiki.apache.org/myfaces/ViewConversationScoped
--- On Mon, 2/1/10, Nicklas Karlsson <nickarls(a)gmail.com> wrote:
From: Nicklas Karlsson <nickarls(a)gmail.com>
Subject: Re: [weld-dev] A ConversationManager API
To: "Weld-Dev" <weld-dev(a)lists.jboss.org>, william.drai(a)graniteds.org,
henrichen(a)zkoss.org
Date: Monday, February 1, 2010, 8:35 AM
Let's try it the other way around. I
toss you the minimal JSF-centric API and the framework
reps of ZK, GraniteDS, SE and Remoting can speak up on what
they need more control of along with their usecase then
Pete can comment and I just act as a secretary ;-) That way
we don't end up with too many "nice to haves"
in the API that could be worked around more or less easy.
public interface ConversationManager
{
/**
* Checks the state of the conversation context
*
* @return true if the conversation context is active,
false otherwise
*/
public abstract boolean isContextActive();
// usecase: the conversation checks for active context
before running methods
/**
* Activates the conversation context
*
* @return The conversation manager
*
* @throws IllegalStateException if the context is
already active
*/
public abstract ConversationManager activateContext();
// usecase: any non-JSF framework will want to run this
themselves
/**
* Deactivates the conversation context
*
* @return The conversation manager
*
* @throws IllegalStateException if the context is
already deactive
*/
public abstract ConversationManager
deactivateContext();
// usecase: any non-JSF framework will want to run this
themselves
/**
* Resumes a long running conversation. If the cid is
null, nothing is done and the current
* transient conversation is resumed
*
*
* @param cid The conversation id to restore
* @return The conversation manager
* @throws NonexistentConversationException If the
non-transient conversation is not known
* @throws BusyConversationException If the
conversation is locked and not released while waiting
* @throws IllegalStateException if the conversation
context is not active
*/
public abstract ConversationManager
beginOrRestoreConversation(String cid);
// usecase: start of the conversation lifecycle.
/**
* Destroys the current conversation if it's
transient. Stores it for conversation
* propagation if it's non-transient
*
* @return
* @throws IllegalStateException if the conversation
context is not active
*/
public abstract ConversationManager
cleanupConversation();
// usecase: end of the conversation lifecycle.
/**
* Gets the current non-transient conversations
*
* @return The conversations mapped by id
* @throws IllegalStateException if the conversation
context is not active
*/
public abstract Map<String, Conversation>
getConversations();
// usecase: Conversation checks if begin(String) was called
with a known cid (no need for a isCidInUse, actually)
/**
* Returns a new, session-unique conversation ID
*
* @return The conversation id
* @throws IllegalStateException if the conversation
context is not active
*/
public abstract String generateConversationId();
// usecase: Conversation gets a cid for begin()
Notice that the begin and end of lifecycle are big chunks.
Speak up where you need more granularity. Also speak up if
you want fancy switching stuff etc ;-) Re-submit any
wishes/suggestions you've done in the past in this
thread (method signature + usecase) so we can keep stuff
together.
---
Nik
-----Inline Attachment Follows-----
_______________________________________________
weld-dev mailing list
weld-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev