# 4 References

What follows in this section are references to FrameWorks and MVC that I have collected from the Web and commented about. Each reference has a bit of rambling I did when trying to understand what the papers meant, and as such are biased towards what I think is right.

Mukul Sood: What is Swing

> Made some interesting points about the JTable. The JTable is a form generator based on a model. You specify if the property is editable, if it's a boolean, etc, and the JTable knows how to render it - as an editbox or as a label, as a checkbox, etc. You can register handlers for each of the types (editbox or a custom edit widget for editable properties, for instance).

> I wonder how it handles OptionMenu, but it does seem to. :)

> In Kiwi part of this is taken care of by CList, but there are some differences. First, the CList widget is rather limited, so you can't have checkboxes or editables in it (which is what the ListView *does* allow in GTK2) - it just takes the model and

> There is a major difference in how Swing handles the Model. In Kiwi the Model is the domain object proper, because the UI is specified independently. In Swing (and in the GTK2 ListModel, too), there is a Model that the UI is based upon, and your domain Model. In a sense, the Glade file is what makes us avoid specifying the UI Model in Kiwi, since the UI elements are already taken care of.

> In the example in this article, there is an AppMain class that is what is created when the app runs. The AppMain creates an AppController which takes care of initializing the Model and View. The View, however, holds the JTable, which in itself is a Delegate! This means part of the signals are treated internally by the JTable delegate, and a part by the AppController ("The mouse handler is implemented in AppController"). I don't know if I like this too much.

Sachin Deshpande: MVC Architecture

> Covers MVC and Swing together.

> As always the famous multiple view example uses a table and chart view of the same data. Finding the same example over and over is a bit boring and it makes me think that spreadsheets are the only purpose of supporting multiple views. It also says that you can modify views without changing the model - sure, you can, but why would you *want* to? The view represents the model - it will *usually* change when the model changes anyway.

> It does point out that Swing offers two kinds of models: GUI state models and Application-data models. The nice part here is realizing that the first are very low-level - they hold the data for the button (which in GTK+ is internal to the widget - a checkbutton's 'state', for instance) and the second, a bit more application-level. I'm not sure how the second would map to domain attributes yet though.

> Interesting point: the Model offers two forms of notification. A light-weight form, which just informs "changed", and a complete one, which provides an event object that describes what changed.

> Swing also has something called a Renderer. I have no idea what it is used for - custom cells in tables and lists?

David Marshall: HCI Handout

> Material for an HCI course that covers Swing, and has a bit or two on MVC. It reminds us that in Swing, View + Controller is called "UI Delegate" (which I promptly copied to Kiwi, fixing the problem with "Simple"). It also goes into describing Swing.

> I find it funny that a toolkit's top feature listed are "Pluggable look-and-feels". Oh, please. And tooltips. AWT must have *really* sucked.

> It finally had me understand Swing a bit better though. The class distinction is as follows: a Component (such as JFrame or JButton) holds two instance variables - one for the Model and another for the Delegate. That's what the diagram up in the DDJ article meant. We have nothing like this in Kiwi -- Kiwi is really used to structure applications, not widgets.

> It also reminded me that Java supports multiple constructors. Neat.

Todd Sunsted: MVC meets Swing

> 'While the MVC design pattern is typically used for constructing entire user interfaces' - I'm not sure this is historically correct. The Smalltalk papers I read did say that MVC was designed for widgets, frames and so on. Application-level MVC has been used before (hey!) but it's not a solution without it's issues.

> 'A model can have more than one view, but that is typically not the case in the Swing set.' - Just as I suspected. Designed for Spreadsheets<tm>. :-) No, I think the point is that there *may* be more than one view for the same model, but it's only in spreadsheets that we have more than one view *at the same time*.

> Interesting note: two types of events (or signals, which starts to clear up the confusion the first article left me with). AWT/Swing events, which are handled *inside* the Delegate, and Events which are actually processed by the Model. So the Model defines behavior too. And again it shows us that the Component hides both of these from the user most of the time.

> The pluggable look and feels are actually implemented by subclassing View - the default view (ButtonUI) for a button paints a simple bordered rectangle. And it processes AWT events into "high-level semantic events the button model expects".

Allen Holub: Building user interfaces for object-oriented systems, Part 1 and Part 2

> Allen Holub's articles are interesting, though hard to grasp entirely. I read the second article about 3 times till I had an idea of what he intended to do, and in the end I didn't agree with most of it. It seems that people have good plans but complicate things when implementing them. My goal with Kiwi is to have the developer need to do the least amount of things to get things working as expected for the simple cases.

Todd Sundsted Java and event handling

> Always neat to see that GTK+ and AWT share similarities - look at the window events, for instance. And the way signal propagation works is quite neat, too. But the way the callbacks are constructed seems at least a bit different (AWT passes in a big Event object, while in GTK+ we do have GdkEvent, but it's not passed to all events, and lots of information is provided outside of it - target widget, row number, etc.

> Apparently, AWT events (analogous to GTK+ signals) are usually captured all together, and if you want to hook to a specific one, you define a special function. It's a bit different from connect(), again.

Claire Bono: Intro to MFC

> Nice set of slides describing the main points of MFC. By what I can understand from here, there is also a Document facility (wonder why all these programs have Document, huh :-) and an "Empty" app with menu and toolbar. It's harder to get things wrong if you have everything set up for you!

> MFC is a C++ class library for Win32 programming. They call event/signal handlers "message handlers". MFC also used combined V+C called View (just like Bakery). Models are Documents. Interesting that there are MDI and SDI app classes.

Murray Cumming: Bakery

> Wow. A project that has the same aim as Kiwi's framework.

> Bakery is a bit different in that it is really for "document"-based applications (like editors), and generates a menu by default, for instance. It provides some Application classes that I need to think about for Kiwi-0.5.0. It also uses the name View for the combined Controller/View, which is okay but might cause some confusion to casual observers.

> One interesting thing is that Bakery provides a simple persistence mechanism, which saves stuff as XML. I gues Kiwi could benefit from something similar, perhaps using pickle().

> Another interesting point is that Bakery suggests using MI to have a class derive both from view and from GtkVBox, for instance. I hadn't thought of things this way before, but I'm not sure it works for Kiwi. It might, I guess.

> Bakery *always* has a Document (our Model) attached to a View. While this may be good for the applications it targets, I have found this is not necessarily true for all apps - sometimes you have a window (a launcher, for instance) that has *no* model behind it. Then what?

> Bakery has composite views, just like Kiwi has SlaveViews. However, it seems that the slaveviews all share the same document (at least that's what `View_Composite.set_document()` seems to do). My SlaveViews have their own models, which goes more in the line of the Proxy Allen suggests (though his are a bit more complicated design IMHO). I wonder what good does a shared model do to the subviews?