I might be biased too from the Seam side, but writing this, even in small steps may grow into a monster :-) I can see committing to only an implicit flash scope (90% of the cases-- and very useful), but pursuing full conversation management and transactions without an actual separate project may be a little much under the myfaces umbrella when you have Shale, Seam, ADF (processScope), etc out there.
just 2 cents from an outsider ;-) >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 >
