Using SignalR and MVC to create a Facebook style news feed

A thought occurred to me whilst driving home a few days ago, where I considered that there was a buzz around node.js and servers pushing content directly to clients. The connecting thought was that I had no idea how this could be accomplished using the .NET framework.

I decided that I'd be really interested to find out if it would be possible to use .NET to produce a Facebook-style news feed that automatically refreshes as soon as something is pushed to the list. Podio does a really good job of this too. As soon as a user posts an update on a story, the change is immediately pushed to all clients complete with a snazzy "knock-knock" sound effect.

There are a few ways of accomplishing this using standard AJAX. The first is long-polling, which maintains an open connection waiting for the server to send something when it's ready. The second way of doing this is using the Javascript setInterval function to poll the server and see if anything has changed every x number of seconds.

However, I wanted a Websockets-style solution that would manage connections better. I did a bit of reading around the subject, and arrived at SignalR.

The clever bit about SignalR is that it provides all the support for this sort of connection for you. It starts by trying a WebSockets connection, and if your browser (or the webserver for that matter) doesn't support it, it picks a different method of transport until it finds something that fits. For Chrome and IIS 8 it would be WebSockets, and for any Internet Explorer version, it uses Forever Frame. You can read more about that on this StackOverflow answer from one of the authors.

My plan was this. I would produce a simple MVC application with a standard create form with two fields. Name and update type (either news or event). When the MVC submission was complete, the update would appear in all connected browsers, almost like a one-way multicast chat program, but over HTTP instead of a standard socket.

I then wanted a bit of JQuery in place that would push the list down and fade my new update in at the top of the list, because the list is ordered by publish date.

I created a blank MVC project, and created a controller class with skeleton actions for index and create. My view contained references to JQuery, JQuery UI, the SignalR Javascript includes, and the standard rendering of the existing list.

To prevent any confusion of the point of the project, this example doesn't connect to a database. I create a list of existing news and event updates in global.asax.cs, and store them in the HttpContext.Application object.

I then needed to create a Hub class that my client would connect to in order to receive updates. If you want the client to fire methods on the server-side, you can create them in this hub class. In my case however, I'm just pushing content from the server to the client, and this is done later on in my controller class.

My controller class takes the name and type of update, and adds it to the list of updates in the Application state as any MVC application would do. The difference however, is just before returning the view, I call a new function called SendMessage(Update). It looks like this:


The idea of a lot of SignalR examples is to push client events to the server, which then distributes it to all clients. I didn't want client-side code muddying the waters of submission of simple data, because in the future, data may change in a different way.

For example, we may want to create a delegate method server-side that performs some functionality and then pushes updates to the clients, rather than waiting for client input. My example is broadcasting a server-side event to all connected clients. This is all happening in BroadcastUpdate using .NET 4.0 dynamic variables to call client functionality.

The last step was to implement some Javascript that would listen on a connection for a call from the server to a client-side method. When this response is sent over, we get a serialized JSON object containing our update. We then do a bit of nifty JQuery to make it fade into appearance at the top of the list.

The Javascript looks like this:


It's really best to get the source code and see the demo in action to really understand how it all fits together, so I've uploaded the project to a repository on GitHub so that you can get it running yourselves.

I understood much more about how to use SignalR in this video about SignalR.

Bulk-moving Umbraco documents and updating their URLs

When moving an Umbraco document to a new parent, I had a problem where the 'link to document' property wouldn't update to reflect the new location.

Another problem I had was when I had to bulk move multiple nodes in one transaction.

After you've moved a document to a new parent, publishing the document isn't enough; you have to regenerate the XML from the parent down.

However, doing this every time using library.RefreshContent(); involves clearing the umbraco.config. Doing this whilst bulk-processing lots of documents means that the umbraco.config goes missing during transactions, and it will throw an exception.

To prevent this from happening, I introduced a config value to control whether that refresh takes place or not.

You can see what I've done here: You can read more about how to publish a document (including the answer I found) on the Umbraco wiki. When we've published the node and it's moved, the document's URL won't have updated. This is because the umbraco.config hasn't been updated from the database, so to get this to forcibly update, you have to:

1. Stop the website application pool
2. Delete the /app_data/umbraco.config file
3. Start the application pool

When this is done, your document URLs should be updated.

Let me know if any of this isn't clear, and I'll do my best to clarify!

JQuery.Cycle messes up on DOM ready

I had a bug recently when using JQuery.Cycle for a slideshow with large images.

The cycle method fails on page load when the images aren't cached.

This was because I was using:
$("document").ready(function() {
    // code here
});

Instead of that, if you use:
$(window).load(function() {
    // code here
});

Your content will load prior to the cycle method being executed.

See this Stack Overflow article for the full explanation:
JQuery cycle fails on page refresh

Errors everywhere - When Umbraco XSLT fails globally

I recently experienced a problem working on a large Umbraco site for a client where the site produced XSLT errors across the board, and none of the existing macros seemed to work.

It turned out that caching had been enabled on these macros, and that the app pool was recycled at some point during the night.

The Umbraco community is littered with examples of this error; a lot of them are in one particular post.

Sitecore vs the world

In previous places of work, I've picked up skills from working with multiple content management systems. I've built websites using Drupal and Wordpress, but the main ones I've worked with have been built within EPiServer and Umbraco environments.

My latest experience however, has been working with the Sitecore environment.

For the purposes of this blog post, I'll talk a little bit about the three of them, and how they measure up to each other from a developer's point of view.

EPiServer

The majority of my work with EPiServer has been in V5.3 R2, and I discovered quite quickly that you can't use ASCX files as templates, which meant that we had to make our traffic drivers (slang for little bits of re-usable content across the site) implement ITrafficDriver (an interface we made up) just to know which ASCX file should be dynamically pulled in by the ASCX file's container ASPX page.

On the plus side, there's lots of help from people within the EPiServer community, and despite a little bit of waiting between responses, if there's a genuine big bug in the CMS, the support ticket system will get you heard by one of their staff in Sweden.

It also has geat access management, allowing you to reduce the visibility of bits of the content tree in the back-office to certain users.

I also found that it's really quite straight-forward to bolt extra bits of functionality onto EPiServer using custom modules that allowed me to create entirely new bits of the CMS (new content trees dynamically) using the API.

Umbraco

The great thing about Umbraco is that it's open-source and free. That's a massive boost to any small organisation. However, this free product comes at a price.

I was tasked with writing a wrapper CMS for the Umbraco CMS which would effectively encapsulate the underlying functionality, and obscure the back-office from users. This was because Umbraco couldn't do this, or multilingual stuff, by default.

The idea behind it was to ensure that users never saw the back-office, and so user permissions could be set to stop people viewing different parts of the content tree. This wasn't too difficult (although it was time-consuming and buggy) because there's great access to the entire Umbraco API.

However, you can't account for poorly written code, and version 4 (in any guise) of the Umbraco framework is poorly coded. Uncaught exceptions (empty catch blocks in try statements) and in-line SQL statements make for difficult code to read and debug.

Sitecore

My experience with SiteCore so far is very new. I've only been looking at it for a week, but I've already discovered the following benefits:

Package management in Sitecore's better

You can export templates, validation rules, content.. whatever you like! The process of doing this is simple, and the installer seems robust and facilitates pretty good deployment processes.

Better built-in support for logging within the UI

This is prettier (in my opinion) than EPiServer interface, and more reliable than Umbraco.

Handling of multiple databases for BIG sites
Sitecore has a tiny little drop-down icon that lets you choose between database environments. This can in turn allow you to publish content to multiple website environments from the same CMS. This struck me as pretty impressive, because it allows for better handling of load-balancing servers

Sitecore's very new to me, but I'm keen to learn more!

Avoiding duplicate content due to case-sensitive URLs

A point that's been raised a fair bit recently by SEO specialists I work with is duplicate page content. This happens when you're using URL rewriting to point a URL to a page, and there is more than one way to get to that content.

For example:

http://www.website.com/news
and
http://www.website.com/news/home

Could both lead to the same place. Google crawls both of these URLs, and distinguishes them as separate. This can allegedly affect your ranking, and as a result, it's good to have your duplicate URL 301 redirect to the other.

This is also the case with URL rewriting case-sensitive URLs:

http://www.website.com/ThisURL
and
http://www.website.com/thisurl

A lot of regular expression matching URL rewriters such as URLRewriter.NET will happily handle both URLs and point you to the same page content. To get around this, I've implemented some code in the global.asax file to convert URLs to all lower-case.

http://www.website.com/ThisURL

will be checked in the global.asax file, and a 301 redirect will send you to:

http://www.website.com/thisurl

There's one other thing to bare in mind; ASP.NET's built-in AJAX functionality requires you to have some references to AXD files such as scriptresource.axd and webresource.axd. These files have case-sensitive querystrings, and if you don't add an exception for AXD files, these files won't be reachable, and your AJAX controls will no longer work.

Finally, you also have to ensure that you don't get in the way of postbacks. If you don't distinguish between a postback and a standard URL request, your postbacks will no longer work, and all your forms will break.

If you check out the code sample below, you'll see that I've ensured that only GET requests are checked, and that AXD files are excluded.

The Script Manager enableHistory attribute

Overview
Geeks with blogs have produced a lovely blog that'll show you how to set up your page's script manager to allow your back and forward browser buttons to trigger an event.

It runs through how to enable it using the enableHistory attribute on the script manager and how to wire up the event so that when you use the back buttons it'll fire.

Something that's worth pointing out though, is that you MUST add a history point during a postback event before leaving the page, or your event won't be fired. This may seem obvious, but I didn't realise!

So you'll definitely need a line like this in a postback event:

ScriptManager1.AddHistoryPoint("Key", "Value");

Without that happening at least once before leaving the page, your navigate event won't fire.