views:

1568

answers:

6

I know, I know, I know. I shouldn't be doing webforms inside of MVC, I completely agree. But, the people who sign my paycheck will not approve a complete conversion of our site to MVC right now. So I am taking incremental steps, page by page, to convert them over while adding new features in MVC.

So my question is how can I access the IsPostBack property from a controller?

Edit: To further clarify, I have a webform user control on my mvc master page which can initiate postbacks. I'm trying to identify these postbacks verses an mvc post. At this point I think I am going to just check the request form keys for a "__viewstate" key and if its found treat it as a postback.

+2  A: 

Controllers do not inherit from System.Web.UI.Page. There is no isPostback property.

Chad Ruppert
ASP.NET View Engine Views do inherit from Page.
Mehrdad Afshari
I stand corrected. Views do. Controllers don't.
Chad Ruppert
A: 

The MVC framework doesn't support the classic postback and viewstate used in the Web forms. So, no, you don't have access to the IsPostBack.

My advice to you is to have two branches: one with the current site where you're adding patches for known errors and another one where you build a new site from scratch. New features should be implemented in this one. I assume that most of your codebase is re-usable in the new site.

When the new site is ready, put it in production.

Rodrigo Guerreiro
+6  A: 

There is no IsPostBack -- everything is either a POST or GET (or other HTTP verb). You can limit the HTTP verbs that your action allows, i.e., you'll never see a request from a disallowed verb, using the AcceptVerbsAttribute. For example, the following only allows POSTs.

  [AcceptVerbs( HttpVerbs.Post )]
  [ValidateAntiForgeryToken]
  public ActionResult Update( int id )
  {
  }

If you need to have the same action name do both GET/POST and they actually do different things, you can either give them separate signatures or use the ActionNameAttribute to alias one of the actions so the methods can have different names.

  [AcceptVerbs( HttpVerbs.Get)]
  public ActionResult List()
  {
  }

  [AcceptVerbs( HttpVerbs.Post )]
  [ValidateAntiForgeryToken]
  public ActionResult List( string filter, int page, int limit )
  {
  }

OR

  [ActionName( "List" )]
  [AcceptVerbs( HttpVerbs.Get)]
  public ActionResult ListDisplay()
  {
  }

  [AcceptVerbs( HttpVerbs.Post )]
  [ValidateAntiForgeryToken]
  public ActionResult List()
  {
  }

EDIT: Note that I've added the antiforgery token validation to the POST actions. You really should be using this to protect against cross-site scripting attacks.

tvanfosson
Actually there are still post backs when mixing mvc and webforms pages. See my edit above.
chief7
A: 

Why are you trying to get that value from within a controller? Not sure if this will help you, but you can still use the traditional Request object to get info that was submitted by a form...

Luis Abreu
See edit above.
chief7
A: 

I'm not sure if I understood your question correctly, but on the controller you would have an action that handles the initial GET from the browser and a second action to handle POSTs.

 [AcceptVerbs(HttpVerbs.Post)]
 public ActionResult Create(MyModel model)
 {...}

 public ActionResult Create()
 {...}
Nate
A: 

I would definitely take a look at this blog post by Scott Hanselman where he puts an aspx page in a MVC application.

http://www.hanselman.com/blog/PlugInHybridsASPNETWebFormsAndASPMVCAndASPNETDynamicDataSideBySide.aspx

Your controllers will not have access to the ViewState property. Even if you did want to handle the problem of __VIEWSTATE, you would have to do some work in order to get it into a usable form in an mvc controller. Good luck on coming up with a conversion strategy, no matter how it works out a lot of people would be interested to know kind of problems you would face in the process.

Min