Hi, folks, I would like to discuss typical coding/design errors in web applications with you. It seems to me that servlets re-introduced some typical coding errors I'd already thought of as things of the past.
Talking about it eases my mind. ;-) In my experience a "naive" programming style in a web application can lead to procedural, unmodular application with much re-invention of the wheel. I'm especially talking about large (100+ pages) web applications, where these things become an issue. The Servlet API as provided by SUN, while good at shielding the programmer from sockets and HTTP, is a still rather crude framework. For scalable (in terms of programming efford) applications a higher-level framework is obviously needed. Feel free to name existing frameworks that in your opinion solve/alleviate these problem especially well. Here are some examples of coding/design mistakes that seem typical to me when using the raw Servlet API (even if you add some homegrown library for rudimentary event dispatching or more or less reusable elements). Please comment on them or add your own: * In every servlet the control flow is manually dispatched to elements contained in the page, with full knowledge of all action strings. This is not a problem if you've got, say, two hand-written FORMs in your page. But it can be a real pain if you want to reuse GUI elements as black boxes, or even nest them. This is lightyears behind the modular, event driven architecture in "classic" GUIs. * The "global variables" provided by the session object quickly become overused in large projects -- with exactly the same consequences as in traditional programming: It's hard to keep track of when these values are written or read and by which method. Not to mention the plethora of key constants if every String or Integer is put into the session separately. Especially nasty IMHO is this technique when redirecting to (sub)pages where parameters are "passed" inside the session (without encapsulating this in higher-level methods). It's a bit like BASIC from long ago where you had to put all arguments into global variables before doing a "gosub" into a subroutine. Sometimes it seems to me that programmers are completely taken in by the service() "procedure" and forget that they could use high-level objects with well-defined states at least in *their* code. As Brad Cox rightly states in http://virtualschool.edu/wap/, pages are not often considered to be first class objects. * Construction of URLs or URL parameters can be a real pain. It needs the co-operation of objects very far away on the call chain: You need the knowledge of data deep down in your (reusable?) GUI element where you want to insert, say, an HREF. But only some entity "at the top of the page" knows about URLs of other pages or other elements in this page in order to avoid name clashes (e.g. in URL parameters). If you haven't got a good framework with an intelligent registration/dispatching mechanism (which framework provides one?) you are likely to end up with ugly service methods a "page" has to implement in order to provide you with lowly URL construction capabilities. Wooo, I feel better now. ;-) Olaf ___________________________________________________________________________ To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff SERVLET-INTEREST". Archives: http://archives.java.sun.com/archives/servlet-interest.html Resources: http://java.sun.com/products/servlet/external-resources.html LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
