On Wed, 27 Oct 2004 00:20:13 -0400, Thomas L Roche <[EMAIL PROTECTED]> wrote: > Just wondering: how does Shale relate to struts-chain? E.g. > > * Would Shale subsume struts-chain? >
It would likely subsume *struts*-chain, but not *commons*-chain (see below). > * Is struts-chain for 1.x and Shale for 2.x? Struts-chain is primarily for Struts 1.x, giving us an alternative way to compose the request processor. Shale is a proposal for an overall architecture of Struts 2.x. However, the underlying commons chain functionality makes a reasonable way to express composable chains of behavior -- and can be used at a number of different levels. And, given a well defined configuration file format, chains should be able to support a pretty nice design time experience. * In either architecture, a chain could be used to compose the application logic used to process, say, a form submit. You could compose a chain, for example, that allocated a data source, then did some business logic level validation, then performed the actual transaction. Or, it could go invoke a remote web service, or interact with a BPEL workflow. This kind of chain would be built from small reusable parts that are easily unit tested in isolation. * In Shale, there's likely to be one or more servlet filters involved in providing the functionality slated for the "application controller" layer. It would be easier to configure (especially if you're creating your web.xml file by hand) to have only one filter for all of Struts, and then use composition to define the steps that take place at the beginning and end of each requst innovation. * In Shale, the same thing could be architected in the implementation of pretty much any event handler where you might want to do more than one thing, allowing applications to add speciaized processing before or after the standard steps. That being said, nothing in Shale's proposed architecture *requires* the use of a chain for this type of thing. It might also be that the required functionality is composed though some IoC container, or a workflow engine, or whatever else you want to use. > > We're planning the next rev of tooling, so I'm wondering which > (moving) target(s) to try to hit, and when ... You're not the only one trying to make that determination :-). However, it's definitely too early to make very many plans around Shale, which still has to make its case with the rest of the Struts developers before it's anything other than a brainstorm. Over the next while, I'll be filling in some of the details with prototype code that should help us make that determination. > TIA, Tom Roche, IBM Rational Developer Model2 Tooling Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
