views:

160

answers:

4

Hello, I have an ASP.NET MVC application, with a view that submits form values via POST. When my controller action method receives the POSTed data it only does server side things with it, no need for feedback to the client side.

However I am required to return an ActionResult. If I return null or EmptyResult, the page becomes blank after the form is submitted. I could return the View, but it is pretty 'expensive' to build, so I wonder if there is a way to simply have the values POSTed and then NOT have the browser expect anything in return?

+2  A: 

You should consider posting the form using AJAX techniques like jquery.post.

Mehrdad Afshari
A: 

Traditional POST action is a command for the browser to send data AND RECEIVE something back. Consider using ajax techniques as elegant and quite easy solution.

edit: POST should not return an html content response! It should just post data then redirect to GET a new page (could be the same url)

twk
+3  A: 

Consider using ajax to post the data. You can do it easily with jQuery or the built in MVC ajax stuff.

Or, just redirect to another page (perhaps the same one?) in your post handler. This is probably the desired approach anyway; if someone refreshes the page after they fill out a form, they won't be presented with the resend-the-form dialog. This is known as the Post-Redirect-Get Pattern (or PRG).

swilliams
+2  A: 

A POST (or even a GET) request by the client implies that the client expects a response back from the server. If the client gets an empty reply, it will display an empty page. There is no way around this with any framework you use on the client side.

However, as other have noted you have some options:

  1. You can use an Asynchronous POST (via AJAX) to send your POST request to the server side. This way the client does send a POST request and does expect a response back, but this does not affect the page the client is on. The whole thing is done on another thread, so to speak, thus it does not matter if you don't return a response. You can look into using the jQuery client-side library that is bundled with the MVC package to do this easily.

  2. You can use the Post-Redirect-Get pattern. In this method, the client will do the POST request and wait for a response. However, your POST handling action method will not return a concrete answer but will return a RedirectResult to the GET handling action method, thus the client will request that and wait for its response, in turn, the GET handling action method will contruct the view and return it. The client, in return, will display that view.

    However, I believe your View generation logic is expensive, thus you don't want to keep generating it again and again. One of the options available to you in this case is to use server-side output caching to cache the View output from the GET handling method. This way, even if you use the Post-Redirect-Get pattern, you would not be reconstructing your Views again and again.

Now let me quickly go over the Pros and Cons of each alternative.

Pros:

  1. Easy to implement; much less traffic to and from the client; the client page does not keep reloading.
  2. Works in all browsers equally well; if your view later needs to change in response to your POST request, it will be easier to integrate that in this pattern.

Cons:

  1. Needs JavaScript enabled (and compliant) in the client (this might be a problem if you are targeting mobile devices); harder to debug and maintain since you are spreading logic on separate layers.
  2. Much more chatty, ie. more traffic to and from the client; you need to fine-tune the output caching method so that you don't end up serving stale (or even wrong) content.
paracycle