TempData[“message”] isn't reliable— what am I doing wrong?

Question

I'm using TempDate["Message"] to show little update banners as the user does things on my site like this:

[AcceptVerbs(HttpVerbs.Post), Authorize(Roles = "Admins")]
public ActionResult Delete(int id)
{
    _Repo.DeletePage(id); // soft-delete

    TempData["Message"] = "Page deleted!";
    return RedirectToAction("Revisions", "Page", new { id = id });
}

Then in my master page I have this:

<%-- message box (show it only if it contains a message) --%>
<% string Message = (TempData["Message"] ?? ViewData["Message"]) as string; 

   if(!string.IsNullOrEmpty(Message)){
       %>
       <div id="message"><%:Message %></div>
   <% }

   TempData["Message"] = null; ViewData["Message"] = null; %>

I hit both TempData and ViewData because I read somewhere that TempData should be used for redirects and ViewData should be used otherwise.

The issue is: often the message won't show up right away. Sometimes it takes a click or two to different parts of the site for the message to show up. It's very strange.

Any ideas?

Answer 1

You should verify all places where you use TempData["Message"] in your code. Corresponds to ASP.NET MVC does browser refresh make TempData useless? you can read TempData["Message"] only once (see also http://forums.asp.net/p/1528070/3694325.aspx). During the first uage of TempData["Message"], the TempData["Message"] will be deleted from the internal TempDataDictionary.

Probably it would be better to use TempData["Message"] only inside of Revisions action of the Page controller and not inside of master page or inside a View.

Answer 2

TempData is not intended to pass data to views, hence the name ViewData for that purpose. In fact, I can't think of a reason to use TempData from within a view definition at all...

One very common usage of TempData is the passing of information between controller actions when you do a redirect (the Revisions action in your example above, for instance, would be able to make use of your TempData["Message"] variable).

This is common practice in the PRG means of coding MVC interactions (Post-Redirect-Get) since you often need to pass information from the initial target action when doing the Redirect to the Get. An example of how this might be useful in a Get is below where I often just default to a new viewmodel UNLESS there is one already passed from a redirect in TempData:

public ActionResult System() {
   SystemAdminVM model = (SystemAdminVM)TempData["screenData"] ?? new SystemAdminVM();

One more thing; I see you explicitly clearing your TempData and ViewData dictionary entries in your view. You don't need to do that as by that point they are at the end of their life spans anyway...

Happy coding!

Answer 3

Your app's behavior is the one you'd expect if you're using TempData where you should be using ViewData.

You want to double-check that you're storing your status feedbacks in TempData only when the controller does a re-direct. Otherwise, you should use ViewData.

Answer 4

This smells like you need a couple of unit tests to confirm the behavior you're seeing. Try writing up a couple using this example as a starting point:

http://weblogs.asp.net/leftslipper/archive/2008/04/13/mvc-unit-testing-controller-actions-that-use-tempdata.aspx

Answer 5

If you have configured multiple worker process for your application, but session state mode is "InProc", then you can't use default TempData implementation, as session state becomes unusable. (see ASP.NET session state and multiple worker processes)

You could try to use MvcFutures CookieTempDataProvider instead.