On 2/16/06, Paul Benedict <[EMAIL PROTECTED]> wrote: > > Martin, you may have to reel back to my first email about this. The > context exposes so much of the > Struts internal data that it is obvious, to me, that it's not supposed to > be an end point > processing. What good is having the end point changing the action servlet? > Probably no good which > is why I am making the case there probably needs to be 2 action contexts. > One for the RP, another > for the end point. Right now ActionContext exposes toooooooooo much, in my > opinion, for a public API.
It's not surprising that this pattern creates a bit of cognitive dissonance :-), since it is *so* different from the object oriented design approach of exposing rigidly controlled interfaces that only "allow" clients to do the things you think they need. The problem, when you are trying to support a notion of assembling functionality out of very finely grained processing units, is that it's *very* hard to predict what the actual clients will really want/need to be able to do. The other thing to note is that essentially everything visible through ActionContext is also visible to the execute() method of an Struts 1.0/1.1/1.2 Action ... it's just a heck of a lot easier to get at :-). Craig
