I also think it is much better 1) just let frameworks (Shale, Seam, ...) handle the conversation scope.
or 2) use ADF like Bean Managment in MyFaces I mean using some thing like: <*managed-bean-scope*>*process*</*managed-bean-scope*> looks much more natural way to use another scope, for JSF developers than defining some scopes in faces-config and some others using tags. also since Trinidad is under MyFaces umbrella may be just generalize their approach using best techniques in ADF, shale, seam. On 12/19/06, Craig McClanahan <[EMAIL PROTECTED]> wrote:
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/
-- Arash Rajaeeyan
