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.)
 

Reply via email to