Hi,

IMHO squeezing a big chunk of your application's functionality into one huge
class breaks some fundamental OO design principles. Good OO designs usually
have a lot of medium or small "coherent" classes rather than a few very big
ones which contain unrelated data or functionality. This makes it easier to
use OO techniques such as encapsulation and inheritance to achieve goals
like re-use, ease of maintenance etc.

There are plenty of resources out there to learn more about OO design...

I think that it can be difficult to achieve a good OO  design with servlets,
which are inherently functionally-orientated, but one possible way to deal
with the problem in the original post is to define a 'handler' servlet which
is a super-class of all handler servlets in the application. This can define
common functionality such as error handling, input validation, checking
security permissions etc. This would still mean a separate (servlet)
sub-class for each web-page but this is not necessarily such a bad thing.
After all, there are plenty of ways of managing large numbers of class
files, like the package mechanism built into the language as well as
sophisticated IDE's etc.

Oisin

> -----Original Message-----
> From: Ryan Richards [SMTP:[EMAIL PROTECTED]]
> Sent: Tuesday, September 12, 2000 5:23 AM
> To:   [EMAIL PROTECTED]
> Subject:      Re: SV: Design Question
>
> Thanks to all for there responses.
>
> Matthias:
>
> I can see your point and it is interesting indeed. Basically
> instead of using one Servlet you combine all the processes
> into one servlet and have each form utilize that servlet
> .... hmm very interesting. I will go with that. Thanks!
>
> Ryan
>
>
>
>
> -----Original Message-----
> From:    Matthias Carlsson
> [EMAIL PROTECTED]
> Sent:    Mon, 11 Sep 2000 19:07:28 +0200
> To:      [EMAIL PROTECTED],
> [EMAIL PROTECTED]
> Subject: SV: Design Question
>
>
> Although I don't know if it is an effective approach, this
> is how I
> (usually) solve this kind of problems (and since I'm used to
> it, I
> find it effective).
>
> Since I don't like having lots of classes, I create one
> servlet, say
> FormHandler. When I call this servlet, I also include a
> parameter
> telling me which form it was called from. This check is done
> in it's
> doPost method, and the correct doPost is then called. See
> example
> below:
>
> import java.io.*;
> import javax.servlet.*;
> import javax.servlet.http.*;
>
> public class FormHandler extends HttpServlet {
>
>         public void doPost(HttpServletRequest request,
> HttpServletResponse
> response)
>         throws ServletException, IOException {
>
>                 String caller = request.getParameter("caller");
>                 if (caller.equals("form1")) doPostForm1(request,
> response);
>                 else if (caller.requals("form2")) doPostForm2(request,
> response);
>                 ... and so on
>
>         }
>
>         private void doPostForm1(HttpServletRequest request,
> HttpServletResponse
> response)
>         throws ServletException, IOException {
>                 // handle form data sent from 'form1'
>         }
>
>         private void doPostForm2(HttpServletRequest request,
> HttpServletResponse
> response)
>         throws ServletException, IOException {
>                 // handle form data sent from 'from'
>         }
>
> }
>
> This way, you can easily add new forms to be handled to the
> servlet, and you
> won't
> have to keep track of several source files, and their class
> names.
> Hope this helps.
>
> [ Matthias Carlsson ]
> [ Programmer (Java, CGI/Perl, Javascript, HTML) ] [ Web
> Designer ]
> [ E-Mail : [EMAIL PROTECTED] ] [ ICQ:
> 1430647 ]
>
> -----Ursprungligt meddelande-----
> Fran: A mailing list for discussion about Sun Microsystem's
> Java Servlet
> API Technology. [mailto:[EMAIL PROTECTED]]For
> Ryan Richards
> Skickat: den 11 september 2000 15:43
> Till: [EMAIL PROTECTED]
> Amne: Design Question
>
>
> I have a web site that uses several servlets to capture and
> utilize html form data and extract or insert into a database
> based on the form etc...Each form has it's own servlet that
> does the functionality. The only difference between them is
> of course th form elements and the jdbc queries/operations.
>
> My question is this: Should I be looking at a specific
> design pattern or some other means to get away from using a
> specific servlet for EVERY html form? I feel like I am doing
> a half-baked approach here and would appreciate any
> ideas/comments/etc..
>
>
> Ryan
> __________________________________________________________________________
> _
> Visit http://www.visto.com/info, your free web-based
> communications center.
> Visto.com. Life on the Dot.
>
> __________________________________________________________________________
> _
> 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
>
>
>
>
>
>
> __________________________________________________________________________
> _
> Visit http://www.visto.com/info, your free web-based communications
> center.
> Visto.com. Life on the Dot.
>
> __________________________________________________________________________
> _
> 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

___________________________________________________________________________
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

Reply via email to