Get Help:Ask a Question in our Forums|Report a Bug|More Help Resources
Last post Oct 30, 2009 03:46 PM by crawford.r
Oct 28, 2009 05:47 PM|LINK
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.
Oct 28, 2009 08:39 PM|LINK
You could use TempData.
Much depends on the design of your application.
TIMTOWTDI =. there is more than one way to do it.
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
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
Oct 28, 2009 09:13 PM|LINK
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!
Oct 28, 2009 09:33 PM|LINK
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.
Oct 28, 2009 09:44 PM|LINK
The link redirected me to the Wiki HTTP article. What is wrong with using TempData for this?
Oct 28, 2009 09:53 PM|LINK
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.
Oct 28, 2009 10:09 PM|LINK
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).
Oct 29, 2009 12:31 AM|LINK
Is session different than ASP.NET State Service?
On my server, ASP.NET State Service is stopped
but my TempData works perfectly.
Oct 29, 2009 02:35 AM|LINK
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:
Oct 29, 2009 03:00 AM|LINK