Controller method: passing values via POST vs. signature

//method declaration
[AcceptVerbs(HttpVerbs.Post)]
public ActionResult Step2_UpdateCart(bool? isNextStepClicked)

//one of many of the view's fields processed by the method
<input type="hidden" name="isNextStepClicked" value="false" />

I'm reverse engineering a View/Controller set where a form within the view has a series of inputs that are passed via the Submit. One of the inputs is a hidden field - it's name is found in the method's signature - and is the only value found in the signature - the rest of the values come from the Request object.

I thought perhaps it might be开发者_Go百科 a case where the method could recursively call itself with a different value than the form carried but i don't see that happening anywhere.

Does this make any sense? (either my question or my code sample).

many thanx

---

You might find its better to take advantage of input models or the FormCollection type. With the first option, you get to define your properties, and MVC's default model binder will do its best to map them across. E.g.:

public ActionResult Step2_UpdateCart(UpdateCartInputModel model)

Where UpdateCartInputModel could be defined as:

public class UpdateCartInputModel {
    public bool? isNextStepClicked { get; set; }
    public bool? isSomeOtherPropertyClicked { get; set; }
}

With the FormCollection, MVC treats this as a special case and where an action accepts an instance of FormCollection it will fill it:

public ActionResult Step2_UpdateCart(FormCollection form)

With a FormCollection, you have to handle the type casting/conversion yourself.

I personally don't see any need to try and build some complex recursive controller action, when what you need could be accomplished doing either of the above.

---

I think you are asking "where is the parameter coming from?" and by parameter I mean the bool? isNextStepClicked signature parameter. There are three ways that a Controller ActionResult can be called to my knowledge.

The first is a straight call from another Action using RedirectToAction. The next is as listed above - from the form, where a control is declared with the same ID as your named parameter (e.g. gives a signature of public ActionResult ViewName (string information). Personally I find this irritating as I like to have all my code with the correct type of casing - but because most form ID's begin with an upper case, so do my signature parameters.

Thirdly, there is the straight constructor call. This is the worst as there is no way to trace it being called from the markup using Shift+F12 (find all usages). Some parameters can be named but not called. A controller doesn't need values for each parameter.

Hope this helps you. :-)