Reverse2Servlet doXxx( question )

As always, I'm afraid of putting too much detail in my question, so I hope this isn't too cryptic...
I have Reverse2Servlet working as requried, but the only way I could find to do so was to override multiple doXxx() methods. This seems silly to me since one of them can only be used once. Is there a way to make the one that gets used all the other times handle the initial request? The way I tried it I got a standard no body HTML page that must have come out of LogServlet...

I am not sure I understand your question, but take a look at this post.

There is nothing special about the doXXX() methods, they're just like any other method in Java, and can be called in the same the manner.

OK, since now I'm royally confused allow me to ask my question more bluntly and a friendly neighborhood bartender can edit my post if needs be...
I had to use a doGet() method to handle the initial page request (i.e. the one with a non existent form) and then a doPost() method to handle the same request with a populated form. What I'm trying to ask, is there a way to get the doPost() method to handle the inital page request so that I don't have to override both methods???

Ah, now I see what you are asking.
Since you are hitting the servlet the first time via the URL, this is a GET request from your browser, no way around it, at least from everything I have read/done. A POST request has to be specified, since GET is the "default" request method, and you specify it by declaring it in your form.
If there is some way to force a POST request in this situation, I'd love to hear about it!

Originally posted by Joel Cochran:
I had to use a doGet() method to handle the initial page request (i.e. the one with a non existent form) and then a doPost() method to handle the same request with a populated form.

I assume that non existant form means empty form, right? There's a hint in the assignment about the form:
"You can set the contents of an HTML input tag by introducing the value attribute:
<input type=text name=text value="spooooooon!" size=50 >"
Using that hint is key to this assignment.
As far as the doXXX methods go, remember that you can treat both requests and responses with one doXXX.
Maybe that helps?

Hey no fair posting while I'm still typing Jason!

Originally posted by jason adam:
Ah, now I see what you are asking.
Since you are hitting the servlet the first time via the URL, this is a GET request from your browser, no way around it, at least from everything I have read/done. A POST request has to be specified, since GET is the "default" request method, and you specify it by declaring it in your form.
If there is some way to force a POST request in this situation, I'd love to hear about it!

This is a common issue with Servlets and the usual solution I've been exposed to calls doPost from doGet.

Nothing wrong with this, especially if the code for both GET/POST method calls is identical or makes more sense when combined.

Michael Pearson writes:
This is a common issue with Servlets and the usual solution I've been exposed to calls doPost from doGet.
I'm in no way doubting that that's a valid solution, but I just want to point out that you can also create a third method that both doPost and doGet call.
I tend to think of doPost and doGet as being special in the sense that they should be called only by the servlet container.

But 5 minutes' thought later I'm not so sure I agree with myself anymore. On the other hand, I guess I wouldn't hesitate to call init() or paint() or somesuch in an applet, and those are things that get called by the applet viewer just like doGet() and doPost() get called by the servlet container. But there just seems to be something more ...sacred(?) about the server calls. You know, GET and POST often being written in capital letters and all.

Originally posted by Pauline McNamara:

I assume that non existant form means empty form, right? There's a hint in the assignment about the form:
"You can set the contents of an HTML input tag by introducing the value attribute:
<input type=text name=text value="spooooooon!" size=50 >"
Using that hint is key to this assignment.
As far as the doXXX methods go, remember that you can treat both requests and responses with one doXXX.
Maybe that helps?

Actually, I mean a non-existent form. When you type code removed - bad dog! in the address line of your browser there is no form to submit, so the Servlet assumes a GET method. What I was hoping to do was find a more elegant solution than overriding both methods.
Thanks for the hint, but I got all that already, now I'm just nitpicking myself!
[ May 15, 2002: Message edited by: Pauline McNamara ]

Calling one of the doXXX() methods from the other doXXX() method is what I was hinting at in my first post... sheesh, you people have the subtlety of a bull in the proverbial china shop :roll:
What he was ASKING is if you can just override one without having to call one from the other. In other words, make the initial call to a webpage go directly to doPost() without the intermediate call to doGet().
[ May 14, 2002: Message edited by: jason adam ]

Originally posted by jason adam:
In other words, make the initial call to a webpage go directly to doPost() without the intermediate call to doGet().

Sure you can. But the assignment tells you not to.
Michael "gotta try out this subtlety thing" Matola
[ May 14, 2002: Message edited by: Michael Matola ]

You can? How? Without using a form, but instead by typing in the URL and hitting enter, I didn't think there was a way to make that a POST, it just automatically defaulted to GET.

Drat. Jason's right. I'm wrong. You can't do what I thought. Scratch my last post. Sorry to add to the confusion.

I don't understand the reluctancy to overwrite both doGet and doPost. They are there for a reason.
The second most common technique I've seen has doGet and doPost call a third method, like Matola suggested . For simple Servlets I don't think this is necessary.

What I was hoping to do was find a more elegant solution than overriding both methods.
Thanks for the hint, but I got all that already, now I'm just nitpicking myself!

Sorry, didn't mean to be insulting, wasn't sure just where you were stuck. In addition to the comments above, the link in Matthew's post (above) discusses some of the elegance question.
[ May 15, 2002: Message edited by: Pauline McNamara ]

Originally posted by Michael Pearson:
The second most common technique I've seen has doGet and doPost call a third method, like Matola suggested . For simple Servlets I don't think this is necessary.

Not that I have much experience with servlets to base it on, but the last discussion about which way makes more sense was enough to convince me that calling a third doStuff from doPost and doGet seems more logical.
Why not for simple servlets too?

I agree with Michael's earlier post. For our purposes, doPost and doGet can work well together by having one call the other (if they doing the same work). Creating another doXXX may add more complexity than is necessary. (But than again that's just my 2 cents)
Good luck on your own choice

Originally posted by Pauline McNamara:

Not that I have much experience with servlets to base it on, but the last discussion about which way makes more sense was enough to convince me that calling a third doStuff from doPost and doGet seems more logical.
Why not for simple servlets too?

To me it seems "procedural" to drive all of the activity into a single doXXX method. I'm not saying I have a preference, just sharing what I've noticed.
[ May 15, 2002: Message edited by: Michael Pearson ]

I stuck with the two methods version, but I'm sure I'll get nitpicked (I am a bad dog after all ) for having almost duplicate code, but I guess we'll wait and see.
Thanks everyone!

Okay Java Gurus, here's a related question.....
If you call doPost() from inside doGet() and there are paramters to be passed that you wish to remain a secret, will your secret be exposed by calling doPost this way, and is there a way to avoid this exposure???
Not that i'm thinking of any particular assignment, whistle, whistle nonchalantly.......

<guru:not>
Calls to doPost do not show form data in the request header, it is sent on a separate data line.
Calls to doGet show form data in the request header.
If you want to keep all of your form data hidden, like a password, call doPost and let it call doGet if you need to support both GET and POST methods.
</guru:not>

Okay, I tried that, but what if you have two separate pages produced by the same servlet, where one page is produced by doPost() and the other is produced by doGet(). If I put the
doGet() inside of doPost(), the seconde page appears on teh first page and I don't want it there!

You have a logical way of determining what the correct output should be. With Servlets it is pretty easy since the button that submits form data can have a unique name. A getParameter( "buttonName" ) returns null unless it is used to submit form data.

Originally posted by Michael Pearson:

To me it seems "procedural" to drive all of the activity into a single doXXX method. I'm not saying I have a preference, just sharing what I've noticed.

Procedural? How so?

Originally posted by Michael Matola:

Procedural? How so?

All depends on how the code is written.
If a servlet is set up as a Controller to forward to other Servlets/JSPs that is great.
When Servlet requests get forwarded from doGet and doPost to a single doXXX method there is a chance some "procedural" infrastructure will be created.
It's pretty easy to see:
(1) poor cohesion or
(2) tight coupling
creep into Servlet development if good OOAD is not used.
You know there are people in the "real world" that write applications like Servlet-5 in one Servlet without thinking twice about it. Just because Java is an OO language doesn't mean you can't create very procedural code.

Aha, I was wondering what you'd meant by that too. So it's the stuffing everything into one single doItAll that makes it procedural for you?

I still don't see how having doGet and doPost call doXXXX is procedural. If a person is going to stuff all there code into one method, then it doesn't really matter what that method is. A doXXXX method should still rely on helper classes and such.
By having doGet and doPost call a third method, you actually gain a design benefit. If you ever need one of the methods to handle things differently, you just change that method. If you place all of your code in doPost and then have doGet call it and later need to change what doPost does, you run into a little trouble.