Obviously not.

This second part of this post gets in depth as to what's going on with the MicrosoftMvcValidation script, but to save you some time, I'll post the solution first.

To manually validate your form with MicrosoftMvcValidation.js:

In MicrosoftMvcValidation.js, change line 20 from:

return Sys.Mvc._ValidationUtil.$0($2.validate('submit'));})); return $2;

to

return Sys.Mvc._ValidationUtil.$0($2.validate('submit'));})); $0.MvcValidationFormContext = $2; return $2;

Alternately, if you're using the debug version of the script, you can achieve the same effect by adding the following to line 196 (the end of the _parseJsonOptions function):

formElement.MvcValidationFormContext = formContext;

UPDATE: As Morten Christiansen points out in the comments, there is a much cleaner way of accessing the FormContext object, without having to introduce a custom tracking property and modifying the script. Instead of a custom property, we can just use
$('form')[0]['__MVC_FormValidation']. Thanks to Morten for pointing this out!

Now we can use the following jQuery/javascript code to manually validate our form:

var $form = ("#MyForm");                            // Select our form with jQuery
var context = $form[0].MvcValidationFormContext;    // Access the new property we created
var errors;
if ($form[0]['__MVC_FormValidation']) {
    errors = $form[0]['__MVC_FormValidation'].validate("submit");        // Validate the form
}
if (!$form[0]['__MVC_FormValidation'] || errors.length == 0) {
    // No errors, do your stuff
}

I assumed (incorrectly) that there must be a client-side API to MicrosoftMvcValidation.js, the javascript responsible for dynamic client side form validation that ships with the ASP.Net MVC framework. Unfortunately, in all my digging, I could not unearth one -- and it seems like a huge oversight. The amount of effort to expose an isValid property or a validate() function on the client would be pretty minimal!

Why would you need to do this? Doesn't the validation occur automatically? Well, yes it does -- when you submit the form, or click around in it. However, there are lots of cases where you might want to manually trigger the error messages or perform a client-side action based on whether or not the form is valid, without running the submit handler. In my case, I wanted to make sure the form was valid before trying to submit it, as our ajax pipeline puts up the "spinner" graphic when a submit event is triggered, which meant it was flashing briefly and looked dumb.

The most common response I ran across when searching for how to manually validate was -- give up and use the jQuery validate plugin. This would be my preferred solution to be honest, but I ran into at least two blockers with jQuery validate:

1. it doesn't seem to work with modal dialogs generated from jQuery UI,
2. it doesn't seem to work with forms that are loaded into the document via an ajax call.

So that was out. Since I already had most of what I needed working with the Microsoft scripts, I went back to them and started exploring the code to see if I could discover any sort of public API. This is what I came up with.

The key thing that I found was that MicrosoftMvcValidation creates a javascript object called a FormContext, which has a validate(eventName) method. This seemed promising, so I tried following the code to see how I could get at this validate method. Well -- I couldn't. Not without some modifications. Here's how it works.

When you include MicrosoftMvcValidation, the main piece of script that executes is this:

Sys.Mvc.FormContext._Application_Load = function Sys_Mvc_FormContext$_Application_Load() {
    var allFormOptions = window.mvcClientValidationMetadata;
    if (allFormOptions) {
        while (allFormOptions.length > 0) {
            var thisFormOptions = allFormOptions.pop();
            Sys.Mvc.FormContext._parseJsonOptions(thisFormOptions);
        }
    }
}

Adding <% Html.EnableClientValidation(); %> to your views causes a bunch of JSON data to be output to the page, and appended to the window.mvcClientValidationMetatdata javascript object. When the page is ready, the above function runs and calls FormContext._parseJsonOptions() on all the rules and data that were output to that object.

_parseJsonOptions is what creates the FormContext object that we're interested in. In fact, the return value of _parseJsonOptions is the FormContext… but sadly, Application_Load ignores the return value, and it's just thrown to the bitbucket, never to be seen again (at least by us).

Judging from the underscores on the function names, it's pretty clear that these are meant to be internal operations, so we can (perhaps) excuse them for not storing and exposing the FormContext for us. From the framework's point of view, it doesn't need to be stored anywhere, because it still has it -- _parseJsonOptions internally adds new event handlers for the form, and these handler delegates close over the FormContext object. The closures means that internally, the form handlers still have a saved reference to what they need, so the application load function doesn't need to do anything with the return value. The FormContext never surfaces -- so if we want to validate the form ourselves, we need to expose dig for it.

All that my code at the top of the post is doing is modifying the _parseJsonOptions function (minified to be named $12), to start adding a new property to the form element in the DOM, which will store the created FormContext object. I named this property MvcValidationFormContext, but you could call it anything you'd like. You can subsequently access this new property to get the FormContext and call validate("submit") on it, which fires the validation as though we were trying to submit the form, and returns a collection of errors we can check.

As Morten pointed out, the reference is, of course, still there. You can access the closed over FormContext by grabbing the DOM element and digging in it's properties array. The updated code reflects this.

The question on Stack Overflow is titled "How do I route images with ASP.Net MVC", but fundamentally the question is really asking "how can I use ASP.Net MVC to re-route URL's to actual physical files, rather than methods of a controller?"

To be clear, lets address the conceptual differences between routing and url rewriting.  Url rewriting takes the requested URL and modifies it before your code ever sees it.  As far as your application is concerned, the client requested the rewritten URL.  All that URL rewriting does is to change one URL into another URL, based on pattern matching.

Routing is a different and much more powerful beast.  The ASP.Net routing engine maps an URL to a "resource", based on a set of routes.  The first route to match the requested URL wins the prize, and sends the request off to the resource it chooses.  For the ASP.Net MVC framework (which uses System.Web.Routing under the hood), a resource is something that can handle the request object, which is always a piece of code.

So where does that leave physical files?  If a request is always parsed by the routing engine and then handed off to some function somewhere, how can we ever route a request for an image to actually return the physical image?

Well, it takes a tiny bit of legwork, but once we're through it, I'm confident you will see the huge advantages that routing has over simple url-rewriting.  We will show the equivalent of url-rewriting by handling a request for an image using an URL that doesn't map to a physical path, but be able to return the image anyway.

Handling the Request

First off, we need to handle the request that we want to re-route to a physical file.  Out of the box, ASP.Net MVC uses an instance of the MvcRouteHandler object to handle every request.  MvcRouteHandler hides all the complexities of taking the requested URL, breaking it down into parts, finding the right controller in your application, instantiating it and passing it all the data it needs.

The end result of MvcRouteHandler is not what we desire. We want to return an image, not instantiate a controller and run a method.   We want to skip dealing with controllers altogether in this case.  So lets create our own route handler that we'll use instead.

To do so, we simply implement IRouteHandler, an interface exposed by ASP.Net MVC that actually inherits from IHttpHandler.  This means that what we're writing is the ASP.Net MVC equivalent of an .ashx file for a webforms app -- we're inserting our own handling module into the ASP.Net pipeline, that will handle the request much closer to the webserver/http level, rather than at the ASP.Net application level.

IRouteHandler only has one method that we need to implement, which is GetHttpHandler().

using System;
using System.Collections.Generic;
using System.IO;
using System.Linq;
using System.Web;
using System.Web.Compilation;
using System.Web.Routing;
using System.Web.UI;

namespace MvcApplication1
{
    public class ImageRouteHandler : IRouteHandler
    {
        public IHttpHandler GetHttpHandler(RequestContext requestContext)
        {
            string filename = requestContext.RouteData.Values["filename"] as string;

            if (string.IsNullOrEmpty(filename))
            {
                requestContext.HttpContext.Response.Clear();
                requestContext.HttpContext.Response.StatusCode = 404;
                requestContext.HttpContext.Response.End();
            }
            else
            {
                requestContext.HttpContext.Response.Clear();
                requestContext.HttpContext.Response.ContentType = GetContentType(requestContext.HttpContext.Request.Url.ToString());

                // find physical path to image here.  
                string filepath = requestContext.HttpContext.Server.MapPath("~/test.jpg");

                requestContext.HttpContext.Response.WriteFile(filepath);
                requestContext.HttpContext.Response.End();
            }
            return null;
        }

        private static string GetContentType(String path)
        {
            switch (Path.GetExtension(path))
            {
                case ".bmp": return "Image/bmp";
                case ".gif": return "Image/gif";
                case ".jpg": return "Image/jpeg";
                case ".png": return "Image/png";
                default: break;
            }
            return "";
        }
    }
}

The above IRouteHandler is pretty simple.  Ignoring the GetContentType helper method, there's really only two things happening.  First, we check for a "filename" parameter that got passed in to our handler (more on that in a second).  If it's not there, we return a 404 response.  Otherwise, we attempt to open up the physical file "test.jpg", and stream it to the browser.

Clearly, this should be adapted to your needs by actually using the filename parameter to find the physical files on your system.   But moving on -- how do we invoke this from our MVC app?  And how do we pass in the filename parameter, of which we'd like to reroute to some other physical path?

Routing the Request to the Custom Handler

Well, this is the easy part.  Where you'd normally define your routes in Global.asax, simply use routes.Add(), instead of routes.MapRoute().  Just like this:

routes.Add("ImagesRoute",
                 new Route("graphics/{filename}", new ImageRouteHandler()));

This method of adding our route allows us to specify our custom IRouteHandler, rather than routes.MapRoute(), which by default uses an instance of MvcRouteHandler.  So now, we've defined a route that matches against any requested URL containing "graphics/", and puts the rest of the URL into the "filename" bucket of the RouteDataDictionary, and hands it off to our IRouteHandler.  This is how we pass the filename parameter into our custom route handler -- basically the same way we pass things into controllers, by defining the variables in the route pattern.

We've successfully routed all URL's containing "graphics/", which doesn't physically exist in our web application, and returning "temp.jpg", which could exist anywhere.  With a bit of coding around the file IO, you could return files from anywhere.

And that's pretty much it!  You might be thinking, "this seems like a lot of extra work just to re-route a URL to a physical file that already existed in my web app!".   If you take a step back though, you'll see the power of this approach.  What if you wanted to log every request to the original URL to a special log file?  What if you wanted to also transform the image before returning it?  Perhaps launch a system executable or asynchronously hit a web service?  What if you wanted to…?

In a nutshell, by inserting your own HttpHandlers into the ASP.Net pipeline to handle routed requests, you can code anything that you'd like to happen when a request comes in, rather than just rewriting it to some other URL.