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>

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

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");

    }

}

public class Entity

{

    public Guid ID { get; set; }

    public byte[] FileData { get; set; }

}

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);

    }

}

private bool IsAjaxError()
{
  return HttpContext.Current.Response.StatusCode == 500 && HttpContext.Current.Request.RawUrl.Contains(".asmx");
}

[SecurityException: Request for the permission of type 'System.Web.AspNetHostingPermission, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' failed.]
   System.Reflection.Assembly._GetType(String name, Boolean throwOnError, Boolean ignoreCase) +0
   System.Reflection.Assembly.GetType(String name, Boolean throwOnError, Boolean ignoreCase) +42
   System.Web.UI.Util.GetTypeFromAssemblies(ICollection assemblies, String typeName, Boolean ignoreCase) +145
   System.Web.UI.TemplateParser.GetType(String typeName, Boolean ignoreCase, Boolean throwOnError) +73
   System.Web.UI.TemplateParser.ProcessInheritsAttribute(String baseTypeName, String codeFileBaseTypeName, String src, Assembly assembly) +111
   System.Web.UI.TemplateParser.PostProcessMainDirectiveAttributes(IDictionary parseData) +279

I knew that some sort of trust issue was the problem and after some Googling I came across this article that explained this problem and more importantly provided a solution. The pertinent command to execute was:

C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\caspol.exe -m -ag 1 -url "file:////\computername\sharename\*" FullTrust -exclusive on

Building a UI can be a very database intensive operation in terms of the number of separate calls required. And for each one of those calls the time taken to actually execute the query can be a small compared to the duration of the roundtrip to request and fetch the data. The obvious solution is some type of batching and with Future<T> this happens automagically without any change to the consuming logic (for databases that support it). Let me restate that, you get a huge performance benefit with only a simple change to your query methods in the Repository. So why aren’t you using it?

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).

On one of the Views I had to move a collection of complex data from the client to the server. By complex I mean more than just a single property. An example of this might be editable rows in a table (yes I know that there are other ways to solve this problem such as using AJAX but please stick with me). In addition I didn’t like the fact that there was a duplication of the presentation logic – server side binding during the initial rendering and client side binding if data was changed. I’ve seen a lot of bugs in the past with this approach when someone makes server or client side changes but forgets about the other piece.

I decided to used JSON as a common currency for this part of the UI. I removed the server side binding. Then on the server side I created a Display Model (a View Model for a subset of the View) to represent the data that I needed to display and edit. I can serialize this to JSON (new JavaScriptSerializer().Serialize(myDisplayModel)). I can subsequently access the JSON via an AJAX request or I can stuff it into the DOM if I am sensitive about the number of calls being made (which I was here). On the client side I used a JQuery plugin ($.evalJSON(myJsonString)) to convert the JSON into a form that is easily consumable in Javascript. I could therefore use the same code to initially populate the UI and deal with any edits.

When an edit was made I simply update the UI and store the new JSON in the DOM ($.toJSON(myJSonObject)). When the form was submitted back to the server I can easily deserialize the JSON (new JavaScriptSerializer().Deserialize<myDisplayModel>(myJsonString);) and then manipulate it as I see fit.

What is nice about this technique is it allows both the client and the server to work with the same Display Model. It also resulted in nice clean “object.Property” Javascript.

As always any feedback or alternative approaches would be greatly appreciated.

One of the reasons that we were keen to work together is that we have a lot of shared values, not least of which are Integrity, Craftsmanship, Agility and Community. However we had not worked together before. And despite our ideological common ground there are always challenges with any new team. One method of visualizing the stages that you typically go through in this scenario is a model known as Form – Storm – Norm – Perform.

I’m not going to explain the concept as the referenced Wikipedia article does an excellent job of that. However I do want to emphasize that any subsequent changes in the team or the context within which it operates take everyone back to the beginning of the process. Of course if the change is small then the duration of the cycle will often be commensurately short. Understanding the process that we were going through and its psychological ramifications has certainly enabled us to be successful. I hope that it helps you too.

(Don’t jump all over me for not fixing the problem myself or the way that I brought up the fact that there was one. We have an excellent working relationship that allows for this type of interaction / humor. And we benefit a lot from it as when the other party can’t be offended you get to the point quickly, agree a solution and move on).

Priyesh (incredulously): How can you be sure that it’s a threading issue?

Jason: Because the error message is “System.Threading.ThreadAbortException: Thread was being aborted”

Priyesh: Ah, you’re probably right then.

On one of the Views I had to move a collection of complex data from the client to the server. By complex I mean more than just a single property. An example of this might be editable rows in a table (yes I know that there are other ways to solve this problem such as using AJAX but please stick with me). In addition I didn’t like the fact that there was a duplication of the presentation logic – server side binding during the initial rendering and client side binding if data was changed. I’ve seen a lot of bugs in the past with this approach when someone makes server or client side changes but forgets about the other piece.

I decided to used JSON as a common currency for this part of the UI. I removed the server side binding. Then on the server side I created a Display Model (a View Model for a subset of the View) to represent the data that I needed to display and edit. I can serialize this to JSON (new JavaScriptSerializer().Serialize(myDisplayModel)). I can subsequently access the JSON via an AJAX request or I can stuff it into the DOM if I am sensitive about the number of calls being made (which I was here). On the client side I used a JQuery plugin ($.evalJSON(myJsonString)) to convert the JSON into a form that is easily consumable in Javascript. I could therefore use the same code to initially populate the UI and deal with any edits.

When an edit was made I simply update the UI and store the new JSON in the DOM ($.toJSON(myJSonObject)). When the form was submitted back to the server I can easily deserialize the JSON (new JavaScriptSerializer().Deserialize<myDisplayModel>(myJsonString);) and then manipulate it as I see fit.

What is nice about this technique is it allows both the client and the server to work with the same Display Model. It also resulted in nice clean “object.Property” Javascript.

As always any feedback or alternative approaches would be greatly appreciated.