I'm continuously unimpressed by the implicit assumption that "Developer Productivity" == "GUI construction". The blind acceptance of this hoary old chestnut has been a huge impediment to real progress in developing better systems.
Given that the rapid construction of a UI is a good thing, what's my beef?
Simply put, there's a whole world of complexity behind the UI that needs to be conceived of, designed, and implemented before the application is useful. It's this complexity that goes begging when UI construction is the sole (or even majority) measure of productivity.
There are levels of productivity. GUI building is on the surface, easy to see. But it's thin, and not nourishing. Real productivity lies in the ability to provide rich, complex functionality that supports real people in getting real things done.
GUI tools tend to concentrate on the thin layer on top, providing some hardwired mechanism(s) underneath to support the UI. This is an extreme limitation in real productivity in that it limits the access the developers have to the underlying bits. Struts provides the framework that lets us deal with the UI and get past it into the Java world where we're really limited only by our own skills and knowledge.
Like Vic said in his post, I provide training in Struts (and other stuff) to corporate clients. I recently mentored a bunch of mainframe programmers starting up with Java/Struts in order to reimplement their existing FoxPro application. It's a simple customer info collection application - get some info into a form, save it, find it, update it, save the changes. The UI side of things is straightforward with Struts, as it would be with other technologies. BUT, real complexity lies unspoken in the "find it" functionality.
The naive approach is to provide a single-field input form accepting a client ID# which is used to look up the info. Next up is the "search form" approach: "Let's give them a form that looks like the input form, let them fill in some value(s) and then search for their info". OK, now we're talking. What fields are on the form? How do the values entered interact with one another - implicit ANDs or ORs, or do we try to give them a real query builder? And so it goes. Even better, as the user population gains experience with the application, having a flexible powerful language and platform underneath employed via strong, supple frameworks and architectures makes it much, much easier to continually improve things than is the case for systems built from GUI-oriented tools lacking Java's access to the machinery.
Up until now the Java world has concentrated on core technology, and thereby enabled core productivity. Struts has brought us up to the surface, and things have always improved. I'm really hoping that JavaServer Faces will provide the rapid UI-building experience other tools and technologies enjoy. Once that happens the world will change. It'll be Java all the way down.
Chris
At 03:14 PM 6/11/2003, you wrote:
Chris, I tend to agree with your assessment of JavaPro but I'd like to open this up a little. Right now we are faced with two choices for web development .Net or not .Net. I can over-simplify the arguments for and against .Net as the following:
.NET Pluses Developer Productivity Negatives Vendor lock in.
Others (including Struts) Pluses No vendor lock in Negatives Less developer Productivity
It seems like many if not most companies are more interested in developer productivity.
Does anyone know of, or foresee any means by which we (developers) will be able to be as productive using Struts/JSP/DHTML/JavaScript etc. as people are using .Net? I'd love to be able to make a case against .Net .
Thanks
Glenn
-----Original Message----- From: Chris Gerrard [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 11, 2003 12:07 PM To: [EMAIL PROTECTED] Subject: Stuts can't "get its act together" - JavaPro
I found this announcement today on JavaPro's August Issue online "In Brief" site: http://www.ftponline.com/javapro/2003_08/magazine/departments/inbrief/defaul t.asp
The blurb: Developer Tools TurboM2 Tired of waiting for The Apache Group to get its act together with the Struts initiative, Virtuas has launched a framework of its own. Virtuas released TurboM2 previously under the name Web Application Model (WAM). Since then, the company decided to alter the product to perform many of the features Struts offers, and like Struts will be released under the open source model.
There's more, but on casual inspection it appears that JavaPro has simply regurgitated some marketing poo from Virtuas intended to convey the impression that Struts is in a funk and not moving forward. (so one should naturally move to Virtuas' TurboM2 product)
Upon casual inspection it appears that TurboM2 is a fairly direct clone of Struts. On of Virtuas' value-added claims is that TurboM2 has available support and training that Struts does not.
Links: Virtuas TurboM2: http://www.turbom2.org/index.html Struts/TurboM2 comparison: http://www.turbom2.org/docs/Comparison.pdf
The part that disturbs me is JavaPro's presenting this whole pile as if it were truth. Someone reading this article could well be persuaded that yes, indeed, Struts is in trouble and they should look elsewhere. I've been less than impressed with JavaPro's content for some time, and this erodes my confidence in their editorial control and knowledge of the Java world even further.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
