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
