Swing GUI API's and custo
To: comp.lang.java.gui
Hello!
I'm currently wading through figuring out what to use for using MVC my
application. I really need to explain the setup I currently use so you
get a clue what I'm talking about and what I'm looking for (it's hard
to describe my motivation without it). What follows is not hard to
read, but a little lengthy for the actual questions I have. You might
as well skip it and go to the end of this posting, though not
recommended (of course ;-) )...
The first thing I implemented was a java.util.Observable style
framework which *used Observer adapters* to be attached to the
Observables so I can define custom observer interfaces like
public interface SelectionObserver extends GenericObserver
{
public void update(Selection s);
}
public interface EmailConstraintsObserver extends GenericObserver
{
public void update(EmailConstraints ec);
}
to work with java.util.Observable.
An adapter will *always* look like this (replace Selection with any
*concrete model* class name -> POJO):
public class SelectionObserverAdapter implements java.util.Observer
{
private SelectionObserver so;
public SelectionObserverUpdateAdapter(SelectionObserver so)
{
this.so = so;
}
public final void update(Observable obs, Object arg)
{
so.update((Selection)obs);
}
}
Like this, the Observable's notifying method will call the standard
java.util.Observer adapter's update(Observable, Object) method. Then,
given the concrete adapter implementation, a downcast to the concrete
Observable subclass, here Selection (EmailConstraints or any other
custom observable -> POJO's) and the call to the right method on the
object needing the update is performed (invisibly to the user).
The adapter acts as a "multiplexer" so that if an object observes
different Observables by implementing *n* concrete Observer
interfaces, the method of the real type will be called:
public class MultiObserver implements SelectionObserver,
EmailConstraintsObserver, BlaObserver, ...
{
//...
public void update(Selection s)
{
}
public void update(EmailConstraints ec)
{
}
public void update(Bla b)
{
}
}
Using this MVC style involves 5 basic steps:
1. Create the concrete Observable model class:
public Selection extends Observable
{
//... implement the setChanged/notifyObservers policy
}
2. Define a custom observer interface (GenericObserver is just a
tagging interface like Serialzable without any implementation but some
naming convention public static's, explained later):
public interface SelectionObserver extends GenericObserver
{
public void update(Selection s);
}
3. Define an adapter class that will simply contain a downcast and
call to the concrete observer's update method:
public class SelectionObserverAdapter implements Observer
{
//downcast and concrete observer call here
}
4. Have a class implement the concrete interfaces:
public class MultiObserver implements SelectionObserver,
EmailConstraintsObserver, BlaObserver, ...
{
//update method/s here
}
5. Create the instances and connect:
//the view component
SelectionObserver so = new JSelectionRadioButton(...);
//the adapter
SelectionObserverAdapter soa = new SelectionObserverAdapter(so);
//the model (Observable subclass)
Selection s = new Selection(...);
//attach adapter that will forward to the concrete object, here so
s.addObserver(soa)
This is a very complicated setup to use, especially step 3 seemed
"suboptimal".
Analysis:
Step 1: Is needed for every MVC setup I suppose. No loss here.
Step 2: Defining the concrete model's Observer interface. The overhead
usually is minimal because you will likely declare only one method.
Step 3: Creating a new adapter class for each concrete model/observer
class pair is a complete maintenance and usage nightmare (3 classes
per model/view class: Observable model, custom Observer interface,
adapter). Furthermore I need to instantiate the adapter (step 5.2) -
not that nice to use.
Step 4: Implement the concrete Observer's update methods: This is the
nice thing about that MVC setup, whichever Observable this object
observes, the right update method is called without any if then else
and downcast construct that would be needed with the standard
java.util.Observer (and the listener stuff). This is what I like about
this MVC setup and is the main reason I use it. It's soo clean (the
mud is in the adapters ;-) ).
Step 5: Necessary to use it all, step 5.2 creating the adapter is
annoying.
The description above is the version 1 approach, which was nice,
except for the adapter overhead. Then, I came up with *generating all
of the adapter class byte code on the fly*. Using some naming
convention (GenericObserver super interface used to tag custom/generic
Observer interfaces), a somewhat sophisticated algorithm I now manage
to do so. It works *beautifully* (thanks to the Apache BCEL lib).
Now step 3 and 5.2 are completely gone, connecting two instances is
handled by a special method: ObserverTools.attachInstances(Observable,
GenericObserver).
1. Create the concrete Observable model class:
public Selection extends Observable
{
//... implement the setChanged/notifyObservers policy
}
2. Define a custom observer interface:
public interface SelectionObserver extends GenericObserver
{
public void update(Selection s);
}
3. Have a class implement the concrete interfaces:
public class MultiObserver implements SelectionObserver,
EmailConstraintsObserver, BlaObserver, ...
{
//update method/s here
}
4. Create the instances and connect:
//the view component
SelectionObserver so = new JSelectionRadioButton(...);
//the model (Observable subclass)
Selection s = new Selection(...);
//attach instances if compatible (generates the observer adapter/s)
ObserverTools.attachInstances(s, so);
Much better!
Analysis:
Now I step 3 is completely gone and the call to
SelectionObserverAdapter soa = new SelectionObserverAdapter(so); as
well. The magic is hidden in ObserverTools.attachInstances(Observable
obs, GenericObserver go) method, where the Observer instance is
checked for compatibility: the SelectionObserver so has
update(Selection s), so it is compatible with its update method's
first param, that's the basic contract here. If they are compatible,
an adapter class called "some.package.SelectionObserverAdapter" is
generated (using a custom class loader), instantiated with the
observer and then added to the concrete Observables automagically.
That setup is still somewhat complicated to use, however now, it is
equally complicated to use as any other MVC setup. Advantage in use is
there's absolutely no downcast as seen from the programmer's side.
Plain Observable MVC as well as other JavaBeans PropertyChange...
style MVC setups (I've looked at) always involve a downcast in the
update implementation at some point or another. I got so disturbed by
it, I really had to do this observer adapter byte code generation
stuff. All downcasts gone, nice, they're hidden from the API user.
But what does this have to do with the subject?
Answer: I'm kind of stuck with using java.util.Observable... you might
as well ignore the above MVC description of the setup I currently use.
My point here is, I created this setup, it works veery nicely. I'm
just wondering if there are any alternatives that offer more. I don't
want to go out and repeat coding things that already exist. For most
of the things I need, I create POJO model classes. As probably every
serious developer, I really do need some way of handling collections
(lists, sets, maps, sorted/unsorted). I looked at several API's, but
I'm kind of lost.
I looked at JGoodies binding, which seems to be a JavaBeans
(PropertyChange...) style API designed to observe/sync single values
and lists, but it doesn't seem to support JTabbePane's (is this due to
the fact that JTabbedPane doesn't have an own JDK model, but instead
uses SingleSelectionModel?). I looked at other API's, but I can't
really figure out what to use. As stated above, I'd like to have
something that works with JTabbedPane. With a custom/own MVC setup
like the above I can realize that and basically make anything
compatible. I only have to create Observable collections. This also
brought me to the Apache collections and some (out of date) sandbox
project called Events where I found an ObservableCollection,
ObservableList, etc. I dropped that, because I'd like to have support
for generics.
Anyway, I'm a little confused with all the input of the last days/
hours searching the inet and reading API docs. The problem/s I
described are somewhat trivial, I'd like to get some insight on this
topic. I feel especially undecided on making the right choice API-
wise.
I looked at:
JGoodies (binding)
Apache commons: Collections (no generics?) and Event (sandbox,
dormant)
Hitch
Genesis
My tendency currently is to implement Observable collections as needed
(by delegating) to concrete collection instances. I know these won't
be the fastest collections around, but I would use them for list like
structures/models for JTabbedPane (or JList) with an overseeable
number of entries. At some point, I will collide with the/a "lower
level binding" API, as I would with JGoodies binding (JList,
JComboBox, and JTable).
My problem is: I can't really decide about what to use and what not
and why... So if there are any recommendations and suggestions you
have, you are hereby invited to share them with me.
Karsten
PS: Since we're in a discussion group, I'd like to hear some critiques
on the described (custom) approach...
---
* Synchronet * The Whitehouse BBS --- whitehouse.hulds.com --- check it out free usenet!
--- Synchronet 3.15a-Win32 NewsLink 1.92
Time Warp of the Future BBS - telnet://time.synchro.net:24