good idea. even better, create an *interface* "Action" and use it as the basic type for all implementing classes. the STRUTS framework is using a similar approach. anyway this is a good example for the benefits of using MVC-patterns in servlet environments. so perhaps it is a good idea to take a look at STRUTS because it is quite mature and very powerful and customizable (mostly via XML descriptors, e.g. for the mapping which URL (i.e. action request) calls which sort of action handling class etc.) and on the other hand it is freely available ( http://jakarta.apache.org/struts). moreover, it does integrate well with velocity (or so it claims ;o) so perhaps it's the framework of choice for you greg :o) cheers
> You could: > - create a class called Action > - contains method public Result doAction(request, response) > - subclass Action for each of your actions and implement doAction method > to do whatever needs to happen for that action. > > - In your servlet initialize a collection with the set of all Actions > where each is accessible using the String name of the action as the key. > - For the action String provided in a given request, get the Action from > the collection and call its doAction method. > > That would simplify the servlet and modularize the actions. BTW, I'm > not claiming credit for this idea, if you've seen it before. We use an > approach like this in a big servlet application but with more layers of > containment for various reasons. > > - Eli Edwards > > -----Original Message----- > From: Greg Nudelman [mailto:[EMAIL PROTECTED] > Sent: Wednesday, July 30, 2003 2:10 PM > To: jdjlist > Cc: Greg Nudelman > Subject: [jdjlist] Servlets Design Question > > > > I'm rewamping an old system with Servlets and a Velocity > templating engine. Servlets talk to the remote app server via a > cleint-server protocol. A typical request then is as follows: > > doService(request, response) { //"main method doGet/doPost" > > if (action == "getXXX") { > > Vector result = callRemoteGetXXX(request); > showUserXXX(result, request, response); > > } else if (action == "getYYY") { > > //etc. > > } > > > > so basically, my main servlet becomes a very bloated file with > doService(), as well as all of the callRemoteGetXXX(request) and > showUserXXX(result, request, response) methods of which there are quite > a few. What other accepted designs there are for placing the > > callRemoteGetXXX(request) and showUserXXX(result, request, > response) methods in separate files? > > 1) The old design had loosely grouped actions into types and had > an adapter for each type that passed calls around in the context back to > the servlet. All the response calls/formatting was handled in the root > CustomServlet superclass. > > Not a good idea IMHO. > > 2) create a RemoteCallManager DAO-type class, where all the (now > static) callRemoteGetXXX(request) methods would live: > > Vector result = RemoteCallManager.callRemoteGetXXX(request); > > For handling of the response, maybe I can stuff the result > Vector into the request object and then do some type of > Context.forward(responseServletForAllTransactionsOfTypeRelatedToXXX, > request, response); > > For handling all those responses, they will be loosely grouped > into response types and forwarded to 3-4 different "response only" > servlets accordingly. > > I like this better, but maybe there is another good way or some > implementation/design tricks out there? > > Any other ideas? > > Thanks in advance. > > Greg > > P.S. we're on Apache/JServ 1.1/Velocity Java 1.4.1 Solaris > > > > > > > > > --- > You are currently subscribed to jdjlist as: > [EMAIL PROTECTED] > To unsubscribe send a blank email to > [EMAIL PROTECTED] > http://www.sys-con.com/fusetalk > > > > --- > You are currently subscribed to jdjlist as: [EMAIL PROTECTED] > To unsubscribe send a blank email to > [EMAIL PROTECTED] > http://www.sys-con.com/fusetalk > -- COMPUTERBILD 15/03: Premium-e-mail-Dienste im Test -------------------------------------------------- 1. GMX TopMail - Platz 1 und Testsieger! 2. GMX ProMail - Platz 2 und Preis-Qualit�tssieger! 3. Arcor - 4. web.de - 5. T-Online - 6. freenet.de - 7. daybyday - 8. e-Post --- You are currently subscribed to jdjlist as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] http://www.sys-con.com/fusetalk
