Hi Joe, You have some very interesting observations. (See intermixed below.)
At 07:57 am 15-08-2002, you wrote: >1) "Object explosion" for large sites--1-to-1 mapping of URLs to objects can >lead to hundreds of small classes. It really bothers me that Struts >encourages this kind of situation. Although the DispatchAction helps a lot. To me, the large-number-of-small-classes approach is more a Java idiom than a Struts idiom. I've worked on Delphi before I moved to Java. In comparison, the common practice in Delphi favours a small-number-of-large-classes approach, while Java large-number-of-small classes. I see this is a trend in modern OOP. If your worry is code organization and management, I believe the package structure in Java compensates this nicely. >2) Meaningless method signatures, like execute(Mapping, Form, Request, >Response). All the methods look the same, regardless of what data they're >actually expecting. This often makes it necessary to go into the Java code >just to figure out what data a method uses. Not to mention losing >compile-time type checking. > >I have been doing front-end web development since 1996, and doing it in Java >since 2000, and in all that time I have never built a presentation tier that >I would consider both large and clean. It just seems like as websites get >bigger and bigger (the site of the company I'm working at has 738 at the >moment) there is no way to avoid "throwaway" code (i.e. at least one method >per request that does little else but service that request). I got so sick >of it that I am no longer in web development, instead I concentrate on the >backend transaction processing. > >Being a Java/OO purist, I really don't like it when 738 type-unsafe, >throwaway objects (or methods at least) make their way into the Java object >model. I have grown to recognize that large amounts of such code are >necessary in any large website, but if I can help it I would like to keep it >out of the Java source for the above reasons. This problem inherits from the bloody HTTP protocol (which was not designed for interactive apps in the first place!). I agree with you this is a bit uncomfortable, if not disappointing, that Struts hasn't raised the level of abstraction higher. However, that's what makes Struts practical. Struts takes a pragmatic approach. It doesn't try to hide all the low-level HTTP/servlet protocol/API. That leaves you a "fallback path" to fall back to more primitive technologies if Struts doesn't work out for you. I won't be surprised some years from now, Struts, as in its current form, will show its age and look relatively primitive (low-level). That will be the time we'll be all using technologies (e.g. <wishful-thinking>Struts 3.1 + JSF</wishful-thinking>) hiding all the ugly HTTP heritage. However, for now, Struts is one of the most practical platforms to write webapps. -- John Yu Scioworks Technologies e: [EMAIL PROTECTED] w: +(65) 873 5989 w: http://www.scioworks.com m: +(65) 9782 9610 Scioworks Camino - "Don't develop Struts Apps without it!" -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
