Thanks to a comment from Jason Carreira made on my “post(Thoughts on an MVC framework for Swing)”:http://www.magpiebrain.com/archives/000178.html, I was pointed in the direction of XWork. XWork is a view agnostic command pattern framework, originally developed as the core of “WebWork 2”:http://wiki.opensymphony.com/space/WebWork2.
XWork is a little different to my design – here actions are not the thing that does something, they signify the intention to do something. Additionally actions can be intercepted by Interceptors before being run.
Components are not fully de-coupled from the framework itself – when writing your own Action for example you have to subclass the Action interface. There is also no concept of a view as such within XWork – this is left to specific uses of XWork (such as WebWork). In general XWork seems close to my suggested design, but not as flexible. It would probably benefit from being reworked to use a more fully featured IoC engine internally (such as Spring or Pico) which would then allow coupling to the framework to be removed. That said its highly unlikely I would ever be able to develop something as fully featured as XWork on my own. I’ll have a play tonight and see whats involved in getting a simple Swing interface to use XWork – that will be a proper test of just how flexible it can be.
magpiebrain 
2 Responses to “XWork for Swing?”
As it says here ( http://wiki.opensymphony.com/space/Struts vs. WebWork ) you
only have to implement the Action interface, so your actions are nearly,
but not quite unaware of their container.
The PicoContainer usage has already been done ( http://wiki.opensymphony.com/space/PicoContainer Integration ), try
to use this instead of the FooBarAware IoC stuff they started with.
Be interested to see how you get on with Swingifying it all…
jez.
The integration examples for both Spring and Pico cover integration with WebWork 1.4, but not 2 or with XWork itself. I think I’ll run before I can walk – get Swing using WorkX (assuming I can get it built – the build seems a little groked right now) as a command framework interfacing with a Spring powered IoC Layer. Then I’ll look at interating Spring into XWork proper. I would hazard a guess that XWork’s existing IoC capabilities (it is after all a form of IoC frameowkr itself) could be completely replaced behind the scenes with either Pico or Spring. I guess Pico would be the favorite given the size, but Spring is more mature, has better support and better docs…