thanx 4 the tip, I will have a look at WebWork too. but, on the other hand, I've heard that Struts is also used as the standard MVC implemetation in the new bea weblogic release, which also doesn't make it a *better* solution, but still moves it towards a de facto standard. and regarding gregs Q: yes, command pattern alright, and david has already pointed out some of the other advantages: centralized authentication/authorization and all kinds of "housekeeping", all in one central point. in fact I developed a "front controller servlet" with authentication/authorization myself some time ago (I wasn't aware of struts et al. then) which took the mapping information from a RDBMS and also allowed "logical" URLs mapped to physical one's, so that no special extensions (.jsp, .to or the like) are necessary and the URLs can be just any arbitrary name. still works good, but is far from beeing as powerful and customizable... greets 2 all
> I wasn't aware of WebWork, thanks for the tip. It's always good to know > about alternatives. > > As a consultant, though, I'll go with Struts over WebWork. In checking out > dice.com, I find 4 job/contract entries that reference WebWork, versus 238 > that reference Struts. > > The following disclaimer applies: the popularity and widespread use of > Struts does not make it a better solution. Nor does it make it better for > your particular problem. I just like the fact that it is a part of > apache.org, there are some extaordinary pople that have contributed to the > development of Struts, it has several years of development and use > (equating > to maturity) behind it, and having good visibility means that my clients > (current and potential) are looking for developers and architects with > Struts knowledge, and as a development manager, I can find people with > Struts knowledge. > > David > > ----- Original Message ----- > From: "Joseph Ottinger" <[EMAIL PROTECTED]> > To: "jdjlist" <[EMAIL PROTECTED]> > Sent: Thursday, July 31, 2003 9:47 AM > Subject: [jdjlist] RE: Servlets Design Question > > > You could also look at WebWork, which is far simpler than Struts and gives > you just as much power, and costs just as much. > > On Thu, 31 Jul 2003, David Tomlinson wrote: > > > I would agree with this suggestion. I've used Struts on my last 3 > projects. > > Struts has a servlet (ActionServlet) that interpretes all HTTP requests, > and > > then calls Action classes as configured in a struts-config.xml file. The > > Action class implements a Command pattern; it is passes the > ActionMapping > > (the entry in the Struts config file), an ActionForm (a class that > > represents the (form) data from the browser), the Request, and the > Response) > > > > The Action class returns an ActionForward, which is interpreted by > > ActionServlet as a destination, which results in either a forward or a > > redirect. > > > > It is very easy to use, in its simplest implementation, yet provides > many > > tools and allows you to extend it for your needs. For example, you can > > extend the ActionServlet to handle session authentication and request > > authorization, and various server level initialization tasks (caching > static > > objects, initializing logging classes, etc.). You can extend Action and > > create a base ApplicationAction class that does the various request > level > > housekeeping tasks. > > > > Check out http://jakarta.apache.org/struts/index.html and > > http://jakarta.apache.org/struts/api/index.html > > > > David Tomlinson > > > > ----- Original Message ----- > > From: <[EMAIL PROTECTED]> > > To: "jdjlist" <[EMAIL PROTECTED]> > > Sent: Wednesday, July 30, 2003 6:51 PM > > Subject: [jdjlist] RE: Servlets Design Question > > > > > > > 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) { file://"main method doGet/doPost" > > > > > > > > if (action == "getXXX") > > > > > > > > > > Vector result = callRemoteGetXXX(request); > > > > showUserXXX(result, request, response); > > > > > > > > } else if (action == "getYYY") > > > > > > > > > > file://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 > > > > > > > > > > > > --- > > You are currently subscribed to jdjlist as: [EMAIL PROTECTED] > > To unsubscribe send a blank email to > [EMAIL PROTECTED] > > http://www.sys-con.com/fusetalk > > > > ------------------------------------------------------------------- > Joseph B. Ottinger http://enigmastation.com > IT Consultant [EMAIL PROTECTED] > J2EE Editor - Java Developer's Journal [EMAIL PROTECTED] > > > --- > 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
