> I don't see a whole lot of difference, any way you slice it.
The difference lies in the fact the service() does far more than just call
doGet and doPost. If you override that method you loose the simplicity of
adding doPut, doDelete, doOptions and doTrace plus the getLastModified must
be handled independantly.
(*Chris*)
----- Original Message -----
From: Steven J. Owens <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, September 16, 1999 1:21 PM
Subject: Re: Still having Problem with POST FORM
> I wrote:
> > > Frankly, I override the service() method. Various people have
> > > said "this is bad" but I've never actually heard a coherent, cogent
> > > explanation of why it's bad. [ ... ]
>
> Milt Epstein replied:
> > Or perhaps you just didn't appreciate those explanations.
>
> No, I just haven't _heard_ any explanation, other than "because
> it's bad", or I would have quoted one (and I'm sure 90% of those were
> people parroting what *they* heard). Thanks for being the exception.
>
> > What the default service() does is very nice, farming requests out
> > to appropriate doXXX() methods. So when you want to do different
> > things with GET and POST (or whatever) HTTP methods, it's very nice.
> > And still it's very easy to handle the case when they do the same
> > thing.
>
> So the alternatives when you have no need to differentiate GET and
> POST are;
>
> Overriding at a point higher up the chain (service()) and
> handling both alternatives (GET and POST) there.
>
> Going further down the chain, coding two methods instead of one,
> and having the second method (doGet()) call the first method
> (doPost()) and return the results.
>
> Override both both doPost() and doGet() and have them just call a
> third method with the arguments, and do all the work there.
>
> I don't see a whole lot of difference, any way you
> slice it. Using the second or third option makes things easier in a
> child class, I guess, so you don't have to do any convoluted nonsense
> like overriding service() and having doPost() call super.service(). I
> could see that as being something of a concrete strategic (though not
> tactical) benefit. I still don't see it as warranting the ominous
> overtones in which the topic is usually discussed.
>
> > Perhaps you've only worked with servlets that do the same thing with
> > GET and POST. But that doesn't mean that 99% of applications work
> > that way. And if you ever have to change, it'll be a lot easier if
> > you had just left service() alone in the first place.
> >
> > In addition, not having heard a compelling argument for not overriding
> > service() is *not* a compelling argument *for* overriding service().
>
> Perhaps it's because I started in the CGI world, where the
> program can pretty much ignore which method was used for getting the
> data to it, once you parse the data into some useful structure.
> Because I'm coming from the perspective of needing a compelling reason
> to override both doPost() and doGet(), when it's simpler to just
> override service().
>
> And I'll note that in the CGI world (which means most of the
> server web programming up until the introduction of servlets) 99% of
> applications *do* work that way; in fact the general rule of thumb is
> to avoid GET unless you have a specific reason, for example to allow
> the user to bookmark the request, or to carry a bit of data, like a
> unique user serial number, on a URL.
>
> Steven J. Owens
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
>
>
___________________________________________________________________________
> 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
