Response.Redirect bad seed or just misunderstood

Question

Recently I posted a answer to a question that I thought was quite an easy one, The question was about issues with the lifecyle of the page in asp.net where items would only reflect the changes made after the first postback, so I suggested using

Response.Redirect(Request.RawUrl)

And almost instantly got voted down for this as (Why cause another round trip)

Well I want your suggestion, is this type of thing good practise, simply practical or should never be used, please back up your answer with a little motivation its something I do from time to time and now question if I should rethink it.

This is the original post http://stackoverflow.com/questions/987680/dynamically-change-user-control-in-asp-net/987727#987727

Answer 1

There is nothing inherently wrong with Reponse.Redirect, just in most cases it isn't required in that kind of situation. You can change the way the page is constructed by working with the lifecycle rather than against it. Then there shouldbe no need for another postback.

Answer 2

The ASP.Net page lifecycle provides plenty of opportunities to step in and set things up, so I don't see that it would be necessary to use Response.Redirect to make the client load the page twice.

As an aside, using Response.Redirect with just the one argument can throw a ThreadAbortException, so it's often best to use the overload Response.Redirect(string url, bool endResponse) with the second argument set to false. This definitely applies to ASP.Net 1.0 and 1.1 (see here), not sure about 2.0.

Answer 3

It seems like programming by coincidence, but much of ASP.net is that.

Answer 4

Another solution would be to use an UpdatePanel with an AutoPostBack DropDownList to switch the user controls, then that is only responsible for switching the user control, and when the main submit button (or other event) posts back the whole form, you can process all of the data.

UpdatePanels do update the local page ViewState, if you do it correctly.