Retrieving values from TempData

94 views
Skip to first unread message

Chad Lee

unread,
Sep 14, 2009, 12:52:25 PM9/14/09
to Spark List
I noticed that using <viewdata whatever="whatever" /> doesn't work when the "whatever" you are trying to retrieve is in TempData.  Is this a bug or was it designed this way?

If this is by design, I think it would be useful to change the semantics of that call to retrieve values from TempData as well as ViewData (with a priority on ViewData).  Thoughts?

zihotki

unread,
Sep 14, 2009, 1:10:37 PM9/14/09
to Spark View Engine Dev
I don't think that usage of TempData in views is a good idea. IMO,
views should use data from ViewData only. And all necessary data for
the view should be added to the ViewData. Views should know nothing
about TempData at all, it's a responsibility of a controller. You just
need to copy all necessary data from TempData to ViewData. See
TempDataToViewDataAttribute.cs in MvcContrib project (
http://code.google.com/p/mvccontrib/source/browse/trunk/src/MVCContrib/Filters/TempDataToViewData.cs
) for example.

Chad Lee

unread,
Sep 14, 2009, 1:17:23 PM9/14/09
to spar...@googlegroups.com
I don't think that usage of TempData in views is a good idea.

Why not?  The controller is still populating that collection of data.  I don't think it really makes a difference whether you get it from ViewData or TempData.

I didn't know about that attribute in MvcContrib -- but still, I'd rather not have to decorate my controller with an arbitrary attribute just to support this scenario.

The reason I was expecting this behavior is that I was using Spark with Monorail before, and the <viewdata /> element in the Monorail Spark engine pulls from PropertyBag and Flash (equivalent of ViewData and TempData) and I don't see why it should be different for the MVC engine.

Louis DeJardin

unread,
Sep 14, 2009, 1:30:52 PM9/14/09
to spar...@googlegroups.com
The difference there comes down to a when-in-rome type of thing... The monorail view engine was following nvelocity's implementation about which collections, and what order, the names resolve out of. The mvc view engine on the other hand relies on the fwk's Eval method that resolves any tmodel properties or vd dictionary key values.   


On Sep 14, 2009, at 10:17 AM, Chad Lee <chad...@gmail.com> wrote:

Vasili Puchko

unread,
Sep 14, 2009, 1:32:39 PM9/14/09
to spar...@googlegroups.com
Inlines,

2009/9/14 Chad Lee <chad...@gmail.com>

I don't think that usage of TempData in views is a good idea.

Why not?  The controller is still populating that collection of data.  I don't think it really makes a difference whether you get it from ViewData or TempData.

TempData is responsible for keeping some data between current and next request. ViewData is responsible for transfering data to views. Controller is responsible for putting all necessary data for views. Just simple Separation of Concerns (SoC). Views should know nothing about architecture of the project.
 

I didn't know about that attribute in MvcContrib -- but still, I'd rather not have to decorate my controller with an arbitrary attribute just to support this scenario.

The reason I was expecting this behavior is that I was using Spark with Monorail before, and the <viewdata /> element in the Monorail Spark engine pulls from PropertyBag and Flash (equivalent of ViewData and TempData) and I don't see why it should be different for the MVC engine.

I have no experience with Monorail, but it seems to me that it's not a good idea to let a view to know too much.
 

On Mon, Sep 14, 2009 at 12:10 PM, zihotki <zih...@gmail.com> wrote:

I don't think that usage of TempData in views is a good idea. IMO,
views should use data from ViewData only. And all necessary data for
the view should be added to the ViewData. Views should know nothing
about TempData at all, it's a responsibility of a controller. You just
need to copy all necessary data from TempData to ViewData. See
TempDataToViewDataAttribute.cs in MvcContrib project (
http://code.google.com/p/mvccontrib/source/browse/trunk/src/MVCContrib/Filters/TempDataToViewData.cs
) for example.

On Sep 14, 7:52 pm, Chad Lee <chadl...@gmail.com> wrote:
> I noticed that using <viewdata whatever="whatever" /> doesn't work when the
> "whatever" you are trying to retrieve is in TempData.  Is this a bug or was
> it designed this way?
>
> If this is by design, I think it would be useful to change the semantics of
> that call to retrieve values from TempData as well as ViewData (with a
> priority on ViewData).  Thoughts?







--
With best regards,
Vasili Puchko

j...@indev.be

unread,
Mar 9, 2015, 1:56:23 PM3/9/15
to spar...@googlegroups.com, zih...@gmail.com
There is no issue or breach in using TempDataDictionary instead of the ViewDataDictionary, the only difference will be the "lifetime" of the variables.

You can use it in Spark just by accessing the TempData variables ${TempData["myKey"]}

It might be very useful for validation or info messages.

Lets say i've got a controller with the following actions:

public ActionResult List()
{
    ViewData["List"] = MyDbContext.GetMyList(); // or ViewBag.List =;
    return View();
}

public ActionResult Edit(Guid id) {
    return View(Models.GetMyModel(id));
}

public ActionResult Update(MyModel model) {
    If(!ModelState.IsValid) {
         ViewData["Error"] = "Invalid model";
        return View("Edit", model); // Returning a ViewResult ? You can use th viewdata, its fine.
    }
    TempData["Info"] = "Update succesful";
    return RedictToAction("List"); // By returning a RedirectToActionResult, the ViewData will not be accessible, you shoud use TempData instead
Reply all
Reply to author
Forward
0 new messages