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)

This week I got certified, I guess. I took two tests, each one took 30 minutes or so, and got an MCTS Web Dev certification.
Because it was so easy (and cheap, test prices are 125$ but with discounts you can take a test for 85$) it makes me feel like this certificate doesn't mean much to those who know what it is.

.Net and Visual Studio can make it to easy to just drag and drop to create an application. Microsoft also has a lot of built in tools to make life simpler. Mastering these tools and drag and dropping seemed to be the focus of these tests. Sure, there were some questions about serialization, but after working with .Net ever since the first release (was it a preview or a beta? too long ago to remember) I found that most of the questions were about things I've never had to do.

Even without having experience with some (or most) of what Microsoft decided a .Net web developer should know, it was very easy to pass these tests, I guess after such a long time working with the .Net framework you understand the philosophy behind it and can guess how the folks at MS would've called a method, even f you never heard of it before.

There is a whole business built around certifications, Microsoft offers online courses and books and there are plenty of other companies in the game as well, so maybe it's all about the money, or maybe it's more important for IT certifications (system and network administrators should probably know what their doing, if you let them near the most important servers in your company).

So now I have my MCTS Web Developer certification, my guess is it won't hurt but I'm not sure how much it will help. I was planning on doing a third test to get the MCPD, but the only reason to do it now is to check if that test is any harder.

(btw, according to the Microsoft Learning web site, there are just over 20,000 MCTS Web Dev 'achievers', and 4,500 MCPD Web Dev while the number for certified windows 2003 sys admins is 186,000. This numbers are updated for April 2008, seems like not too many people felt the MCPD is worth it...)

I've been MIA from my blog for a while, too many new technologies and libraries that I want to learn...

I've been playing around with upgrading the application the AJAX search page sample was based on to use WCF and EXTJS.

The WCF part was easy, it's not that different from ASMX when you want to do basic stuff. The main difference is you have to create a data contract, which can be done by simply adding a [ServiceContract] tag to the class and [OperationContract] tags to each exposed method.
The better way is to create a separate interface that will be used for the data contract, but if you want to upgrade an existing ASMX service, you might want to take the easy way out...
The other thing you have to do is add the serviceModel section to the web.config.

The cool thing about WCF is that I no longer have to worry about how the data is converted to JSON, with WCF it's simply a definition in the web.config, so changing between XML and JSON can be done at any time without changing code and deploying it. Also, you can have more than one access point to the same class, so you can actually return both formats from the same code.

Changing my code to WCF took a couple of hours, half of it to learn about WCF basics and the rest to copy over the code to a new class, but WCF can go a lot further with it's extensibility.

WCF also let me create the javascript proxy classes including classes for the data contracts (server side objects I want to send to and from the client side). So I don't need to use the Asp.Net AJAX GenerateScriptType anymore.

EXTJS - An AJAX and UI JavaScript Library
This is currently the best UI library out there. initially I wanted to use their grid instead of the WebFX grid I've been using, but after a short time playing with it I decided to try and create a while application with extjs for the entire UI.

This library supports using other libraries for the communication layer, so if you're already using prototype or jquery, you can use extjs just for the UI components. It does have it's own AJAX implementation, so you don't have to use other libraries and if you don't need anything else from these other libraries, it's best not to use them (too heavy and eventually too many libraries will have to mean conflicts)

So I started a new project without the MS Asp.Net AJAX. Passing objects between the client and server was easy with the WCF data contracts generating javascript classes for me, which is why I haven't blogged for a while.

the extjs community is excellent, there are a lot of additional UI controls and plug ins created by the community.
One of them is a form generation class that creates a form from some json. I created something similar for my search pages (with a lot more layout support that was required by the specs). The class is called MetaForm you can find it at Saki's extension page along with some other great controls.

I will eventually return to that series of posts and recreate it, if I don't jump to some other technology by then (I have been thinking about doing something similar with silverlight, we'll see where that goes).

As always, web technology is moving fast and new things are coming out all the time, it's hard to keep up...

I remember a time when rumors about Microsoft buying Macromedia were circulating, it was obvious why they would want to buy Macromedia, Flash was THE rich interactive web application standard, and it was beginning to dominate online video as well.

As someone who suffered a lot with the Flash studio (being a programmer and not a designer or animator) I was happy with the idea of getting that side of Flash fixed. If there's one thing the folks at MS know how to do well, it's their dev tools and the support for this tools.
Flash was felt limited to me, both in the way you had to develop for it and in the way you communicate with the hosting page or the server.
You had to do very complicated solutions for very simple tasks.

When Adobe ended up buying Macromedia, I was disappointed, another designer's company meant the environment and tools won't get much better.
I was surprised MS didn't try to get flash until they revealed their own solution for RIA, online video and animation. I guess they also didn't like a lot of things about flash and decided to simply create their own plugin and it was called WPF/E, at least until the PR guys woke up and renamed it Silverlight.

I haven't worked with flash for a couple of years, and I'm sure a lot of the things that were bothering me were solved, maybe, but recently someone tried to convince me that Silverlight was terrible and had no chance of besting Flash.

So this is what I see as advantages for silverlight:

• Use JavaScript to write you client side code. the upside here is big, every web developer (should) know JavaScript, there's no need to learn another programming language or work with another set of tools. this also means the same developers can do the standard javascript programming, AJAX programming and RIA programming but it also means integrating silverlight into your AJAX apps should be easy.
• Silverlight 2.0 adds support for .Net on the client side. This means a lot of things including better performance, support for other languages (C#, Ruby, python, VB.Net, etc...). This also means all the .Net developers can now work on RIAs, so it's not only those who know JavaScript.
• XAML. Having an XML based format means you can very easily generate it on the run, on the server side or on the client side. If you need to customize a page based on database results or if you want to allow users to create XAML snippets and add them to a page, it's all just xml and should be pretty easy to do. This also means other tools for creating XAML should be available from 3rd parties (like the export plug ins from illustrator and flash)
• Video using wmv. I never liked FLV, the quality is bad and I just didn't see any reason for it to exist (remember, when it came out we had quicktime, wmv, and real media videos)
• Microsoft is behind it. This puts the flash has 98.5% install base claims to bed, at least for me. If it was some new, small, no-name company, it would've been hard, even with a better product, but I'm pretty sure MS will make sure it's on every computer and it looks like they learned from their mistakes, instead of just making it part of an update you must install or shipping it with windows, they're getting big content providers to use it. After the summer Olympics, when NBC will be using Silverlight to broadcast thousands of hours on the internet, I'm sure a lot more people will have the plug-in installed (and no, silverlight won't cause a crash, the media servers might, but that has nothing to do with silverlight).
• Silverlight is available for IE, FireFox, and Safari on the Mac (and at least on FireFox it works well for me). Another lesson learned by MS. No linux support from MS, but I think there's a plug-in in the works by someone else (ehh, who cares, it's not like a lot of the RIA users will be using linux anyway, they don't like pretty things...)

As with previous Microsoft efforts, when they show up late, they learn from others' mistakes and make a better product.
This happened with .Net, which basically took JAVA and did it the right way, or C# which eliminated a lot of problems VB, C++, JAVA and JavaScript had, and now with Silverlight.

I've only played around with SilverLight for a few days, but it's such a better experience compared to working with Flash and I have to say that as a team leader I like the fact that my team members, who all work with .Net and JavaScript, will be able to learn silverlight programming very quickly.