ASP.NET MVC

Re: View bug in preview 4 (worked fine in preview 3)

Haacked — Fri, 15 Aug 2008 15:24:26 GMT

Ah right, I believe that will change.

Re: View bug in preview 4 (worked fine in preview 3)

SteveSanderson — Fri, 15 Aug 2008 09:40:26 GMT

Haacked:
By the way, you can shorten that to this:
<%= Html.TextArea("MyText")  %>

Not in preview 4 - TextArea() doesn't have an overload that takes only one parameter.

Is this something being changed in the next release?

Re: View bug in preview 4 (worked fine in preview 3)

Haacked — Fri, 15 Aug 2008 02:49:05 GMT

By the way, you can shorten that to this:

<%= Html.TextArea("MyText")  %>

Re: View bug in preview 4 (worked fine in preview 3)

Nullable — Thu, 14 Aug 2008 12:58:04 GMT

http://weblogs.asp.net/stephenwalther/archive/2008/08/13/asp-net-mvc-tip-32-repopulate-form-fields-with-viewdata-eval.aspx

Re: View bug in preview 4 (worked fine in preview 3)

Luis Abreu — Tue, 22 Jul 2008 10:46:22 GMT

Hello again. I'm using something similar to the approach I've mentioned in my current app. It has increased logic in the controller in order to get the "correct object" that is passed to the viewdata.model property, but I hhaven't really had any problems with it til now... I'll try to reuse your approach to see how it feels like...

Re: View bug in preview 4 (worked fine in preview 3)

Sgro — Tue, 22 Jul 2008 10:39:56 GMT

It's arguable. Though the view is responsible only of showing received data, I'm not so sure that it is not its concern to display the correct data in an ambigous scenario like preserving user input on a failed post. That little "Eval" method saves me from passing each single value back and forth between ViewData dictionary and ViewData.Model, and saves me to write a specific action method to handle failed posts, so in my opinion it's a good thing.

Think about it: if we couldn't do that, we would have to pass evetytime all data to the dictionary, even on first request, making ViewData.Model totally useless. In fact, you couldn't use it in any way.

Re: View bug in preview 4 (worked fine in preview 3)

Luis Abreu — Tue, 22 Jul 2008 10:15:58 GMT

Hello again. yes, I understand that. but when you do that, you're making your view a little more intelligent than it needs to be. or am I seeing it incorrectly?

Re: View bug in preview 4 (worked fine in preview 3)

Sgro — Tue, 22 Jul 2008 10:04:01 GMT

It does, but this is exactly the logic of the ViewData.Eval method that solved the problem.

Re: View bug in preview 4 (worked fine in preview 3)

Luis Abreu — Tue, 22 Jul 2008 09:05:10 GMT

Hello again Matteo. Ok, so what you're telling me is that you might end up adding each property two times because you might add an object to the viewdata.model property and then you might have also add an entry to the viewdata dic whose key is the name of the property and in this case the value comes frmo the tempdata property. is this correct? if it is, then what I'm saying is that you could change your controller logic so that it only passes the object assign to the viewdata.model. what you must do is make sure that the object you're passing is correclty filled, which means that in some scenarios you'll get it from a db and in another you'll get it from tempdata. In practice this means that you'd probably star by checking the tempdata and if it's null you need to get the item from somewhere else (probably from the db). does this make sense?

Re: View bug in preview 4 (worked fine in preview 3)

Sgro — Mon, 21 Jul 2008 23:30:23 GMT

One little thing before the example: in another post I got the solution. Simple use ViewData.Eval("MyField") to get the desired behaviour. Now for the example...

Here's a brief example using only 1 field. As for the view:

<%= Html.TextArea("MyText", ViewData["MyText"]) %>

In the controller,the actionmethod that is used to create a new record:

public ActionResult CreateNew()

{

return View("MyEditView");

}

the method for updating an existing record:

public ActionResult EditExisting(String id)

{

//loop through tempdata and assign any values from it to viewdata equivalents, so if we come here by an error in the SaveData method, we still have the user input

//get the item from LINQ to SQL using the specified ID

ViewData.Model = retreiveditem;

return View("MyEditView");

//note: in the perfect scenario, the view will render everything from ViewData.Model except for data present in ViewData dictionary, so user input (if we come from a SaveData error) takes priority on database data

}

and the actionmethod called with POST:

public ActionResult SaveData(String MyText)

{

//try to save the data, if ok return success view

//in case of error or invalid user input, memorize MyText in TempData["MyText"] and redirect to EditExisting method

}

This example should make it all clear. As stated above, the use of ViewData.Eval("varname") solves it, so I think further debate is pointless.

Re: View bug in preview 4 (worked fine in preview 3)

Luis Abreu — Mon, 21 Jul 2008 21:11:03 GMT

Hello again. there's one thing I'm not getting: how are you filling the info that is being passed to the view? can you put some demo code for all the scenarios? After seeing it I'll try to explain what I'm saying... thanks!

Re: View bug in preview 4 (worked fine in preview 3)

Sgro — Mon, 21 Jul 2008 18:43:17 GMT

Luis, the reason is clearly explained in my second post. Read it carefully :)

Re: View bug in preview 4 (worked fine in preview 3)

Luis Abreu — Mon, 21 Jul 2008 18:12:25 GMT

Hello again guys. Maybe I'm not following then. In my 2 or 3 experiences with MVC, I always use a strongly typed view. So I always get the the data from the model property (ie, the values passed to control alwas come from the model property). Since I really haven't used any of the previous versions, can any of you guys tell me why it's so important to make the helpers trye to get a value from the dictionary syntax and then from the model property? I mean, with the current release, the helpers aren't doing any "guessing" and this seems fine to me, but maybe I'm wrong... maybe a specific example would help me understand why the previous behavior is better? thanks.

Re: View bug in preview 4 (worked fine in preview 3)

levib — Mon, 21 Jul 2008 16:38:53 GMT

Luis - I don't follow. The controller is already responsible for populating the ViewData, and the view is responsible for consuming it.

Re: View bug in preview 4 (worked fine in preview 3)

Luis Abreu — Mon, 21 Jul 2008 14:16:13 GMT

Hello again. I have a different perspective here...I say that the view and the helpers shouldn't really do that. They should only receive the data they need to show. what I'm saying is that the controller should always be responsible for passing the *correct* data to the view, ie, you should have a specific view object (I prefer to use a strongly typed approach instead of the dictionary approach) which is filled by the controller with the correct values (which should cover inserts, updates deletes or whatever scenario you have). In fact, by putting that responsibility in the controller, you can really increment the testing range of your app...