On 12/19/06, Mario Ivankovits <[EMAIL PROTECTED]> wrote:
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.
If you haven't looked at Shale Dialog lately (last couple of months), it has been substantially enhanced -- it might suit your needs directly. A couple of interesting tidbits: * Totally independent of view controller (although it works fine in conjunction with view controller if you want) * Separated API and implementation -- currently two implementations available (a "basic" one much like the original but with lots of bugfixes, and one based on Jakarta Commons SCXML). An implementation that integrates directly with Spring's conversation stuff (but still used the same APIs) would be interesting to take a look at.
* 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 ...
Indeed, I should have mentioned that Shale Dialog does support a mixed case, where you *can* start a conversation using a request parameter. That turned out to be useful when you wanted a popup dialog to have its own context, independent of the one for the parent window or frame. The docs[1] are reasonably up to date, plus there are some sample and test apps for both dialog implementations. Thanks alot!
Ciao, Mario
Craig [1] http://shale.apache.org/shale-dialog/
