I tried to logically trace the flow within the framework and wanted to
check if my thoughts are correct here, while at the same time asking a
few more questions:

As a start I take DefaultActionProxyFactory. DefaultActionProxyFactory
instantiates DefaultActionProxy, but also gives us
DefaultActionInvocation via its createActionProxy methods, using the
"new" operator.

The DefaultActionProxy constructor takes ActionInvocation as parameter
and sets the ActionInvocation interface field by means of a
DefaultActionInvocation implementation.

Next, DefaultActionInvocation takes extraContext and a boolean as
constructor params. It also has a reference to the ActionProxy which I
believe sets via its init method?

DefaultActionInvocation also creates the actions with its
createAction(Map<String, Object> contextMap) method, letting an
objectFactory take care of the actual creation with information taken
from the ActionProxy (like action name, name space, config, etc).

Then DefaultActionInvocation also invokes the action by calling
invokeAction(action, actionConfig).

This is more to help me understand the basic workflow at a higher
level at first. Are my above statements correct?

One thing that I find confusing (at this time) is the use of so many
"contexts": extraContext, actionContext, invocationContext, etc. What
is the primary use of the context? Is it similar to the configuration
object?

I still have as a short term objective to unit test my
intercept(actionInvocation) method of my custom Interceptor, but is it
true to assume that to prepare for the test I'd probably need to
create a lot of dependencies manually? i.e. Create mock objects all
the way deep to DefaultActionProxyFactory?

Many thanks again for your help.




On Thu, Jul 23, 2009 at 5:37 PM, Dave Newton<newton.d...@yahoo.com> wrote:
> Dimitrios Christodoulakis wrote:
>>
>> By the way I noticed that when I downloaded the s2 source code, it
>> didn't come with the opensymphony packages... Does the xwork source
>> has to be downloaded separately?
>
> Yes.
>
> Dave
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
> For additional commands, e-mail: user-h...@struts.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org

Reply via email to