<SNIP> On Wed, 16 Mar 2005 08:01:41 -0500, Ted Husted <[EMAIL PROTECTED]> wrote: > On Tue, 15 Mar 2005 20:22:34 -0800, Dakota Jack <[EMAIL PROTECTED]> wrote: > > The idea, I thought, was to use the Commands to supplant the > > RequestProcessor with a composable request processor. > Refactoring the RequestProcessor for CoR is about extending the > request processing cycle. It's been a straight-line refactoring since > the beginning. I don't believe anyone is trying to follow a particular > pattern. We are just trying to provide a flexible approach extending > the request processing cycle. </SNIP>
YAHOO! Good news! There is organization after all! LOL This IS good news. <SNIP> > The idea behind CoR and Struts Chain is to solve both of these problem: > > * A flexible processing layer for business applications > * An extensible request processor for Struts </SNIP> Great, so long as discussions that want to merge them are discouraged by the team. <SNIP> > The refactoring of the request processor is a proof-of-concept for > CoR. The request processing gauntlet is the "business logic" of the > Struts framework. It's also a hoary example of some very nasty > business logic. IMHO, if we can do the Struts request processor in > CoR, we can do anything in CoR :) </SNIP> I think that CoR is just another pattern that does what it does. I don't think that it is a particularly helpful pattern for business logic in general. One thing I dislike about the pattern is that it encourages people to think in procedural processing terms. There is a real difficulty getting people into the OOP mindset. I like to think of calling objects/classes/interfaces as more like a very organized "go to" command in procedural processing. In C, and like languages, those who used "go to" extensively were the best programmers with the best logic but the code stank and caused way too many problems to encourage because no one could read it. Objects, among other things, solve this very important problem. Command/Chain sort of does the opposite, if you are not careful, and encourages bad code to keep things simple. <SNIP> > Yes, Struts Chain is a challenging application for CoR, and the > implementation is not as slick as we might like. But, challenge is a > good thing. And, I'm sure as more of us gain experience using CoR in > other contexts, we'll devise more elegant solutions. The great thing > about CoR is that it's easy to refactor. </SNIP> The great thing about CoR is that it allows a class to pass on a process without knowing what object will handle the logic down the line. This means, of course, that it is decoupled and, so, very extensible in context, which is what, I think, Ted is saying. <SNIP> > I'm using CoR in my own applications, and it's working quite well. I > hope to start reapplying some of that experience to Struts Chain, and > I'm sure others will too. </SNIP> Use all the patterns, as needed, I would suggested. Also, use CoR where needed. Jack -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
