On Thu, 16 Sep 1999, Steven J. Owens wrote:
> 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.
This is one of the first things that I read when I started doing
servlets. It's mentioned in Jason Hunter's book, and I suspect most
servlets books. It says right there in the API docs "Notice that the
service method is not typically overridden". No, they didn't go into
a lot of detail about why this is recommended practice, but then it
seemed pretty straightforward to me, and to fit in with good general
programming practices. Also, it's one thing to question advice like
that, but it's another to just ignore it totally. As if they just put
in there arbitrarily.
[ ... ]
> 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.
The thing you're missing is that there's a lot of functionality in the
default service() method, and by overriding it, you're throwing it all
away. Even if other things are equal, that's enough to make that
option less appealing. That makes either of those latter two options
clear favorites in my mind. Choosing between them is somewhat a
matter of aesthetics and symmetry.
> > 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().
Well, service(), doPost(), and doGet() didn't/don't exist in the CGI
world, so I don't see why you should be thinking this way. It's not
like you did it that way (i.e. by overriding service()) with CGI. And
no need to enforce CGI thinking with servlets. I don't know, if I was
new to servlets, and saw a recommended practice that I didn't quite
understand, I'd probably say to myself "I don't quite understand why
this is a good idea, but it's not tricky, and I'll just follow it" as
opposed to "I'm just going to ignore this suggestion".
> 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.
But again, you're not in the CGI world here, so why try limiting your
thinking. Not everything is a nail, you know. In fact, there is more
you can do with POST in the servlet world, like applet-servlet
communication, for example.
Milt Epstein
Research Programmer
Software/Systems Development Group
Computing and Communications Services Office (CCSO)
University of Illinois at Urbana-Champaign (UIUC)
[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
