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.
One of the architectural approaches that MyFaces developers seem to do pretty often, even when they don't have to, is think of everything as needing a component. To me, this involves the person building the view in decisions that really belong to the person working on the business logic. Yes, it's often the same person, but where is the separation of concerns? Given that statement to show my biases :-), there are two aspects of the way that Shale's dialog manager deals with these issues that you might want to take a look at: * Dialog instances can be started programmatically, or by looking for a special prefix on the logical outcome returned by an action. Nothing at all needs to be placed in the page itself for this to work ... and a particular page can be reused inside or outside a dialog. * Instead of explicitly modifying the URL (as described above), or adding a custom HTTP header (as Seam used to do ... don't know what 1.1 does at the moment), the dialog identifier (and any other related stuff) is stored as a generic attribute on the view root component. Typically this will be stored (for a Shale app) in the prerender() method ... the corresponding generic way would be a "before render response" event handler in a phase listener. The latter approach has an advantage in that you can pass any sort of state that is serializable (and therefore get <t:saveState> out of your pages too! :-), and a disadvantage that it doesn't react well to the redirect-after-post pattern. But it is worth taking a look at. Ciao,
Mario
Craig
