2) standardize the backing-bean concept (aka ViewController) Technically spoken: We have a PhaseListener which try to lookup a bean using a name derived from the viewId (like shale's ViewController).
then what will happen to users who use Seam or future WebBean with MyFaces? as you may know seam also has its own phase listener and bean managment facility. can seam users also continue using myfaces? (seam has its own conversation mechanism, http://docs.jboss.com/seam/1.1GA/reference/en/html/conversations.html) will nested conversations also be allowed? On 12/19/06, Mario Ivankovits <[EMAIL PROTECTED]> wrote:
Hi! Our plan was to implicit start a conversation as soon as a conversation been will be created through spring. Well, to know which conversationContext we are currently working in (this context is required for "multiple window" awareness) we have to add a request parameter to every rendered url. This already works pretty well, BUT one has to ensure that the s:startConversation tag is the very first on a page using conversations to allow the system to configure itself appropriate so that the url parameter will be appended. At least, the s:startConversation has to be before e.g. the form stuff. Now, with implicit started conversations this is not that easy any more. I see two solutions: 1) still support the startConversation (in addition to the implicit started one for sure). In fact I'll keep backward compatibility anyway, so this will happen anyway. 2) standardize the backing-bean concept (aka ViewController) Technically spoken: We have a PhaseListener which try to lookup a bean using a name derived from the viewId (like shale's ViewController). If this bean is in conversation scope (or one of its injected properties if you have request scoped backing-beans - like me ;-) ) this would have started a conversation then and the system is fine again. What do you think, would someone see such a standardization as a bad thing? IMHO having such a view controller concept would help much (not only for conversations), e.g. we too can have those "prerender" methods etc we often would like to have. Ciao, Mario
-- Arash Rajaeeyan
