But when I did some manual tests by using the web application for entering some data and storing it in the database, I started to notice some strange behaviors. Particularly, after the application managed to successfully store a record in the database, the next thing when it tried to read it back out again, the record was gone. After checking the code involved, I tried to debug this a couple of times. Although the transaction completed successfully, and the record became visible in the database (I used SQLite Administrator for that), the next thing I knew, the record disappeared again.

At first I thought it had something to do with the transaction. I’ve had some issues with transactions and SQLite in the past, but I was quickly able to root this out. After doing some more digging and debugging I found the actual reason for this strange behavior.

Whenever I’m working on a small console or Windows application, I tend to save the SQLite database file in the bin folder of the application. However, this isn’t a very good idea for ASP.NET applications. Making modifications to the bin folder of an ASP.NET web application causes the application to restart. The fact that storing a record in the SQLite database modifies the file, the web application got restarted as a result. Because I’m bootstrapping the ASP.NET application (IoC, NHibernate, etc. …) in a bootstrapper class that is initiated by the Application_Start method of the Global.asax file, the database got recreated for every application startup which caused the record to ‘magically disappear’.

I changed the configuration for the SQLite database file so that it got created in the app_data folder instead of the bin folder, and everything worked just fine again.

What can I say? I’m a noob.

My constraints were:

1. I did not have an HTML form (the application I was working with is very “AJAX heavy”).
2. I needed to pass parameters in addition to the file (the ID of the entity that I want to associate the file with).

I used the jQuery.upload plugin too assist me with both of these. Obviously that means I am also using jQuery.

Let’s look at the code. Here’s the Content from my View:

Select File to Upload: <input id="file" name="file" type="file" />

<img id="fileView" />

<script type="text/javascript">

    $(document).ready(function () {

        $('#file').change(function () {

            var data = { ID: "b53dd6b4-f24c-4450-bf6a-246e5835a125" };

            $(this).upload(

                "FileUpload/AttachFileToEntity",

                data,

                function () {

                    $("#fileView").attr("src", "FileUpload/GetFileDataFromEntity/" + data.ID);

                }

            );

        });

    });

</script>

I am simply attaching an change event handler the the <input type=”file” /> control. The event handler does two things:

1. Uploads the selected file
2. Displays it. I am assuming that you are uploading an image (but not verifying this)

Note that the name attribute of the input control must be set and it must match the name of the HttpPostedFileBase parameter in the AttachFileToEntity Controller Action. Speaking of the Controller here it is:

public class FileUploadController : Controller

{

    private readonly EntityRepository _entityRepository = new EntityRepository();

    public ActionResult Get()

    {

        return View();

    }

    public ActionResult AttachFileToEntity(Guid ID, HttpPostedFileBase file)

    {

        var entity = _entityRepository.Get(ID);

        entity.FileData = GetFileData(file);

        return Content("File saved");

    }

    private byte[] GetFileData(HttpPostedFileBase file)

    {

        var length = file.ContentLength;

        var fileContent = new byte[length];

        file.InputStream.Read(fileContent, 0, length);

        return fileContent;

    }

    public FileResult GetFileDataFromEntity(Guid ID)

    {

        return File(_entityRepository.Get(ID).FileData, "image");

    }

}

The imaginatively named Entity could not be simpler:

public class Entity

{

    public Guid ID { get; set; }

    public byte[] FileData { get; set; }

}

In a production scenario you are using probably using an O/RM such as NHibernate. In this case you will want to deviate from what I have above and store the uploaded file in a different entity. This is to avoid having to load the binary data for the file each time you access the entity. Note that NHibernate 3 supports (to a limited degree) lazy loading properties. However even if you are utilizing this feature you still want to make sure that the binary data is stored in a different table in the underlying RDBMS so that any full table scans (for example if you are performing some type of aggregation) don’t end up reading mountains of irrelevant data.

The one thing that you are missing is the Repository. Rather than introduce the complexity of data access I am simply using a static Dictionary to store the data:

public class EntityRepository

{

    private static readonly IDictionary<Guid, Entity> _entities = new Dictionary<Guid, Entity>

    {

        { new Guid("b53dd6b4-f24c-4450-bf6a-246e5835a125"), new Entity { ID = new Guid("b53dd6b4-f24c-4450-bf6a-246e5835a125") }}

    };

    public Entity Get(Guid ID)

    {

        return _entities[ID];

    }

    public void Save(Entity entity)

    {

        if (entity.ID == Guid.Empty) entity.ID = Guid.NewGuid();

        if (_entities.ContainsKey(entity.ID)) _entities[entity.ID] = entity;

        else _entities.Add(entity.ID, entity);

    }

}

That’s everything you need. Hope that you find this useful.

First, lets think about what the view should be doing – in a single responsibility sort of way: turn data into html.  That right there rules out several options.  No retrieving data, no extra data transformations.  Just turn some data into html.  And frankly, that is complicated enough.  So a side goal that I strive for is to create a markup page (the aspx) that is similar to the desired html output.  The main reason for that side goal is to make double checking the output that much easier.  I want to see a ‘div’ in my markup, and have a reasonable idea where that ‘div’ will show up in the html.

1. Keep as much code out of your views as you can.

Don’t make this rule overly simplistic.  Some code belongs in the view.  A ‘for’ loop to create a table, a simple ‘if’ block to show administrator functionality, stuff like that.  But you shouldn’t be having to specify the DateTime format, or string parsing.  That is what the ViewModels should do for you.  Rule of thumb, if you see a block where there is more C# than HTML, you probably did it wrong.

I will also extend this rule to JavaScript as well.  I’ve talked about the why JavaScript should not be in the views before, so this should not be a shock.  JavaScript belong in separate files.  Period.

2. Make Views typed.

This is true for all views where you have to pass data from the controller to the view.  Make a View Model for the view and pass data via that model.  This opens up a whole host of better patterns for you, like typed HtmlHelpers.  As a result, it is VERY rare that I will share a view model between views, or even Controller Actions.  I make separate models for GET, POST, and DELETE.  I guess my view is, the more the merrier.

3.   Make the View Models specific to the needs of the view.

OK, this isn’t actually a View best practice, but it is highly related.  If you try to keep the model for the view too generic, you end up with a lot of logic in the view to transpose the data into something useful.  The key point is that the data in the model serves the view, so all of the work to get the data into the correct format should be done when putting the data into  the model.  I will often take this to the point where the model will give html elements in the view their CSS classes.  So that means I have more than data from the database in the views.

Side note: when it comes to populating View Models with data specific for the View, AutoMapper rocks!  That is all.

4.  Custom Html Helpers are wonderful things

It is remarkably simple to create your own Html Helper, and once you get the hang of them they are beautiful.  They are wonderful little ways to encapsulate a small amount of logic so you can get it out of the aspx view.  Use them to encapsulate small amounts of code you need in various place through the project.

Another little “trick” I will use from time to time to create custom models just for a html helper (passed in via the view’s view model).  I have a few places where I need to change the markup because of the browser being used…so I create a custom helper that can detect the browser.

5. Standard HTML Helpers are great, but remember html

The key point I’m trying to make here is to become familiar with the output of the standard HTML helpers.  While the helpers can be great, they have their warts (anything having to do with an attribute name/value is a bit ugly).  Sometimes it is easier to swap them out with the standard html (especially with inputs) to get the exact output you want.  As a bonus, it is easier for the next guy coming in to figure out what you were after.   Currently, I’d say I use the helpers about 50% of the time over raw HTML.

Now, typing the html, or the helper, still kind of stinks.  You have to type the same code over and over.  Take a look at what Zen-Coding does.  You can do the same thing with ReSharper Templates or Visual Studio snippets…or just install one of the ReSharper or Visual Studio pluggins.  But beyond that, there is an art to customizing Visual Studio that you should learn.

6. Wrap all links in Url.Content and Url.Action

You have a web app.  You have to navigate between pages, call web services, link in javascript and CSS.  That is just what we do.  All of those links should be wrapped in Url.Content or Url.Action helpers.   The problem that is easy to run into is you move from development to test and the base url for your application changes.  You were testing at http://localhost:898989/ , and now you are deployed to http://myserver/myapp/  and a whole lot of urls just stopped working.  Url.Content and Url.Action are supposed to fix that.  That is why you use them.

7.  Get to know Partial Views for Ajax calls.

Partial views are actually just views that don’t have master pages and the html/body tag sections.  Partials can be executed in a multitude of ways, not just from inside a view on the server, but also from Javascript on the browser. JQuery also has a wonderful little method called $.load that will call a url, take the html that is returned, and slap it into the page.  This can greatly simplify a lot of behaviors.

I subtle little trick I sometimes do with this this is to wrap a section of code that takes a long time to load in a partial.  I will then call that partial into my page AFTER is has loaded on the browser (using the JavaScript function setTimeout to call the $.load ).  Now I get  a page that loads faster, but still has all of the data it needs.

8. Make the Master page work for you.

It isn’t that there is something inherently wrong with the existing master page that you get when you create a new Asp.net MVC project.  Typically it is 80% of what you would want.  But, as soon as I know what my general page is supposed to look like, I rip right into the Master Page.   Also keep in mind that you can nest Master Pages as well.

9. Think about what a designer would want.

Even if you don’t have one.  This is just a general pattern I try to get into.  I think about a designer as someone that can take raw html, add some css and images and make my work look a LOT better.    This means I use the raw html whenever possible, I write my JavaScript click handler so they will work with buttons or links (hint: always return false — and why haven’t I written a JQuery plugin for this yet?).

10.  Version your css and JavaScript

This is actually getting into my next blog post, but figure out a way to version your JavaScript and CSS.  This really isn’t MVC specific, you should do this in almost any project.  The key reason is to help you with a browser’s cache.  You know you have a problem when the first thing someone tells you, when asking for help, is that they cleared their cache already.   My thought on this is your web app’s dll should have a version number, set the project to auto version, and then pop that onto the end of the css/javascript file call.  So it might look like this:  ”http://myapp/…/file.css?version=1.0.0.256″.   In my sample code, when in development I stick a timestamp on the file in the same way.

OK, 10 rules is quite enough (I didn’t even think I would get that many).   To the american’s reading this: Happy Independence Day.

Here is the problem, as I see it:  as an MVC project gets large, keeping all of the necessary pieces and parts for a set of controller actions straight can get a bit daunting.  I’ve ended up with duplicate folder structures in views and models, which can make navigation a pain.

To make a new Area, simply right-click anywhere in you MVC project, Add->Area.  As I said, you can do this from anywhere in the project structure, but the Areas are created in a new “Areas” folder.  When you name the Area, a new folder is created with the Areas name as well.

Once created you should see all the familiar Controllers, Models, and Views folders (all blank).  In addition to that, you will see an <name>AreaRegistration.cs file.  This inherits from AreaRegistration, and this is where any new Routes go.  In the file is a prebuilt route that should look similar to this:

   1: context.MapRoute(

   2:     "test1_default",

   3:     "test1/{controller}/{action}/{id}",

   4:     new { action = "Index", id = UrlParameter.Optional }

   5: );

So a url to the area would include /test1/ (name of my Area) in the path.  That would be good if you had multiple controllers with the same name, but if you don’t, just take out the “test1” and you won’t need it in the path.

Also, if you leave Area name in the route, you will have a little more work to, here is what one of mine looked like:  <%=Html.ActionLink("test", "Index", "test1/TestArea") %>.  But it turns out this is more correct:

<%=Html.ActionLink("test", "Index", "TestArea", new { area="Test1"}, new {}) %>

This also mean that any controller actions you want to link to outside if Area needs to include a blank area in the link, like this:

<%=Html.ActionLink("Home", "Index", "Home", new { area=""}, new {}) %>

In case you are wondering, the first object in the area is for route values, the second is for html attributes.

So the downside of using Areas is that you could complicate your routing in a hurry.  Plus it does not look like the Html helpers are there to lend you a hand either.  It is very doable, just annoying.  Of course, the easy fix is to remove the Area name from the route and move on.  That should be ok so long as you do not have two controllers with the same name.

So are Areas a compelling feature? I think so.  Plus, the larger the site, the more compelling Areas can become.  For smaller sites, probably not.  But I would not say no either.

One of the long-standing MVC practices has been ‘Shun Magic Strings.’  For example, rather than specifying Controller/Action names in an ActionLink by string, we’ve always used an Expression<Action<TController>> instead to define the Controller class and Action method “in code.”  If the action changes in the future, this gives you somewhat better abilities to discover the problem sooner vs. later. 

MvcFutures includes a version of this idea, taken to the next level:  you provide the expression with the arguments you want passed to the action included – you don’t provide a 2nd anonymous type defining the arguments.  This gets rid of the somewhat confusing “null” arguments inside the expression, and just looks better overall.  Plus, if the arguments to the action change, you’ll get better warning of that as well.

<asp:Content ID="Content2" ContentPlaceHolderID="MainContent" runat="server">    <h2>Magic Strings are Evil</h2>    <p>        <%= Html.ActionLink<HomeController>(c => c.FavoriteNumber(16), "A Number") %>        <%= Html.ActionLink<HomeController>(c => c.FavoriteNumber(32), "Another Number") %>        <%= Html.ActionLink<HomeController>(c => c.FavoriteNumber(42), "Yet Another Number") %>            </p></asp:Content>

I like this method MUCH better. 

The implementation that makes this happen is in Microsoft.Web.Mvc.Internal.ExpressionHelper.  Which even though it’s in an “Internal” namespace, is neither marked Internal, Sealed, or otherwise made unavailable (hallelujah).  So you can use this trick for all sorts of things.

There is also a System.Web.Mvc.ExpressionHelper in the official MVC assembly, which is used to implement the smart Html.TextBoxFor(m => m.Property) functionality.  This class is also NOT internal, not sealed, not obfuscated and hidden away.  We’ve used it to extend the Html.[control]For() abilities to some other control types.  Very useful stuff.  Plus its just interesting code to read.

One potentially big caveat:  I’m told that the Html.ActionLink<TController>() methods don’t work if you’re using Areas in your MVC application.  I haven’t tried this myself, we aren’t using Areas in any of our MVC 2 applications yet.  That might be why this functionality is hidden in MvcFutures and not out with the rest of the smart expression code.

My first thought was “Crap, this is going to be rough”.  Mainly I was still thinking of my time trying to test Code Behind in Asp.Net WebForms.  I had to smack myself a few times after I remembered that the Controller base class is an abstract type.  Reality is that a Controller doesn’t have to be any harder to test than any other service class.  It isn’t like inheriting from Page (Asp.Net WebForms).

Not that my code did not have some lingering issues.  Like: why did I have something in my Controller Action that would require testing in the first place?  I hate having much logic at all in my Actions.  Get input, send it off for processing (logic), go somewhere.   That should be about it – unless you have to go to different places depending on what is returned.  Now, I want some tests.

Anyway, now back to your regularly scheduled program.

Lets start things out by outlining the various parts of a web page:

• Title
• Header
• Content
• Footer
• CSS includes
• Script includes
• JavaScript

Typically, without eliciting some tricks, there will be some JavaScript in your page, as there will be some part of the script that is dynamic.  But best case, all of the JavaScript that you need can be put into a separate file.  But even then, if we are talking 5 lines of JavaScript I will probably give you a pass if you keep it in the file.

But what I want to do is encourage best better practices.  CSS is declared at the top, JavaScript at the bottom, html in the middle, code you want to run right after the page loads here.

So here is a typical MasterPage after I’ve made a few modifications:

   1: <%@ Master Language="C#" Inherits="System.Web.Mvc.ViewMasterPage" %>

   2:  

   3: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

   4:  

   5: <html xmlns="http://www.w3.org/1999/xhtml" >

   6: <head runat="server">

   7:     <title><asp:ContentPlaceHolder ID="TitleContent" runat="server" /></title>

   8: </head>

   9: <body>

  10:         <asp:ContentPlaceHolder ID="MainContent" runat="server">

  11:         

  12:         </asp:ContentPlaceHolder>

  13:  

  14:     <%
   1: = Html.IncludeScript("~/Scripts/jquery-1.3.2.min.js") 
%>

  15:     <asp:ContentPlaceHolder ID="ScriptIncludesContent" runat="server">

  16:     

  17:     </asp:ContentPlaceHolder>

  18:  

  19:     <script type="text/javascript">
   1:  

   2:     $(document).ready(MasterLoadPage);

   3:     

   4:     function MasterLoadPage(){

   5:         <asp:ContentPlaceHolder ID="DocumentReadyContent" runat="server">

   6:         

   7:         </asp:ContentPlaceHolder>

   8:     }

   9:     

  10:     
</script>

  20: </body>

  21: </html>

You can see that I’ve added some extra placeholders in the code there. 

But does any of this suck? Yes.  When you add a page that implements this master page, you will get all of the appropriate content areas, but they will all assume that you are going to add html/text to them.    The consequence is that the DocumentReadyContent Content area that is generated cannot help you with any JavaScript/Css intellesense. 

To some extent, that is still ok, as I am looking to minimize the amount of JavaScript and css in my pages…you could say the pain is disserved.    But what would be nice is if we could add a language indicator to the Content element. (hint: Microsoft VS team, I’m looking at you).  

If you also think adding language indicators would be cool, vote here: http://aspnet.uservoice.com/forums/41199-general/suggestions/487773-make-language-specific-contentplaceholders-

Happy hacking.

And if you have ever worked on web applications you should be familiar with the “user went to lunch” issue (session timeout).  User leaves for an hour, comes back to your web page, and expects it to continue working.  Unfortunately the session timed out, and now you have to refresh a bunch o’ crap.   Another version of the problem, the “.ASPXFORMSAUTH” cookies gets deleted.  Either way, your web site stop just working and the user blames you.

The fix is to have the user log in again.  Normally this is simple, when the user does something, then the page is refreshed and redirected to the login page (as assigned in the web.config).  That is the standard web model.  Unfortunately it does not work in this case.

Web services complicate things.  When inside a web method request, redirects do not work, and even worse if you are using JQuery “load” method (which loads html directly into an element), then you get the login page inside of a div.  But more often, your web client code is expecting JSON, and will be getting html (an error page or the login page).

So my current solution it to wrap up the JQuery AJAX methods with my own methods.  This way I can check the users authentication (another web method).  If I see the user is not logged in, I redirect to the login page.  The other web method is killed via the page redirect.

Here is my wrapper:

   1: var ajax = {

   2:     _lastAuthCheck: new Date().getTime(),

   3:     getJSON: function(url, data, callback) {

   4:         ajax.CheckAuthentication();

   5:         return $.getJSON(url, data, callback);

   6:     },

   7:     post: function(url, data, callback, type) {

   8:         ajax.CheckAuthentication();

   9:         return $.post(url, data, callback, type);

  10:     },

  11:     load: function(destination, url, params, callback) {

  12:         ajax.CheckAuthentication();

  13:         destination.load(url, params, callback);

  14:     },

  15:     CheckAuthentication: function() {

  16:         if (!TimeToCheckAuth()) return;

  17:         $.getJSON('<%=Url.Action("IsAuthenticated", "Account")%>', null, function(result) {

  18:             if (!result) {

  19:                 window.location = '<%=Url.Action("LogOn", "Account")%>';

  20:             } else {

  21:                 ajax._lastAuthCheck = new Date().getTime();

  22:             }

  23:         });

  24:         

  25:         function TimeToCheckAuth(){

  26:             var currentTime = new Date().getTime();

  27:             var diff = currentTime - ajax._lastAuthCheck;

  28:  

  29:             return (diff > 5000);

  30:         }

  31:     }

  32: };

Now with the wrapper in place I switch my $.ajax, $.get, $.post calls to ajax.ajax, ajax.get, ajax.post.  All the parameters should stay the  same.

Notice one thing, I’m mixing in Url.Action calls in that code.  I should add that this code is in a separate file for me, not in my web form page.  If you want to get more of an idea of how I do that, check out my post on Asp.Net MVC JavaScriptView.

Now the web method, IsAuthenticated, is about as simple as you can get:

   1: [AcceptGet]

   2: public JsonResult IsAuthenticated()

   3: {

   4:     return Json(User.Identity.IsAuthenticated);

   5: }

But back to the JavaScript, there are a couple of other things going on here.  First off, the authentication check will happen at the same time actual web method call.  I banking on the theory that the authentication check will return before the other method.   Second, I put an extra check in the method, so at most the authentication check will only happen once ever 5 seconds.  Adjust as you feel necessary.

By default an text box is generated for DateTime fields. What I wanted to do was hook this up to the excellent Datepicker widget from jQuery UI. Here’s how I achieved this:

1. Add the following 3 references to the Master Page:

   <script type=”text/javascript” src=”http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js”></script>
   <script type=”text/javascript” src=”http://ajax.googleapis.com/ajax/libs/jqueryui/1.7.2/jquery-ui.min.js”></script>
   <link href=”http://ajax.googleapis.com/ajax/libs/jqueryui/1.7.2/themes/overcast/jquery-ui.css” type=”text/css” rel=”Stylesheet” class=”ui-theme” />

   I am referencing jQUery and jQUery UI from the Google CDN (great for getting started quickly as well as for production scenarios). I am also linking to one of the default themes which goes nicely with the default MVC stylesheet.

2. Add the following Javascript to the Master Page:<script type=”text/javascript”>
   $(function () {
   $(“.date-edit-box”).datepicker();
   });
   </script>

   Here I am simply looking for a specific class and attaching a Datepicker widget to it. I am aware that this is not the most efficient approach as the code might run unnecessarily but it’s perfect for a demo.

3. Ensure that the correct class is rendered by the Template. Apparently you can currently only override the default templates for individual Controllers. Therefore create a Views/{ControllerName}/EditorTemplates folder and within it create a file called DateTime.ascx which should contain:

<%@ Control Language=”C#” Inherits=”System.Web.Mvc.ViewUserControl” %>

<%= Html.TextBox(“”, ViewData.TemplateInfo.FormattedModelValue, new { @class = “date-edit-box” }) %>

4. You’ll probably want to use the DIsplayFormatAttribute on the DateTime fields in the View Model to ensure that the time is not also output (don’t forget to set the ApplyFormatInEditMode property to true if you do this).

That’s it. You should now see Datepickers for the appropriate fields that were rendered using the Html.EditorForModel() extension method.

Why?  I have a few reasons.  Number one is I want to remove all of my JavaScript from the html, so the JavaScript is loaded via script tags.  Once that happens, then I can have the JavaScript cached by the browser and speed up my application a bit.  What I need the Asp.Net engine for was to give me accurate links to web site resources (images, web services, call, other javascript files, etc).  These are thing that I don’t want to hard wire, mostly because I’ve bitten off the Asp.Net Routing engine bug.  So, I want to use the Asp.Net Routing engine to tell me where to find stuff.

Not that I’ve committed to Asp.Net MVC I’ve come to a realization that making dynamic javascript files is well within my reach.  Actually, it is almost there already; Asp.Net MVC ships with a JavaScriptResult.  The downside of that result action is that the object expects you to hand it the JavaScript as a string, which it pushes to the browser as a file.  I want to give a method a JavaScript View for that.  The other good news about JavaScriptResult is that it doesn’t do much (just set the response.ContentType  to application/x-javascript).  So I could grab all of the View methods, turn them into extension methods, rename them, and then use them for my own underhanded affairs.

Luckily we can all grab the Asp.Net MVC source code and go to town.  I didn’t modify the original source, but I defined a new class (JavaScriptFileResult) and a bunch of extension methods for the Asp.Net MVC Controller to give you JavaScriptView methods.  You can see a usage in the first piece of code.

   1: public ActionResult JsConstants( )

   2: {

   3:     return this.JavaScriptView();

   4: }

Now below is the actually extension methods and class needed.  Put this in your project some place and go to down.

   1: public class JavaScriptFileResult: ViewResult

   2: {

   3:     public override void ExecuteResult(ControllerContext context)

   4:     {

   5:         base.ExecuteResult(context);

   6:         HttpResponseBase response = context.HttpContext.Response;

   7:         response.ContentType = "application/x-javascript";

   8:     }

   9: }

  10:  

  11: public static class JavaScriptControllerExtensions

  12: {

  13:     public static ViewResult JavaScriptView(this Controller controller )

  14:     {

  15:         return JavaScriptView(controller, null /* viewName */, null /* masterName */, null /* model */);

  16:     }

  17:  

  18:     public static ViewResult JavaScriptView(this Controller controller, object model)

  19:     {

  20:         return JavaScriptView(controller, null /* viewName */, null /* masterName */, model);

  21:     }

  22:  

  23:     public static ViewResult JavaScriptView(this Controller controller, string viewName)

  24:     {

  25:         return JavaScriptView(controller, viewName, null /* masterName */, null /* model */);

  26:     }

  27:  

  28:     public static ViewResult JavaScriptView(this Controller controller, string viewName, string masterName)

  29:     {

  30:         return JavaScriptView(controller, viewName, masterName, null /* model */);

  31:     }

  32:  

  33:     public static ViewResult JavaScriptView(this Controller controller, string viewName, object model)

  34:     {

  35:         return JavaScriptView(controller, viewName, null /* masterName */, model);

  36:     }

  37:  

  38:     public static ViewResult JavaScriptView(this Controller controller, string viewName, string masterName, object model)

  39:     {

  40:         if( model != null )

  41:         {

  42:             controller.ViewData.Model = model;

  43:         }

  44:  

  45:         return new JavaScriptFileResult

  46:         {

  47:             ViewName = viewName,

  48:             MasterName = masterName,

  49:             ViewData = controller.ViewData,

  50:             TempData = controller.TempData

  51:         };

  52:     }

  53:  

  54:     public static ViewResult JavaScriptView(this Controller controller, IView view)

  55:     {

  56:         return JavaScriptView(controller, view, null /* model */);

  57:     }

  58:  

  59:     public static ViewResult JavaScriptView(this Controller controller, IView view, object model)

  60:     {

  61:         if( model != null )

  62:         {

  63:             controller.ViewData.Model = model;

  64:         }

  65:  

  66:         return new JavaScriptFileResult

  67:         {

  68:             View = view,

  69:             ViewData = controller.ViewData,

  70:             TempData = controller.TempData

  71:         };

  72:     }

Now the view, here is what it looks like:

   1: <%@ Control Language="C#" Inherits="System.Web.Mvc.ViewUserControl" %>

   2: var UrlList = {

   3:     SubscriptionList: '<%=Url.Action("SubscriptionList", "Channel") %>',

   4:     MoreSubscriptions: '<%=Url.Action("More", "Channel") %>',

   5:     WaitGif: '<%=Url.Content("~/Content/img/ajaxloader.gif") %>',

   6: };

Like I stated before, I was looking to get uris for the most part.  But this could also be a strongly typed view where you have to pass in real data.

Finally, loading this view into my page.  You saw the controller action was “JsConstants” above, which was in my HomeController (not shown), so here is how I ask the routing engine for the JavaScript file.

   1: <script type="text/javascript" src="<%=Url.Content("~/Home/JsConstants") %>"></script>

So far I am happy with this technique.  But if you see something that can be improved, please let me know.