What the hell ever happened to doGet() and doPost()?
For the frameworks that I know of or read about they all do a process similar an execute, or doAction, or executeAction, or something very similar where there is a single point of entry to do web processing within the Action. Very often you are left to do something like this within that execute method:
public void execute(HttpServletRequest request, HttpServletResponse response, ...) {
if (request.getMethod().equals("GET"))
{
//do some get stuff here....
}
if (request.getMethod().equals("POST"))
{
//do some post stuff here....
}
}
This type of code is usually embedded in the execute method. What happens if I want to just run the GET instructions from a POST request? Then you are left do some refactoring or even worse code copying!
GET and POST were obviously engineered for a reason. Maybe someone in blog land has a nice way to circumvent this, or even offer a framework that does this nicely, but until then I am still sticking with my old custom "framework".
That's it for my rant, and oh, P.S.
If anyone gives me the excuse that it's like that so that you can have an atomic single service at your disposal I am not going to buy it. That's what SLSB and/or facade patterns are used for. :)
Danno
Tue, 15 Jun 2004 08:03 PM GMT
What are the GET instructions of a POST request? You mean the query parameters that are passed along in the URL of a POST submission? Well you treat them as any kind of values that arrive at your action, it doesn't really matter if it's get or post, does it? I fail to see a real reason to make a distinction between GET and POST at the serverside. They have a lot of use to make a distinction between one-shot forms (POST) or permantent urls (GET) or to pass along a lot of data (POST) by entering them correctly in the html, that's where the differentiating handling ends imho though.
Tue, 15 Jun 2004 08:44 PM GMT
The Spring framework makes use of the semantic differences between a POST and a GET quite well.
Tue, 15 Jun 2004 09:58 PM GMT
I don't see the problem. If you needed to differentiate between GET and POST then just have the logic in separate methods and have execute() call those methods. I agree with Geert though that in most cases there is no reason to differentiate between a GET and a POST, hence the reason most frameworks don't.
Wed, 16 Jun 2004 01:14 AM GMT
Doesn't handling GET/POST differently in a single "action" make the application very fragile? Wouldn't it be better for these two different actions to be in two different action classes?
Wed, 16 Jun 2004 02:09 AM GMT
Anonymous, Have you ever had a case where you had the same URL which behaved differently for a GET request versus a POST request?
Wed, 16 Jun 2004 02:34 AM GMT
Anthony, I've had this a lot. The question is did it need to behave differently, and would it have been better if it didn't?
Wed, 16 Jun 2004 04:38 AM GMT
To answer your question anonymous. All the time, I always like to prepare my form (called from a GET) before displaying it. Then obviously retreive the results (from the POST) and do something with them. It would be a shame to have createAccountByGet action and a createAccountByPost action. When one action can (and should have) different roles. I would like a createAccount action, one that can setup my form and one that can retrieve entries.
Wed, 16 Jun 2004 07:21 AM GMT
I agree that it's very convenient to create a form and handle a form in the same object. This is actually one of the cornerstones of RIFE. I however think that it's not correct to rely on GET and POST to do this, since forms can be GET and anybody can change POST to GET and vice-versa. To me these are merely different ways to transport the data to the action. RIFE introduced the concept of a named submission, which means your element (action) is able to handle and generate multiple forms (quite common in admin interfaces and such). I agree also that a check for an incoming submission is not very clean, therefore I just added support for automatic execution of 'doSubmissionName()' to the RIFE svn repo. The next version will be released in a few days, so if you're interested, you can play with it then. Thanks for pointing this out and showing me that a handy last step was missing.
Wed, 16 Jun 2004 03:57 PM GMT
public void execute(HttpServletRequest request, HttpServletResponse response, ...) { if (request.getMethod().equals("GET")) { doGet(request,response); } if (request.getMethod().equals("POST")) { doPost(request,response) } }
Wed, 16 Jun 2004 07:01 PM GMT
Apache Cocoon has a pipeline component (RequestMethodSelector) which will trigger different sections based on the HTTP request method. I don't think doGet/doPost have gone away, I think the idea behind it has just been convieniently abstracted away.
Sat, 17 Sep 2005 02:01 AM GMT
null