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
Check parameters for defaults and throw error when not valid
Run OnActionExecuting
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.
Run OnActionExecuting
Check parameters for defaults and throw error when not valid
Pass parameters in to Action
I would be interested to get this in the hands of the MVC team.
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.
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.
Phil Haack (http://haacked.com/)
Senior Program Manager, Microsoft
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.
Marked as answer by nberardi on Mar 19, 2008 10:07 PM
nberardi
Star
11233 Points
2352 Posts
BUG: Order of opperations in Action parameter validation seems wrong.
Mar 18, 2008 02:48 AM|LINK
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:
The source to CaptchaValidationAttribute is at http://code.google.com/p/coderjournal/source/browse/trunk/ManagedFusion.Web.Captcha/ManagedFusion.Web.Captcha/CaptchaValidationAttribute.csThe 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
I think that the process should be the following to give me a chance to set defaults in the OnActionExecuting.
I would be interested to get this in the hands of the MVC team.
Thanks,
Nick
tgmdbm
Contributor
4392 Points
883 Posts
ASPInsiders
MVP
Re: BUG: Order of opperations in Action parameter validation seems wrong.
Mar 18, 2008 04:42 AM|LINK
+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.
tgmdbm
Contributor
4392 Points
883 Posts
ASPInsiders
MVP
Re: BUG: Order of opperations in Action parameter validation seems wrong.
Mar 18, 2008 04:43 AM|LINK
PS. Not a bug.
levib
Star
7702 Points
1099 Posts
Microsoft
Re: BUG: Order of opperations in Action parameter validation seems wrong.
Mar 18, 2008 08:57 AM|LINK
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?
tgmdbm
Contributor
4392 Points
883 Posts
ASPInsiders
MVP
Re: BUG: Order of opperations in Action parameter validation seems wrong.
Mar 18, 2008 09:32 AM|LINK
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.
Haacked
Contributor
6901 Points
412 Posts
Re: BUG: Order of opperations in Action parameter validation seems wrong.
Mar 19, 2008 06:51 AM|LINK
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.
Senior Program Manager, Microsoft
What wouldn’t you do for a Klondike bar?
nberardi
Star
11233 Points
2352 Posts
Re: BUG: Order of opperations in Action parameter validation seems wrong.
Mar 19, 2008 09:56 PM|LINK
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.