sorry, "Action" is a class as well, not an interface in STRUTS... anyway, the basic concept is not influenced by that ;o)
> 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 > -- 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
