A Server-side Color Chooser, the Struts v. Barracuda Bake-off

[Dan Connelly <ds...@adelphia.net>]

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

Re: A Server-side Color Chooser, the Struts v. Barracuda Bake-off

[Dan Connelly <ds...@adelphia.net>]

The interesting thing about building a Struts Color Chooser app is that I am being forced to program the multiple update dependencies.  Each of my Color Views (five of them at last count) will be an Observer of all of the others, on the server-side.  This is not a problem in such a trivial case, but I am hoping to find a more general way of dealing with this.  (In another application I may want to modify an <html:options> collections on the fly this way.  Seems like this should work.)

For the Color Chooser I will render each Color View through a JSP into a separate mini-frame on the browser window.  I cannot resist referring to these dependent mini-frames as "framelets" (forgive me).   Each framelet will hold a minimal <html:form>.   When any of these formlets (ugh!) gets submitted, I will need to update all the other framelets.  Since the HTTP allows only one response I will probably select a Master Color View for the single response to any form submission.  (But in other apps, the update pattern may be much more complex.)

The standard references tell me that, in order to provide an update to each of the other framelets, I will have to supply an "onLoad" JavaScript as a knowledgeable loader in the rendering of the Master Color View.   That JavaScript program will explicitly load the subordinate Color Views.  (How to generalize??) 

I am beginning to understand the relevance of CRM's remark, in another context, that the JSP is a way to get a program to write a program.

(BTW.  I want to use Microsoft's "HyperText Component" slider widget, available at http://msdn.microsoft.com/workshop/c-frame.htm?/workshop/author/default.asp , in my Struts Color Chooser.  All the classic choosers use a slider.   It does not bother me that only IE 5.5 supports HTCs, also known as DHTML Behaviours.  Of course, there are potentially a huge number of these things.  Creating a new Struts tag for each one is not an option.  More problems of generalization.)