I’ve been ‘away’ from this blog for a while. It’s been a very interesting year for me but I’ve been neglecting this blog for too long.

If you’ve read the previous posts, you can see I’m not a big fan of the Asp.Net postbacks and update panels. Too much information is sent back and forth for small actions that can be easily done in javascript.

As I’ve shown before, there are hugh performance benefits to using client side rendering in a web app. Instead of sending the entire HTML for every request, we load javascript code for creating that HTML once and after that we just send the data for subsequent requests.

One of the side effects of moving from server side rendering is that you start getting more and more javascript files. I’ve been using JQuery for a while, there are a lot of great plugins for JQuery, but loading all of those include files introduces some problems:

1. More scripts = more requests = more loading time
2. Managing includes can become messy

Using a Script Combiner to reduce the number of requests
Ideally you want to have only one js file and one css file, but you don’t want to have your files merged while you’re developing, a hugh file will be a pain to work with. The solution is to merge all the scripts into one big file later, either in the build process or at run time.
if you use the same scripts for all pages in your app (or if you have a one page app), merging during the build process is a good solution but I needed different files for different pages.

Asp.Net AJAX 3.5
If you’re using Asp.Net AJAX 3.5, achieving this is very simple. The scripts from Microsoft will already be combined by default and to add your own scripts all you need to do is include your scripts using the ScriptManager.

<asp:ScriptManager runat="server" ID="ScriptManager1" >
    <CompositeScript>
        <Scripts>
            <asp:ScriptReference Path="~/JScript1.js" />
            <asp:ScriptReference Path="~/JScript2.js" />
        </Scripts>
    </CompositeScript>
</asp:ScriptManager>

Script Combiner - The Other Solution
If you don’t use Asp.Net AJAX and don’t want those scripts loaded (or you’re still using 2.0) you can create your own handler to combine scripts.
Here’s a project I foundby Omar Al Zabir (Who wrote the excellent book Building a Web 2.0 Portal with ASP.NET 3.5 and co-founded PageFlakes)
You might want to change the way you decide which scripts to load, I use an xml configuration file to specify the location of each script file and which js files should be loaded based on the page name that’s passed to the handler. (I use the page name as the key for now). I also have a separate path for the minified version and the debug version, and based on a config I use the right one

<ClientScripts>
   <Script name=”jquery” minPath=”Scripts/JQuery/jquery.1.2.6.min.js” debugPath=”Scripts/JQuery/jquery.1.2.6.js”/>
   <Script name=”jqvalidation” minPath=”Scripts/JQuery/plugins/jquery.validate.min.js” debugPath=”Scripts/JQuery/plugins/jquery.validate.js”/>
</ClientScripts>
<Pages>
   <Page name=”home” Scripts=”jquery,jqvalidation” />
</Pages>

There are several benefits when using this custom handler

• You can use it for css files too
• It compresses the js files using gzip
• The files are only read from the file system once and are then cached on the server for subsequent requests
• You can easily add versioning to the handler and set client side caching to never expire.

There is a lot of information on the web on using WCF for JSON, but I figured I’ll writing something short on the way I use it.

When I decided to try WCF, the first thing I noticed was how simple it was to upgrade. All you need to do is add a new WCF Service to the web project, copy the code from the ASMX service, change the [ScriptService] to [ServiceCntract] and the [WebMethod] tags to [OperationContract] and add some definitions in the web.config file.
You’re supposed to use a separate Interface to define the service contract, but it’s not a must and you can add the tags to the actual class with the implementation.

The second thing I noticed is that I can get JSON by changing some configuration settings.
When I was working on the AJAX search page, WCF was not around (it was by the time I posted the series on it here). I used XSLT to transform data to JSON and arrays. It was another step I had to do on the server side but it’s worth it, JSON is smaller than XML and very easy to work with in JavaScript.
With WCF I just change a small definition and I get the results in JSON, no need for the XSLT transformation.

Another thing we get with WCF is Data Contracts. The way I’m using it in this sample, it’s pretty much the same as using the .Net AJAX GenerateScriptType.
All I had to do is add a [DataContract] tag to the class and [DataMember] tags to each property.
I think it’s better to define this on the exposed class itself instead of adding some register definition in a web service.

The attached project is the same search page sample with the WCF service. The changes to look for are:

• The new DataService.svc file
• The Entities.QueryParameters classes now have the DataContract tags
• web.config has the new serviceModel section at the end, that defines the service as an HTTP JSON enabled service
• default.aspx – the service defined in the ScriptManager was changed to the svc file and the path was updated in the javascript Search method

WcfAjaxSearchSample.rar (883.99 kb)

ADC is a set of data controls that try to mimic the Asp.Net controls using Asp.Net AJAX Extensions.

I'm looking at the GridView in particular, although I never really liked the Asp.Net control, the AJAX version might work well for my search pages.
For the current project I'm working on I won't be using the server side wrapper, just the client side code.

The grid view control supports paging, sorting, column dragging, links, checkboxes and in-place editing.

I'm going to try it out, see if it takes the places of my upgraded WebFXColumnList...

check it out at Ajax Data Controls - Home