On 12/8/05, Joe Germuska <[EMAIL PROTECTED]> wrote: > > At 6:26 PM -0700 12/8/05, Wendy Smoak wrote: > >I need help with Commons Chain and Struts in combination. I've read > >the Commons Chain docs, including the cookbook, which uses a > >CommandAction in the Chain version of mailreader. > > > >Then in Extras we have ChainAction and DispatchChainAction. I assume > >I'm supposed to use one of those instead of including a special Action > >in my webapp. > > > I suppose you could just use the "command" (and optionally "catalog") > attribute of the action mapping and not specify any "type." (Yet > another way to do it!)
That's what we (at my day job) would be using if we were on 1.3.x. Since we're on 1.2.8, though, we use ChainAction to get (almost) the same effect. It worries some people that ChainAction is in a "legacy" package, and there are issues with non-default catalogs, but for the most part it works very well. If you're using a Chain action, then why would you want dispatch > also? Are you talking about dispatching to a chain, instead of > dispatching to a method by reflection? If that's the case, you could > do it using the commons-chain Lookup Command, although it might be > more elegant with a command that could use an expression to determine > the name of the chain to which to dispatch. (I know there's an > outstanding patch for adding expression evaluation to commons-chain, > but I'm still waffling on the implementation (especially if Struts Ti > is going to preference OGNL to JEXL, which has been my expression > language of choice, but more because I just don't have time to > implement patches with proper care right now...) > > For me, I haven't come up with any very compelling use cases for > chaining action logic together. Somehow there never seems to be that > much reusability. I guess some of the stuff that I'm pushing back > into the "model" and using chains for is stuff that could be done at > the controller layer in a lighter model, but I have specific use > cases for triggering the behavior both from the webapp and from other > processes. > > In any case, I wouldn't be surprised if there isn't some cleaning up > to be done in this area -- not a lot of people have set out to use > chains and commands instead of actions, so there aren't a lot of > "best practices" just yet. You get to discover them! We don't have any of our own Action classes in the main app that's under heavy development right now. It's all chains and commands. Most of our action mappings correspond to a chain of two commands, where the first deals with the incoming request and the second deals with preparing for the response. In some cases, we have chunks of prep work that are reused across multiple response types, so we break those out into additional commands. We had some initial pain when we got ourselves into an "everything is a command" mentality, leading to common commands showing up in almost every chain, but we recovered from that. ;-) We made minor changes to the request processor chain, mainly for error handling and Tiles (and the combination), but otherwise it's been pretty painless. It's interesting to compare this approach with what we did at my last company, before we had this handy dandy chain doodad to play with. There, I created a request handler / display handler dual that was similar in effect to what I described above. In some ways, Chain saved me from having to recreate that. On the other hand, the way chains handle context makes them sometimes too flexible, making code reviews more important when the compiler isn't doing the design checking for you. ;-) -- Martin Cooper Joe > > -- > Joe Germuska > [EMAIL PROTECTED] > http://blog.germuska.com > "Narrow minds are weapons made for mass destruction" -The Ex > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
