Hi Craig! > 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. Hehe, yes indeed. But I'll try to move away from such approaches, the Spring Conversation integration should no longer need them, even if supported.
> * Dialog instances can be started programmatically Yes, thats easy. > or > by looking for a special prefix on the logical outcome > returned by an action. Thats something we have to take a look at, though, we don't want to build a full featured dialog framework. Lets go small steps, maybe spring-webflow fits in there, but for sure shale-dialog will have its place here too. > * Instead of explicitly modifying the URL </snip> > ... the dialog identifier > (and any other related stuff) is stored as a generic attribute > on the view root component. Hey, this one is interesting, I'll give it a try. > 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. The advantage of the url-parameter method is to allow to easily render links WITHOUT the conversationContext attribute and thus a new conversation context will be started. Maybe a mix of both strategies will be fine ... Thanks alot! Ciao, Mario