At 8:13 PM -0800 2/14/06, Paul Benedict wrote:
>> But I noticed the ActionContext is mainly for the request
processor and looks like it contains
TOO much data that would never be exposed to an action class to use.
I may have misunderstood but I'd like for someone to clarify.....
I find it very strange that the ActionContext would allow a command
to *set* the action,
cancelled, exception, form valid, forward config, messages
resources, and module config. As I said
before, these are all controller related issues. Is it the intention
of the Struts commiters to
make a Command something like a new Action that should be used
instead? Or are you expecting
commands to be created solely for the request processor chain?
As a matter of fact, yes. The ActionContext was designed
specifically so that something in possession of one could do
everything that a Struts Action class could do. There's nothing you
can do with an ActionContext that you couldn't do in Struts 1.2.x
without the chain if you knew where it was to be done.
More generally, the Context in the chain pattern is the common space
through which commands can interact. Without it, you can't
effectively decompose behavior because no command can have any way of
knowing what else has happened before. The ActionContext class just
implements java methods in preferences to using keys in a map. This
both makes the code more readable and makes it easier to actually put
the values in request or session scope, maintaining backwards
compatibility with things which look there for values instead of
through the ActionContext.
I find it very strange that the ActionContext would allow a command
to *set* the action,
cancelled, exception, form valid, forward config, messages
resources, and module config. As I said
before, these are all controller related issues.
Why is this strange? The commands are controller related -- they are
components of the controller.
If it is the second, then I stand by my suggestion that
ActionContext should be renamed to reserve
the name (ProcessorActionContext?) for the day when you want actions
to receive an ActionContext
like WebWork. It just contains too many internal properties you
don't want a client to be able to
mess around with.
I think lots of Struts 1.x will not make a direct transition to
Struts 2.x. I don't think we necessarily have to worry that much
about this potential overlap. That said, I wouldn't veto a change
if other committers agree strongly with Paul.
Joe
--
Joe Germuska
[EMAIL PROTECTED] * http://blog.germuska.com
"You really can't burn anything out by trying something new, and
even if you can burn it out, it can be fixed. Try something new."
-- Robert Moog
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
