The canonical MVC application in the GUI world is the
Color Chooser.
You will see the Color Chooser in standard texts on both
Motif and Swing, but with very different implementations of the "Observer"
pattern. The Patterns people claim that the Observer is at the heart of
MVC loose coupling. I agree, although that pattern is
an arch wide enough to drive several implementation buses
through.
Your Java 2 jdk distribution probably contains a Color Chooser
application under demo/jfc/SwingSet2. However, that app is quite
complex, more demo than tutorial. The O'Reilly book by Eckstein, Lay
and Wood has a more approachable example. Source code is available in
either case.
I propose that we have a "contest" to implement
a Struts Color Chooser, with a goal being to provide as much as possible of
the liveliness that one sees in the Java/Swing app and to support a
server-side Color Database. This is an exercise left to
you, the reader. It is not to be part of the Struts
codebase.
You can find numerous examples of simple Javascript Color
Choosers which operate totally on the client-side using very static color
tables. These "apps" do not have a sever-side except for the
HTML pages. To show off Struts, I want to add a server-side. The
Struts Color Chooser must support a database of Color
Names. However, that term database is loose. It need not be
persistent, but it must be accessible to all concurrent Color Chooser web
apps.
So.... There will be a Color Model, with various Color Views
(e.g., RGB Sliders, RGB Numerics, HSV Numerics and Color Names). The
various Views must update each other in timely fashion (somehow). There
should be a "ComboBox" allowing the user to scroll a (dynamic) database of Color
Names. There must be Color Actions for adding, editing and deleting Color
Names on the shared database (which need not be persistent across
server-side reloads of the Struts Color Chooser).
We can try this in Struts, Baracuda,
Turbine and Hammock (about which I know nothing). You may also
want to try it in your favorite scriptable template engine, but this would be
unlikely to beat out any of the above four.
BTW, on closer reading of the Barracuda "Overview" I see that
Barracuda does not (now) claim any mechanism to map client-side
events to server-side handlers. This is more limiting than I was
expecting, given the rhetoric from Barracuda that would
support a Swing-style Event/Listener model. (But not for
the Barracuda View ??) I incorrectly imputed to Barracuda a desire for
propagating client-side events when i posted comparing Struts to
Barracude. This is not true. Like Struts, the only client-side event
that Barracude builds in is an HTTP Request generated by a
Form/Submit.)
On further consideration of the issue of event notification, I
am less pessimistic about the "mud". I do think that both Struts and
Barracuda, in their current distributions, could host applications which
implement client-side events that are notifiers to server-side
actions. This can be done with slightly less fuss than I previously
imagined because the set of client-side events to be accommodated is already
identified and limited. There is a clear path to the
application code to send notifications for these events. But this
code may be repetitious and inelegant. That is
the crux of the matter.
In Struts, the onXXX JavaScript handlers in the html
tags be coded as event notifiers that interact with server
actions. I would guess (just guessing) that Baracuda wants
to use Java applets for this. The SOAP/Biztalk books
now filling your local bookshop have examples of client-side
events being sent server-side using
JScript/SOAP/XML. The examples there are even more
repetitious and inelegant, being totally in static HTML. But this is how
Microsoft captures a market and then sells its Visual tools.
As far as my contest is concerned, almost anything is
fair. I requre that at least one of the two "standard"
browsers be supported in one of its standard realeases. You can require
any browser setting you need. But, no plug-in or ActiveX downloads are
permitted. Also, you must build the application on top
of some standard distribution of your chosen framework. You may
use any extensions that this framework permits, but you must not
alter the framework in the cases where it is open source (Struts, Turbine,
Barracuda).
The contest will be "judged" on the basis of both
functionality and elegance. The time limit should be very generous so that
we can share ideas. Say one year.
Dan Connelly
