A redirection causes the browser to submit an entirely new HTTP request, which means that we don’t have access to the details of the original request. If we want to pass data from one request to the next, we can use the TempData feature.
TempData is similar to Session data, except that TempData values are marked for deletion when they are read and removed when the request has been processed. This is an ideal arrangement for short-lived data that we want to persist across a redirection. Here is a simple example in an action method that uses the RedirectToAction method:
public RedirectToRouteResult Redirect() { TempData["Message"] = "Hello";
TempData["Date"] = DateTime.Now;
return RedirectToAction("Index");
}
When this method processes a request is sets values in the TempData collection and then redirects the user’s browser to the Index action method in the same controller. We can read the TempData values back in the target action method and then pass them to the view, like this:
public ViewResult Index() {
ViewBag.Message = TempData["Message"];
ViewBag.Date = TempData["Date"];
return View();
}
A more direct approach would be to read these values directly in the view, like this:
@{
ViewBag.Title = "Index";
}
<h2>Index</h2>
The day is: @(((DateTime)TempData["Date"]).DayOfWeek)
<p />
The message is: @TempData["Message"]
Reading the values in the view means that we don’t have to use the view bag or view data in the action method, but it does mean that we have to cast the TempData results to an appropriate type.
We can get a value from TempData without marking it for removal by using the Peek method, like this:
DateTime time = (DateTime)TempData.Peek("Date");
We can preserve a value that would otherwise be deleted by using the Keep method, like this:
TempData.Keep("Date");
The Keep method doesn’t protect a value forever – if it the value is read again, it will be marked for removal once more. If you want to store items so that they won’t be removed automatically, then you should use session data instead.
Returning Text Data
In addition to HTML, there are many other text-based data formats that you might want your web application to generate as a response, these include: XML, RSS and ATOM (which are specific subsets of XML), JSON (usually for AJAX applications), CSV (for exporting tabular data) and, of course, just plain text.
The MVC framework has specific support for JSON, which we will show you shortly.
For all of the other data types, we can use the general purpose ContentResult action result.
Listing 24 provides a demonstration.
Listing 24. Returning text data from an action method public ContentResult Index() {
string message = "This is plain text";
return Content(message, "text/plain", Encoding.Default);
}
We create ContentResult through the Controller.Content helper method, which takes three parameters. The first is the text data that we want to send. The second is the value of the HTTP content-type header for the response – you can look these easily or use the
System.Net.Mime.MediaTypeNames class to get a value – for plain text the value is text/plain. The final parameter specifies the encoding scheme that will be used to convert the text into a sequence of bytes.
We can omit the last two parameters, in which case the framework assumes that the data is HTML (which has the content type of text/html) and will try to select an encoding format that the browser has declared support for when it made the request we are processing. This allows us to just return text like this:
return Content("This is plain text");
In fact, we can go a little further – if you return any object from an action method that isn’t an ActionResult, the MVC framework will try to serialize the data to a string value and send it to the browser as HTML – as shown in Listing 25.
Listing 25. Returning a non-ActionResult object from an action method public object Index() {
return "This is plain text";
}
You can see how the result is displayed in the browser in Figure 4. It is worth noting that we are returning a plain text that the browser will be told is HTML. Fortunately, most browsers are smart enough to recognize that our data doesn’t contain HTML elements and treat it as plain text, as shown in Figure 4.
Figure 4. A browser displaying plain text that we delivered with a content type value of text.html
Although this usually works, it is not something we recommend you rely on, and it is good practice to specify the correct content type for the data you are producing.