On 2/19/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote: > > On 2/19/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > > Anyone can quote chapter and verse from the GoF book. Can you instead > > explain *why* what's in Struts isn't CoR? And, perhaps more > > importantly, explain why, even if it isn't an exact match for the > > pattern, it matters one bit? > > By the way, is Struts CoR actually a CoR? This is not a trick > question, I am just asking. > > If I understand correctly, in CoR pattern a client calls the chain > head and "the request propagates along the chain until a > ConcreteHandler object takes responsibility for handling it." (GoF)
That's the most important sentence in the GoF description ... and the one that motivated the API design for a Comman in Commons Chain. In Struts Classic prior to 1.3 a client calls a concrete action (which > is why I consider Struts Classic to *not* be an implementation of > Front Controller pattern). Almost, but not quite ... there was always processng going on before and after the call to the action, and you couldn't bypass it except where Struts allowed you to explictly configure bypassing it (like turning off validation). For someone who doesn't use form beans (like you, Michael? :-) there isn't a lot actually done there, but it does exist. It is possible to stick additional > processing before the action class is called. Though it is not as easy > as in WebWork, it is possible. So, Struts Classic implements > Interceptor pattern, not Chain of Responsibility. The standard versions of Struts before 1.3 indeed do not use CoR (although you could use a CoR based implementation of RequestProcessor from the sandbox in 1.2.x). So, how the whole thing works in 1.3? A client still calls a > particular mapping like in older Struts versions, right? Does this > mapping define a head of chain (CoR) or an end of chain > (interceptors)? If it defines the head of chain, is it still possible > to sneak interceptors into an arbitrary chain? The primary change in 1.3 is to re-implement the standard request processor pipeline as a chain instead of a monolithic single class (in other words, promoting the sandbox CoR implementation into the mainstream). So, the use of a chain is just an *implementation detail* that does not change the "Front Controller" nature of the original framework. But it's now much easier to customize the framework's behavior for all requests, by adjusting the definition of the standard chain and/or utilizing optional call-outs to applicaton defined chains. The next step would be to provide customizable chains per Action (becoming even more like how you configure actions in WebWork) -- but you can even do that today by using an Action that itself executed a chain. Michael. Craig
