--
You received this message because you are subscribed to the "Community for ASP.NET MVC" group.
To post to this group, send email to c4...@googlegroups.com
To unsubscribe from this group, send email to
c4mvc+un...@googlegroups.com
For more options, visit this group at
http://CommunityForMvc.Net
That's correct. If it's not in the HTTP form post, it will not (cannot) be
bound to the controller action parameter.
To use MVC you will get the farthest by understanding how MVC interacts with
HTTP. The first thing to understand is that HTTP is stateless. That is,
once your app sends a response to the browser it has forgotten everything.
As far as it knows, no model ever existed and no response was ever sent.
When the user then submits the form, the browser sends an HTTP post request
to the server. MVC looks at this request and finds the right controller
action. Then it looks at the parameters to that action and uses parts of
the request (URL, query string, HTTP form) to instantiate those parameters.
If the parameter is a complex type, the binder will instantiate it and try
it's best to populate every writable public property. Typically it finds
what it needs in the HTTP form, which is a simple name-value collection of
strings. Properties that cannot be found in the form will be left with their
default values.
So yes, you have to take care of keeping state across request-response.
Putting all values that you care about in the form is one way to do it.
Values that the user does not need to see can be put into hidden element.
There are other ways, most of them bad.
The hardest part of learning MVC is unlearning WebForms. WebForms attempted
to make the web seems stateless while hiding HTTP from the developer. It
did this with viewstate and a complex "page lifecycle." This includes the
idea of "postback." The term postback implies that state is kept from
response to request, so I avoid using it in the context of MVC. I just say
"post" which is an HTTP verb that has nothing to do with ASP.
At first, handling state yourself can seem like an awful burden. But pretty
quickly you love getting closer to HTTP and shedding the abstractions of
WebForms, which many find to cause more headaches than it cures.
To deepen your understanding of this stuff, you might want to Google "MVC
model binding" and "MVC request lifecycle".
Tim Scott
>> Vis sitert tekst