> Patrick Lightbody wrote:
> > Just a reply to all the comments on Joe's blog...
> >
> > The *Aware stuff is coming back in a big way in XWork/WebWork 2.0. It's
part
> > of the Inversion of Control and Component-oriented approach that
actually
> > turns out to be very nice. I was originally an advocate of deprecating
the
> > Aware interfaces in WebWork 1.x, but I've seen my ways now.
>
> Care to elaborate? I thought we agreed to remove these, and for good
> reasons.

Basically, Joe Walnes got me hooked on the idea and it's now part of XWork
in the form of the ComponentManager stuff.

Basically, the idea is that an external service should manage resources and
components. It's called Inversion of Control, and what the end result is
that instead of your action code actively going out and getting a resource
or component, the container (XWork) passively pushes the resource (via
setXxx methods) to the action or any other object.

Example: Imagine your action code needed a Connection object. Typically your
code would use JNDI to look up a DataSource, get a Connection, use the
connection, then close the Connection. Of those four steps, only one of them
is unique to that action and is part of the requirements for why you coded
the thing in the first place ("use the connection"). The rest is accessory
stuff to enable the "use the connection" part. Using XWork's simple IoC
framework (Avalon and JBoss4 will both probably take this much further),
your action could be as simple as:

public MyAction implements Action, ConnectionAware {
 Connection conn;

 public void setConnection(Connection conn) {
  this.conn = conn;
 }

 public String execute() throws Exception {
  // do stuff with the connection, no need to close it
  return SUCCESS;
 }
}

Then the ConnectionService would have an init() and destroy() method called
by the contianer where it could handle cleanup (such as closing the
connection).

In XWork, resources/services/components can have scope. This is implemented
in WebWork2 where there are listeners for request, session, and application
scope. Imagine how easy a ShoppingCart would be (tag it as session scope and
implement ShoppingCartAware)!

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.

-Pat




-------------------------------------------------------
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

Reply via email to