So today I ran into a something that seems like a bug to me. So here is the order of operations, first how they happened. 

Action:

[CaptchaValidation]
public void Login(string userName, string password, bool captchaValid)

The parameter captchaValid is set by the attribute in OnActionExecuting.  It is not derived from the URL.  It is added directly in to the RouteData.

However the Action refuses to execute stating that captchaValid needs to be nullable since there is no default for it set in the RouteData, at least not yet.  So an exception is thrown before OnActionExecuting is executed.  This forces me to change the parameter to bool? captchaValid, which is really not what I want.

This is what I imagine the current process is

1. Check parameters for defaults and throw error when not valid
   
2. Run OnActionExecuting
3. Pass parameters in to Action 

I think that the process should be the following to give me a chance to set defaults in the OnActionExecuting.

1. Run OnActionExecuting
2. Check parameters for defaults and throw error when not valid
3. Pass parameters in to Action

I would be interested to get this in the hands of the MVC team.

Thanks,

Nick 

+1 Great Idea,

All they'd have to do is move some code around inside Controller.InvokeActionMethod(IMethodInfo, RouteValueDicitionary) and put the Parameter Values inside the FilterExecutingContext for us to fudge with.

You're right about what happens.

If the method has an argument that isn't in the RouteData, or the QueryString, or the Form, it's deemed missing. If it does exist but you can't convert it to the corrent Type then it's deemed missing.

THEN it invokes the ActionFilters and THEN invokes the controller action.

PS. Not a bug. 

Just out of curiosity, assuming that the functionality you request is implemented, what would the Login() action do if captchaValid is false?  And is this result most logically associated with the CaptchaValidation filter or with the Login() method?  That is, which of the two should effect the outcome?

I can't speak for nberardi but I don't see that as important.

If in his example, captchaValid doesn't mean anything to the Login action, then the obvious solution is just to remove the argument.

However, from the code that he refers to, it seems to be setting it to either true or false and letting the action handle it, so it's less of a CaptchaValidation and more or a CaptchaReader or something like that. (not happy with "reader", naming is that hardest part of computer science)

Even if that's not the case, the feature is still a great idea!. You can use it to do your own string > object deserialization, add per-action default route parameters, dependency injection. There's a wealth of opportunity here that i'm sure people will take advantage of.

Nice idea. We are definitely looking into this. I think this makes sense for example if I wrote an action filter that logs errors, I would want it to run even if calling the action failed.

tgmdbm:

However, from the code that he refers to, it seems to be setting it to either true or false and letting the action handle it, so it's less of a CaptchaValidation and more or a CaptchaReader or something like that. (not happy with "reader", naming is that hardest part of computer science)

How about CaptchaVerification.  I am with you good naming is probably the hardest part of Computer Science.

Well I originally stumbled on to this possibility when I was using the previous version of MVC.  It worked in that version, that is why I thought it was a bug. Because the ability was removed.

The decorating of the Action Method, with the attribute, seemed like such a natural way to encapsulate an operation that I was going to need to do for specific forms.  And honestly I didn't really care about the process, or the random text from the CAPTCHA that was being posted back, all I cared about was the outcome or the verification of the CAPTCHA text. 

I really hope you can intigrate this in to the next refresh.