All I need to do in my actions is define the mapping from action properties to spring bean names like this :
<action name="listAccounts" class="project.controller.ListAccounts">
...
<interceptor-ref name="springComponent">
<param name="mapping">
accountsDao=accountsDao
</param>
</interceptor-ref>
...
</action>Another way to do this is to use the same enabler interfaces that xwork provides for its own IoC, though this has a drawback that you can't have two instances of the same class of component.
There is functionality in Spring to get a bean by class name. Which could be used to obtain the component, and use the setter defined in the enabler.
I guess requirements dictate the type of system you need.
Currently we are using the Session Facade pattern to place all business logic in a separate layer, the actions delegate to this layer.
This worked well in the WebWork1 days since these actions were really tied to the web layer.
Now that WebWork2 and Xwork have separated the action framework from the web, I am investigating using xwork actions as my business layer using the command pattern, and only using delegation to helper and dao classes where it makes sense to. (i.e. for re-use or testability)
Therefore to implement this strategy, I need to be able to use method interceptors to provide transaction management. Currently with Xwork, an interceptor not only wraps the execute() call, but also the execution of the result (which may be chained actions or a view). This isn't sufficient for me when dealing with a transaction. I need it to start immediately before execute() and commit or rollback immediately after. Hence the move to Spring AOP transaction management.
All that I need to do to is register by action within spring using the namespace and name.
<bean name="/admin/accounts/list" class="com.datacodex.xwork-spring.ActionFactoryBean">
<!-- interceptor definition here or any other spring component refs -->
</bean>
Then by replacing the Xwork ActionInvocation and ActionProxyFactory I am able to automate the call to spring getBean() using the /namespace/actionname string to see if spring has a factory defined for this action, and if not, create a normal, non proxied instance.
I have this working.
Some other benefits of this technique
* you can wire your actions to any spring component using the normal spring bean reference technique
* actions can be autowired (when spring developers complete this) by name or type
Some things that I would like to investigate further :
* using an action as a component for another spring bean
* possibly by using a spring interceptor that invokes the xwork ActionInvocation after getting xwork to finish the action initialization phase
* dynamically wrapping action getters in aop proxies that implement a view interface to separate the model from the view and to provide a readonly interface
* I have a lot of the support code already done for this
Sorry that I strayed from the core topic.. I have had these ideas running around in my head for a little while. I think I needed to perform a brain dump to get them down, and to get other people involved in discussion :)
Cameron.
James Cook wrote:
I had thought the components.xml file would be a natural integration point for Spring factory beans. To this end, I have written my own WebWork enabler interface and exposed our Spring factories this way. It seems lighter weight and a more natural WebWork integration point than coupling the web-tier and the Spring Framework than creating new dispatchers/interceptors.
Any thoughts?
P.S.: In my component, I access the factory bean using this type of construct:
WebApplicationContext appContext = WebApplicationContextUtils.getWebApplicationContext( ServletActionContext.getServletContext()); (IntranetSession) appContext.getBean("nameOfSpringFactoryBean");
It doesn't give me any gee-whiz XML configurable component, but the components.xml file should be made to allow parameters in the <class> tag at some point. If this is done, then this approach gets more dynamic.
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
_______________________________________________
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
-- Any damn fool can write code that a computer can understand... The trick is to write code that humans can understand. [Martin Fowler http://www.martinfowler.com/distributedComputing/refactoring.pdf]
------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
