Even more, services can depend on other services, so you can create very large resource dependencies such that each resource is small by itself, but can be used to form large building blocks. XWork examines the dependency graph and correclty loads resources in the correct order using a simple depth-first search on the graph. Even more, the container can be used outside of XWork and applied in other situations, such as OSWorkflow. In my application at Cisco, I've got FunctionProviders (an OSWF thing) that implement the same Aware interfaces that my Actions do, and both get access to the same resource.
OK, did that sell anyone? The end result is SUPER simplified code that is much better suited for unit testing (think: action.setConnection(mockConnection)) and only focuses on requirements and doesn't worry about any "glue", since the container handles all that.
What are the drawbacks of this approach?
/Rickard
-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com
_______________________________________________
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
