I have a View where the user enters in a bunch of info that they want to post to the database. Upon submitting the form, the information is validated, and then the user is taken to a Confirmation page, where they can see the information that is about to be posted. The problem is, the confirmation page is nothing but text; so when they submit that View, nothing will be passed to the controller. The controller has no way of knowing what information the user entered 2 views ago.

I know that one option is to put hidden fields on the confirmation page to hold all the information that the user entered; but I was wondering / hoping that there was some sort of MVC way of dealing with this... I would think that having a confirmation page in between the user entering information and the database being updated would be a common issue.

You could use TempData.

Much depends on the design of your application.

TIMTOWTDI =. there is more than one way to do it.

Example:

In an application I've done, once the user successfully
registers, I take her/him to a pending page where
I say confirmation needs to be done based on an
e-mail.  The e-mail has an excrypted key that allows
me to confirm the user.  On confirmation, I take
the user to the home page.  I let the unconfirmed
user log an but do not allow any actions that
require authentication.  In pseudo code:
    logged in + not confirmed,
        to page stating confirmation is
          required.

What I do may not work for you.
I do not know the details of your
requirements.  I also do not know
what you are confirming.  Nevertheless,
TempData would probably work for you.

In North American football terms,
it would be like a double handoff,
your first page sets up the
TempData for your confirmation page
and your confirmation page sets it up
again for the next page.  TempData
is temporary and does not hang around
very long.

http://msdn.microsoft.com/en-us/library/system.web.mvc.tempdatadictionary.aspx

gerry

Thanks, I didn't know until now that TempData would stay around when the View was rendered and then posted back; I thought it was only good for passing data directly from one actionMethod to another. That should work great!

Absolutely do not use TempData for this.  The easiest thing to do would be to shove it into Session (if Session is enabled).  Otherwise use hidden input fields or the Html.Serialize() helper from Futures.

Thanks to Levi for answering this.

The link redirected me to the Wiki HTTP article. What is wrong with using TempData for this?

Rick, like crawford.r, I ask why?

Your Levi link http://forumhttp//forums.asp.net/members/levib.aspxs.asp.net/members/levib.aspx
is a badly mangled and broken link.

Also, I challenge you on Session ... you even have to say "if Session is enabled".

On Windows 2008 R2 Server (at least the Web Edition),
Microsoft has chosen NOT to enable Session by default.

I am not in any way claiming to be an expert .... however,
ASP.NET MVC is supposed to be RESTful and I get the feeling
that using Session actually makes (or at least tends to make)
ASP.NET MVC un-RESTful.

Please clarify.

Thank you.

Regards,
Gerry (Lowry)

Hidden form fields is the right answer for scalability reasons.

TempData is the wrong reason because if the user refreshes the confirmation page, then the TempData will be destroyed.

Also, if Session is disabled, then the default TempData provider is also broken (since it's based on session).

Brad,

Is session different than ASP.NET State Service?
On my server, ASP.NET State Service is stopped
but my TempData works perfectly.

g,

http://msdn.microsoft.com/en-us/library/ms178586.aspx 

StateServer mode stores session state in a process, referred to as the ASP.NET state service, that is separate from the ASP.NET worker process or IIS application pool. Using this mode ensures that session state is preserved if the Web application is restarted and also makes session state available to multiple Web servers in a Web farm.

To use StateServer mode, you must first be sure the ASP.NET state service is running on the server used for the session store. The ASP.NET state service is installed as a service when ASP.NET and the .NET Framework are installed. The ASP.Net state service is installed at the following location:

StateServer mode stores session state in a process, referred to as the ASP.NET state service, that is separate from the ASP.NET worker process or IIS application pool. Using this mode ensures that session state is preserved if the Web application is restarted and also makes session state available to multiple Web servers in a Web farm.

To use StateServer mode, you must first be sure the ASP.NET state service is running on the server used for the session store. The ASP.NET state service is installed as a service when ASP.NET and the .NET Framework are installed. The ASP.Net state service is installed at the following location:

Also see  http://technet.microsoft.com/en-us/library/cc732412(WS.10).aspx

Ok, I started to move the information to HiddenFields, but then I realized another issue... TempData was already being used to pass the data from the first page's POST method to the Confirmation GET method... and, the Confirmation GET method was re-setting the TempData so that if the user refreshed the Confirmation screen, it would still be there. But I just realized that this is the same as the solution Gerry mentioned... the TempData is still there on the Post, so the hidden fields are just redundant now.

Is there any other way to pass information from one POST action to another GET action (I'm currently using RedirectToAction())? I know I could pass the data in the RouteValues; but it's a lot of data, and would make for a long and complicated URL... So if I were to avoid using TempData, how could I get the information to the Confirmation GET method?

Thanks.