Jarod and I have both been working on a FubuMVC application for one of our Guild 3 clients. It?s been great to have the opportunity to work with a different MVC framework and hopefully we?ll comment on what we did and didn?t like about Fubu in a follow up post. I should note at this point that the technique outlined below is not limited to Fubu, in fact it would also work with ASP.NET MVC or even Web Forms.
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.
You need to move to using $.getJSON or $.post(url, data, success, “json”) instead of calling $.ajax. Then you can get rid of most of the toJSON stuff.
@Chris Brandsma
I definitely agree Chris although here I was referring to AJAX as a technique rather than as a JQuery method. I’ll be more clear next time 😉
@chris
I dont think Jason was calling $.ajax here. The main point, which may have been missed was:
“I am sensitive about the number of calls being made (which I was here)”
The idea is to load the page with the JSON you know you will need in a hidden field during the initial webrequest. In this case you do not want to use $.getJSON.
In doing so, you can keep the client logic in javascript/json instead of duplicating logic on the client in js on the server in c#. A simple example might be adding/removing items from a list.
Its sorta kinda but not really like viewstate…. its a hidden payload, only for client data storage. On the server your only responsibility is change tracking what happened on the client.
You could take this even further and place the whole view layer (UI logic and events etc.) on the client and have the server just pass data back and forth. Some have named this ‘SOFEA’ or ‘SOUI’, others ‘client-server 2’, for example see http://www.it-eye.nl/weblog/2008/09/24/what-is-client-server-20/