Ryan's Scraps

The MVC design pattern is widely recognized as the preferred patter for developing UI-type applications, whether they be web applications or

more traditional client applications. While there are an abundance of widely accepted and quite mature MVC web frameworks, there are very

few for Swing applications. I believe this is because Swing does a good job of solving the “M” and the “V” portions of “MVC”, while leaving the “C” portion open.

Swing provides native support for using models, having a rich set of model interfaces and abstract classes for most of their UI components; I.e.

TableModel, TreeModel etc… Views are defined by the rich ui components that are driven by these models. It is when tying together the

interactions between the models and views (the controller portion) that Swing’s paradigm falls apart. Swing’s event/listener model is what can be

considered the controller part of the MVC, but is much too diffucult to maintain is it manifests itself as a graph of events and actions to listeners.

Thus Swing’s native controller is an unmaintainable myriad of event to listener to bound object relationships:

So while it’s clear that there is control logic, it’s all seperated between various listeners that are responsible for which bound objects to manipulate

upon which events. In addition, when forming these listener to event relationships you have to have a way to retrieve the reference to the actual

object you need to add the listener to. The same goes for getting the references to the bound objects that the listeners will need to manipulate.

What results is that you have to expose every object that wants to be a part of this system of events and listeners, independent of whether or not

it’s good design to expose these objects.

The first step to solving this problem is to consolidate the control logic into a more respectable, singular controller entity:

Instead of maintaining seperate listeners for every event, the controller has exposed methods to capture all system events and perform the

necessary response actions to the bound objects. While this consolidates the control logic, and forms a controller entity, it still does not clean up the

relationships between objects or the need to expose every object that needs to be part of this eco-system. I.e. the controller still must know of every

event and every bound object. What we need is a way for each event to log the event to a registry, and for each bound object to specify which

events they want to be notified of. Going even one step further, we need a more generic way for the bound objects to specify which events they

want to be notified of and not to refer directly to the event. This sounds a lot like the bus paradigm to me.

When an event occurs the object firing the event places an event message on the event bus. Any object that wishes to respond to an event can register itself with the event bus to be notified on the applicable events:

In this model, none of the events need to know anything about the bound objects and none of the bound objects need to know about the events.

And instead of having one big conglomeration of event/object bindings in the form of a controller, we can allow the bus to marshal event messages

to any object that cares about them. This offers the perfect seperation of logic without sacrificing flexibility.

In code I imagine this event model will manifest itself like so;

<i>Event firing object</i>
public void onEvent1() {
    EventBus.placeEvent(new Event("event1", this.eventContext));
}

<i>Event receiving object</i>
public void handleEvent(String eventId, EventContext context) {
    if(eventId == "event1") {
        aTextField.value = context.getProperty("userId");
    }
}

Thinking even further of the type of configuration and enhancements that could be applied here:

• Events can be further organized by a heirarchical set of topics. So an event could be send on the “ui.mouse.movement” topic with an id of

  “panelHover”. Any bound object that has registered itself to listen to the “ui.mouse” topic would get notification of this event. This would make

  things like logging and other such wide-area functionality very basic to implement. The logging object would just register itself for the root or all

  (”*”) topic to receive notification of every event.
• Using such frameworks as spring, or even utilizing aspect-oriented-programming, we can fully wire events to event bus to listening objects

  using an external XML configuration file. For instance, we can say which events are sent to which topics, and can then specify which objects

  listen to events of which topics. We can even specify which methods to execute when a particular event is received.

  <events>
      <event objectClass="com.ryandaigle.ui.MyButton" 
  eventClass="java.awt.ActionEvent" topic="ui.button" />
  </events>
  <receivers>
      <receiver-ref id="logger">
          <subscribeTopic id="ui.*" />
      </receiver-ref>
  </receivers>
  

  Now granted there is a lot here that I haven’t solved yet, but you get the idea.

I haven’t had a chance to look at how to maximize XWork in Swing, although

I’ve heard some rumblings about it recently. I’ve also been intrigued with Spring’s spring-rcf but have yet to see any code or documention for it.

My hope is that one of these two, or the combination thereof will implement a decoupled event bus-like model. It just seems to be the prefect model

for Swing/Java UI applications.