1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<head>
<link rel="STYLESHEET" href="howto.css" type='text/css' />
<link rel="first" href="howto.html" title='Developing applications with Kiwi' />
<link rel='last' href='about.html' title='About this document...' />
<link rel='help' href='about.html' title='About this document...' />
<link rel="next" href="about.html" />
<link rel="prev" href="node26.html" />
<link rel="parent" href="howto.html" />
<link rel="next" href="about.html" />
<meta name='aesop' content='information' />
<title>4 References</title>
</head>
<body>
<DIV CLASS="navigation">
<div id='top-navigation-panel' xml:id='top-navigation-panel'>
<table align="center" width="100%" cellpadding="0" cellspacing="2">
<tr>
<td class='online-navigation'><a rel="prev" title="3.1 ObjectList"
href="node27.html"><img src='previous.png'
border='0' height='32' alt='Previous Page' width='32' /></A></td>
<td class='online-navigation'><a rel="parent" title="Developing applications with Kiwi"
href="howto.html"><img src='up.png'
border='0' height='32' alt='Up One Level' width='32' /></A></td>
<td class='online-navigation'><a rel="next" title="About this document ..."
href="about.html"><img src='next.png'
border='0' height='32' alt='Next Page' width='32' /></A></td>
<td align="center" width="100%">Developing applications with Kiwi</td>
<td class='online-navigation'><img src='blank.png'
border='0' height='32' alt='' width='32' /></td>
<td class='online-navigation'><img src='blank.png'
border='0' height='32' alt='' width='32' /></td>
<td class='online-navigation'><img src='blank.png'
border='0' height='32' alt='' width='32' /></td>
</tr></table>
<div class='online-navigation'>
<b class="navlabel">Previous:</b>
<a class="sectref" rel="prev" href="node27.html">3.1 ObjectList</A>
<b class="navlabel">Up:</b>
<a class="sectref" rel="parent" href="howto.html">Developing applications with Kiwi</A>
<b class="navlabel">Next:</b>
<a class="sectref" rel="next" href="about.html">About this document ...</A>
</div>
<hr /></div>
</DIV>
<!--End of Navigation Panel-->
<H1><A NAME="SECTION000400000000000000000">
4 References</A>
</H1>
<P>
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.
<P>
<B>Mukul Sood</B>:
<em class="citetitle"><a
href="http://www.ddj.com/documents/s=916/ddj9809m/9809m.htm"
title="What is Swing"
>What is Swing</a></em>
<P>
<BLOCKQUOTE>
</BLOCKQUOTE>
<P>
<BLOCKQUOTE>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).
</BLOCKQUOTE>
<P>
<BLOCKQUOTE>I wonder how it handles OptionMenu, but it does seem to. :)
</BLOCKQUOTE>
<P>
<BLOCKQUOTE>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
</BLOCKQUOTE>
<P>
<BLOCKQUOTE>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.
</BLOCKQUOTE>
<P>
<BLOCKQUOTE>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.
</BLOCKQUOTE>
<P>
<BLOCKQUOTE>
</BLOCKQUOTE>
<P>
<B>Sachin Deshpande</B>:
<em class="citetitle"><a
href="http://www.cs.du.edu/ sdeshpan/comp4708/Lesson1/Part3.htm"
title="MVC Architecture"
>MVC Architecture</a></em>
<P>
<BLOCKQUOTE>
</BLOCKQUOTE>
<P>
<BLOCKQUOTE>Covers MVC and Swing together.
</BLOCKQUOTE>
<P>
<BLOCKQUOTE>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.
</BLOCKQUOTE>
<P>
<BLOCKQUOTE>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.
</BLOCKQUOTE>
<P>
<BLOCKQUOTE>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.
</BLOCKQUOTE>
<P>
<BLOCKQUOTE>Swing also has something called a Renderer. I have no idea what it
is used for - custom cells in tables and lists?
</BLOCKQUOTE>
<P>
<BLOCKQUOTE>
</BLOCKQUOTE>
<P>
<B>David Marshall</B>:
<em class="citetitle"><a
href="http://www.cs.cf.ac.uk/Dave/HCI/HCI_Handout_CALLER/"
title="HCI
Handout"
>HCI
Handout</a></em>
<P>
<BLOCKQUOTE>
</BLOCKQUOTE>
<P>
<BLOCKQUOTE>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.
</BLOCKQUOTE>
<P>
<BLOCKQUOTE>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.
</BLOCKQUOTE>
<P>
<BLOCKQUOTE>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.
</BLOCKQUOTE>
<P>
<BLOCKQUOTE>It also reminded me that Java supports multiple constructors. Neat.
</BLOCKQUOTE>
<P>
<BLOCKQUOTE>
</BLOCKQUOTE>
<P>
<B>Todd Sunsted</B>:
<em class="citetitle"><a
href="http://www.javaworld.com/javaworld/jw-04-1998/jw-04-howto.html"
title="MVC meets Swing"
>MVC meets Swing</a></em>
<P>
<BLOCKQUOTE>
</BLOCKQUOTE>
<P>
<BLOCKQUOTE>'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.
</BLOCKQUOTE>
<P>
<BLOCKQUOTE>'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*.
</BLOCKQUOTE>
<P>
<BLOCKQUOTE>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.
</BLOCKQUOTE>
<P>
<BLOCKQUOTE>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".
</BLOCKQUOTE>
<P>
<BLOCKQUOTE>
</BLOCKQUOTE>
<P>
<B>Allen Holub</B>:
<em class="citetitle"><a
href="http://www.javaworld.com/javaworld/jw-07-1999/jw-07-toolbox.html"
title="Building user interfaces for object-oriented systems, Part 1"
>Building user interfaces for object-oriented systems, Part 1</a></em>
and
<em class="citetitle"><a
href="http://www.javaworld.com/javaworld/jw-09-1999/jw-09-toolbox.html"
title="Part 2"
>Part 2</a></em>
<P>
<BLOCKQUOTE>
</BLOCKQUOTE>
<P>
<BLOCKQUOTE>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.
</BLOCKQUOTE>
<P>
<BLOCKQUOTE>
</BLOCKQUOTE>
<P>
<B>Todd Sundsted</B>
<em class="citetitle"><a
href="http://www.javaworld.com/javaworld/jw-08-1996/jw-08-event-p2.html"
title="Java and event handling"
>Java and event handling</a></em>
<P>
<BLOCKQUOTE>
</BLOCKQUOTE>
<P>
<BLOCKQUOTE>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.
</BLOCKQUOTE>
<P>
<BLOCKQUOTE>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.
</BLOCKQUOTE>
<P>
<BLOCKQUOTE>
</BLOCKQUOTE>
<P>
<B>Claire Bono</B>:
<em class="citetitle"><a
href="http://www-scf.usc.edu/ csci201/notes/MFCintro/"
title="Intro to MFC"
>Intro to MFC</a></em>
<P>
<BLOCKQUOTE>
</BLOCKQUOTE>
<P>
<BLOCKQUOTE>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!
</BLOCKQUOTE>
<P>
<BLOCKQUOTE>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.
</BLOCKQUOTE>
<P>
<BLOCKQUOTE>
</BLOCKQUOTE>
<P>
<B>Murray Cumming</B>:
<em class="citetitle"><a
href="http://bakery.sourceforge.net/"
title="Bakery"
>Bakery</a></em>
<P>
<BLOCKQUOTE>
</BLOCKQUOTE>
<P>
<BLOCKQUOTE>Wow. A project that has the same aim as Kiwi's framework.
</BLOCKQUOTE>
<P>
<BLOCKQUOTE>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.
</BLOCKQUOTE>
<P>
<BLOCKQUOTE>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().
</BLOCKQUOTE>
<P>
<BLOCKQUOTE>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.
</BLOCKQUOTE>
<P>
<BLOCKQUOTE>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?
</BLOCKQUOTE>
<P>
<BLOCKQUOTE>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 <code>View_Composite.set_document()</code> 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?
</BLOCKQUOTE>
<P>
<BLOCKQUOTE>
</BLOCKQUOTE>
<P>
<DIV CLASS="navigation">
<div class='online-navigation'>
<p></p><hr />
<table align="center" width="100%" cellpadding="0" cellspacing="2">
<tr>
<td class='online-navigation'><a rel="prev" title="3.1 ObjectList"
href="node27.html"><img src='previous.png'
border='0' height='32' alt='Previous Page' width='32' /></A></td>
<td class='online-navigation'><a rel="parent" title="Developing applications with Kiwi"
href="howto.html"><img src='up.png'
border='0' height='32' alt='Up One Level' width='32' /></A></td>
<td class='online-navigation'><a rel="next" title="About this document ..."
href="about.html"><img src='next.png'
border='0' height='32' alt='Next Page' width='32' /></A></td>
<td align="center" width="100%">Developing applications with Kiwi</td>
<td class='online-navigation'><img src='blank.png'
border='0' height='32' alt='' width='32' /></td>
<td class='online-navigation'><img src='blank.png'
border='0' height='32' alt='' width='32' /></td>
<td class='online-navigation'><img src='blank.png'
border='0' height='32' alt='' width='32' /></td>
</tr></table>
<div class='online-navigation'>
<b class="navlabel">Previous:</b>
<a class="sectref" rel="prev" href="node27.html">3.1 ObjectList</A>
<b class="navlabel">Up:</b>
<a class="sectref" rel="parent" href="howto.html">Developing applications with Kiwi</A>
<b class="navlabel">Next:</b>
<a class="sectref" rel="next" href="about.html">About this document ...</A>
</div>
</div>
<hr />
<span class="release-info">Release 1.9.22, documentation updated on August, 2006.</span>
</DIV>
<!--End of Navigation Panel-->
</BODY>
</HTML>
|
