CHANNELS
 
 
 
 
 
 
 
 
ON THE WEB
 
 
 
 
PRINT EDITION
 
 
 
 
BZ MEDIA
 
 
 
 
ADVERTISER LINKS
 
 
 
 
 
LOADING...
LOADING...
 
 
AS OF 8/21/2008 7:13PM EST
A Conversation With Creator’s Creator
By Allen Holub

October 15, 2005 — A few weeks ago, I wrote about my disappointment with Sun’s Studio Creator. My main problem is Creator’s flavor of model-view-controller, which puts a straitjacket on the tool, preventing you from using a more flexible (and more object-oriented) UI architecture, such as Presentation Abstraction Control. The net effect of this tight coupling it that your Creator application is doomed to a life of difficult maintenance because the UI is too tightly coupled to both the underlying database and to the implementation of the application-level classes. (I should say that the real flaw is the JSF framework that underlies Creator—most of the commonly used UI frameworks, including JSF and Struts, are not particularly well thought out.)

Well, Sun called me up to arrange an interview with Craig McClanahan, Studio Creator’s architect. Interestingly, the software we used during the interview was as interesting as the interview itself—more on that in a moment. McClanahan’s motive was to prove to me that I could do what I wanted to do using Creator. In fact, you can get about halfway there, but I’m still not sold.

In the most successful systems I’ve written, the objects that constituted the “business logic” were responsible for creating that part of the user interface that represented their own state. Think of it as if every object has a “display yourself” method. (That’s obviously not how a real system works—real systems use things like the Gang-of-Four “Builder” design pattern to separate business and representation logic, and they can represent attributes of themselves with finer granularity—but it’s a good conceptual model.)

Studio Creator’s main flaw is that you must lay out widgets on the screen and then hook those widgets up to the object. If the object’s implementation changes, then all of the infrastructure that hooks up the object to the widget is now broken. I, on the other hand, want all changes to an object to be localized in a single place—ideally a single class definition and its inner classes. If the class definition changes, the UI should scale automatically. Studio Creator won’t do that because that’s not the way model-view-controller works.

On the plus side, McClanahan did demonstrate to me that it’s possible to create a business object that doesn’t expose its implementation with unnecessary get/set methods, and then hook that object up to the framework. You must create a Gang-of-Four “Mediator” that uses get/set methods to communicate with the framework while simultaneously using more reasonable messages to communicate with the business object. Unfortunately, that mediator currently can’t be implemented as an inner class, so this mechanism falls more into the kluge than feature category for the moment.

Returning to the meeting software, we were using WebEx’s “Meeting Center” (webex.com/services/online-meeting-svc.html). WebEx effectively lets you look over someone’s shoulder as they work. You see the software that they are using, or their whole desktop, in your Web browser. McClanahan was using WebEx to demo Studio Creator as he spoke to me using a normal conference-call connection.

One particularly interesting feature of WebEx is its ability to record a session for later playback. The thinking is that it could be used for online instruction, but I doubt that a “class” taught this way would be as effective as a real instructor. The feature is invaluable, however, for documentation.

Getting your average programmer to write documentation is like pulling teeth, and written documentation is for the most part worthless. Using WebEx’s recording feature, however, you can just sit programmers in front of their favorite code editor, and then record them as they explain the code. Since you can look at graphics programs too, not just editors, you can record a designer explaining the intricacies of a UML diagram (most of which are almost incomprehensible without some soft of ancillary explanation), and as a program moves into production, you can show people the connections between the design and the implementation.

This is a much more interesting use (at least to me) than a virtual meeting, and solves a real problem in an elegant way.

Finally, and on a related subject (UI builders), I was complaining a while ago that the new JavaBeans spec was not transparent enough. Joe Nuxoll, the spec lead, pointed me to several java.net sites that proved me wrong (community.java.net/projects/#16, jsr.dev.java.net and jbdt-spec-public.dev.java.net). It’s a mystery why those sites aren’t referenced from the actual JSR page, however. The whole Java Community Process site is, to my mind, almost completely worthless for exactly this reason—the JSRs are listed, but there are often no references to the sites where actual work goes on or to anywhere you can monitor the work in progress. These sort of references should be a required part of the JSR writeup.

Allen Holub is an architect, consultant and instructor in C/C++, Java and OO Design. Reach him at www.holub.com.
 


 
 
 
 
 
 
 
 
 
 
SUBSCRIBE TODAY!
 E-Newsletters:
  News on Mon/Thurs.
  Test & QA Report
  EclipseSource
 
 
JOB BOARD
 
PDF & PRINT EDITION
* Requires Resource Account!  LOGIN or SIGN UP

Download Current Issue!
ISSUE 8/15/2008 PDF

Need Back Issues?
DOWNLOAD HERE

Receive The Print Edition?
SUBSCRIBE HERE
 
REGISTER
 
GET NOTIFIED!
About all of the latest Resources
 
 
SD TIMES 100
It's time once again to
recognize the organizations
or individuals that have
demonstrated leadership in
their markets.