Last post Mar 19, 2008 05:56 PM by nberardi
Mar 17, 2008 10:48 PM|nberardi|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.
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
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.
Mar 18, 2008 12:42 AM|tgmdbm|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.
Mar 18, 2008 12:43 AM|tgmdbm|LINK
PS. Not a bug.
Mar 18, 2008 04:57 AM|levib|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?
Mar 18, 2008 05:32 AM|tgmdbm|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.
Mar 19, 2008 02:51 AM|Haacked|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.
Mar 19, 2008 05:56 PM|nberardi|LINK
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.