Replacing Action (was Moving Chain Processor Ahead ...)

[Don Brown <mr...@twdata.org>]

Joe Germuska wrote:

> Where would ActionCommand fit in, more specifically?  Is the idea that 
> you'd rig the chain to use a different command that fills the general 
> role of the current "ExecuteAction" command?  Did you guys come up 
> with more specific APIs for the ActionContext and ViewContext?

The bottom line of these three classes is it replaces Action and, while 
providing a new default ActionCommand interface, opens the door to 
alternative action frameworks.

ActionCommand would look like this:
public interface ActionCommand {
  public void execute(ActionContext ctx);
}

...notice execute() isn't capitalized, mr .net Ted :)  This interface 
could also possibly return ActionForward to fit easier into existing 
Struts concepts.  Any place Action is used now, we would expect an 
implementation of ActionCommand.  The nice thing about chain is we can 
support both side-by-side - simply add a command that checks the action 
with an "instanceof Action", and if not found, it ignores the class, 
letting the second chain command check for "instanceof ActionCommand".

ActionContext is based on code I wrote for a POJO action framework 
extension for Struts a little while back.  It is initialized at the 
start of the chain, receiving the chain Context.  It then stores an 
instance of itself in threadlocal, to be optionally retrieved by 
ActionContext.getCurrentInstance().  It contains all the methods we now 
have in Action like saveToken(), getMessage(), etc., in addition to 
extending Context, so its get() implementation, if the chain context is 
an instance of WebContext, looks for beans with the proper order 
(request, session, application, local).  For the POJO action framework, 
which looked quite like a JSF backing bean, anytime the action needed to 
get Struts or web-specific things, it called the static method to get 
the instance of ActionContext.

Now that I think about it, I'm not sure what ViewContext would contain.  
Ted was thinking it would be based off VelocityTools, but I don't see 
anything there that couldn't be stuck in ActionContext.

Don

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Replacing Action (was Moving Chain Processor Ahead ...)

[Vic <vi...@friendvu.com>]

Don Brown wrote:

> 
> ActionContext is based on code I wrote for a POJO action framework 
> extension for Struts a little while back.  It is initialized at the 
> start of the chain, receiving the chain Context.  It then stores an 
> instance of itself in threadlocal, to be optionally retrieved by 
> ActionContext.getCurrentInstance().  It contains all the methods we now 
> have in Action like saveToken(), getMessage(), etc.

This "educated" Context looks good and this is what I did a year ago, it 
very OO.

I now do not hang method of the Context, becuase they may not be in a 
"web" context.
For example, commands may, or may not need token, messages, etc.

I like plain Context, just plain Chain context.

If some commands use it in diferent context;
depending on the context of course, w/ pun.

This way I can start puting in my values that come from browser in 
version 1 of my app.

Then... in version 2, I put in something else, and my action code and 
dispatcher still works.
Imagine an XML you pass to the action, and return XML. (XML is just 
name/value pairs).

If there is a clever way to make the app work in both cases. I think if 
action takes a VO (w/ no real methods).
Same action could service 2 diferent contexts (without instanceOf, yuck)

.V


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org