1 April 2008
My new browser start page uses Silverlight to produce a simple link cloud. By targeting the rich class libraries of .NET that are available in Silverlight 2, the app loads quicker than a server-based solution, is useful, and very simple. The app I built is a good demonstration of the “zero pixel” Silverlight plugin concept: I’m using the HTML DOM bridge to create and manage all of the elements in the web page document.
The app has some key features:
Experience this application live.
Since the local isolated storage is used, the links are only on your machine, the first time you use the app it’ll have no links. Click here for a text file you can paste in using the import/export feature to load a set of sample links. I store my link cloud in GMail so that I can always setup another machine in seconds from my mail account.
The .Xap file that represents the app is a miniscule 10kb. By comparison, a server-side version of this app can easily serve 40kb pages once the editing interface is included. The only hard-coded dependency is the stylesheet link that I’m injecting at runtime.
This uses many of the less sexy Silverlight 2 Beta 1 features:
Although I’m using ApplicationSettings type to store the link cloud data, I just wanted to get this up and running, so I’m not following any best practices, and am actually serializing the cloud data myself into a single string.
Live app (10k) – feel free to use this for your homepage
Sample data file (2k) – can import for sample data
Source code (39k) – Zip file with the Visual Studio project, just barebones code, no good code in here
LinkPage.cs (21k) – Primary source file
Briefly jumping into the code, you’ll find that everything’s really contained inside LinkPage.cs. Some of the things inside the file that I’d like to call out:
The ApplicationSettings type is a nice shortcut to having to use Isolated Storage, and is used to store two settings for this link cloud application: the color used for the stylesheet (there’s a few themes available), and the actual link cloud data. The data’s updated and saved whenever a change occurs to avoid having to write the changes at one time.
Pretty standard document object model workflow here: the code’s nothing but spaghetti. The new element is created, attributes set, and then appended. There’s no need to keep a reference to the element unless you intend on interacting with it later.
There’s a built-in property HtmlPage.Document.Body that can be used to return the <body /> element on the web page, but not one for the <head /> element. The code above successfully will add to the head of the page, assuming the head exists.
A lot of AJAX applications use ‘confirm(…)’ to get quick verification before deleting data permanently. Both Alert and Confirm are available within the HtmlWindow type in the HTML DOM bridge, so it’s super easy to do the same in managed code:
The links in the link cloud have the href attribute set to point to the destination page – this enables the end user to open the links in a new tab or window easily. However, the click count is only incremented when the link is clicked since the onclick event is used to track and increment the underlying hit data.
The form that’s created on the page uses managed event handlers in C# to process events and read data:
Hope you find this useful!
Looking at the spaghetti code, it’s clear that some kind of helpful “managed HTML object” library would make creating this style of application a lot easier in the future.
Jeff Wilcox is a Software Engineer at Microsoft in the Open Source Programs Office (OSPO), helping Microsoft engineers use, contribute to and release open source at scale.