Both the website and mobi site were developed using Microsoft’s ASP .NET MVC 2.0 framework with some slight modifications to the vanilla setup. We chose to use Spark as our view engine. Spark’s syntax is declarative and resembles HTML which enables us to integrate code seamlessly (i.e. our views don’t evolve into spaghetti code). This is not the sole advantage of using Spark, I would recommend taking a read through the documentation to realise the more important benefits. This is not the first project we’ve integrated Spark with, and we continue to enjoy working with it.

In terms of client side scripting, we used jQuery as our JavaScript library. Combres (an open source project hosted on Codeplex) was implemented at the backend to ensure that resources such as JavaScript and CSS were minified and compressed before being served to a customer’s browser. Furthermore, Combres enables us to easily update our JavaScript/CSS references which ensures that the latest version of the relevant resources are always loaded.

For the mobi site, we stuck with MVC but ensured that the markup produced by the server was XHTML-MP compliant. Given the nature of the mobile landscape, we were required to support a large number of internet enabled devices ranging from smart phones (such as the iPhone) to the hugely popular Samsung E250. For Mobile Researcher we use a library called Device Atlas which enables us to detect the type of device accessing the site and provide information regarding key capabilities. Given our experience with the product we used the same library on the Debonair’s mobi site. Images are automatically scaled and cached for devices accessing the site which ensures the site’s look and feel remains consistent no matter what resolution the relevant device sports. In time, we may begin enchancing the site for specific devices such as iPhones and Blackberrys.

For persistence we chose SQL Server 2008 R2 Web Edition. We have extensive experience working with both Microsoft SQL Server and MySql, however, we wanted to utilise Windows Workflow 4.0 as part of the solution and we didn’t have time to look at writing a custom MySql persistence service for the workflow engine. In any event, our selected ORM (LLBLGEN) enables us to target any number of database technologies so theoretically, we could switch over to MySql in the long term without too much work. From a code perspective, we implemented the repository pattern using custom LLBLGEN templates. At the repository level, queries were developed using LLBLGEN’s LINQ engine.

Windows Workflow 4.0 was used to handle longer running processes such as those invoked when placing an order. Once an order is validated, the order is serialised into XML and posted to a third party POS gateway which performs further validation and propagates the order down to the relevant store. There are number of failure points involved in this process hence the use of Windows Workflow. If the order is not successful (whether it reached the third party gateway or not) an SMS is sent to the relevant customer informing them of the failure. As you can imagine, there are a number of issues that could cause this to happen including network connectivity failures to the the third party gateway, connectivity problems between the stores and the gateway etc. We wrote a custom Workflow Application Manager that manages persistence and execution of Workflows which means the system is resilient against system reboots etc.

A Windows Service was developed to host the workflow runtime and provides the host for workflow execution. Besides order processing, the service handles menu synchronisation, store connectivity tracking and communication (email/SMS) services. To facilitate communication between the web and mobi-site, we used NServiceBus which leverages MSMQ. NServiceBus enables us to deliver messages to the Windows Service in a transactional context which is obviously critical.

As far as unit testing goes, we used a number of frameworks and libraries to facilitate the unit testing process. For the core testing framework, we used NUnit. For our mocking library we chose Moq. Moq simplifies the mocking process considerably as it exposes a fluent API. If you haven’t heard of Moq I seriously recommend checking it out.

Right now both sites are humming away on IIS 7.5. There is a lot more to come with a number of key features still in development/testing, the main being the ability to pay for an order using your credit card. All in all, the
implementation process has has been an exciting experience which has allowed us to leverage a number of new and useful technologies. Without resorting to butchering the idiom ‘the proof is in the pudding’, please think about placing your next order for a Pizza using one of the sites mentioned – we would really appreciate your feedback.

If you have any questions, comments or suggestions please free to give me a shout.

Cheers,
Rohland

If I created a new Workflow 4.0 project in Visual Studio 2010, everything worked as it should. However, if I integrated Workflow 4.0 with an existing project I ran into problems. After numerous Google/Bing searches I found a few examples of forum/stackoverflow posts about the problem but usually in the VS2010 Beta context.

It tuned out that the problem in my case is that I had two projects in my solution where the project files (*.csproj) were in the same directory. VS2010 did not like that for some reason. After moving the two projects into separate folders, everything worked! Absolutely bizarre.

If you are interested, the reason I had two project files in a single directory was because it’s the default configuration when using LLBLGEN (adapter mode). It generates two projects, one database specific and the other generic. It is possible to get LLBLGEN to generate the projects in separate folders, you can find the instructions here.

Feel free to play the sad trombone if you wasted as much time as I did.

Cheers,
Roh

Near the end of last year I started looking at offsite backup options that didn’t require user intervention and was very excited to discover the svnsync command. The benefit of svnsync is that only new revisions are mirrored and not the full repository each time. This is absolutely critical if you have a repository that is quite active. Needless to say, I decided to forge ahead and try my hand at implementing automated scripts to take care of backing up our repositories online utilising the svnsync tool. As a reference I have posted the setup process here.

Its important to note that this guide assumes you are working in a Windows environment and that you have access to a server offsite. I have referenced a few articles and other blog posts I discovered along the way to help you if you are working in a Linux environment.

Hope you found this useful. I might follow this post up with another blog entry on steps I took to setup an automated script to email me when a repository on the host machine is missing its mirrored counterpart. This is really helpful to detect cases where a repository was setup locally but not configured for synchronisation, furthermore the ability to automatically generate the relevant scripts is quite useful

Rohland

References:
http://journal.paul.querna.org/articles/2006/09/14/using-svnsync/
http://www.rosshawkins.net/archive/2009/04/27/using-svnsync-properwith-visualsvn.aspx
http://devlicious.com/blogs/christopher_bennage/archive/2009/03/11/mirroring-subversion-from-windows.aspx

It was the start of 2009, and I was investigating ORM tools for a new project we were working on at Clyral. We had been using Linq 2 SQL as our core database access layer for some time but felt we had outgrown it and were looking for something a bit more powerful and flexible. It didn’t take long for us to discover LLBLGEN. Whilst not the most intuitive acronym for an O/R mapping framework, LLBLGEN (Lower Level Business logic Layer Generator) impressed the team from the outset. After downloading the demo version and playing around with it on a test project we committed to purchasing it and since then haven’t looked back.

We started off using the Self Servicing model of the framework as it was earmarked for beginners, in time though, we began to see that we would get more mileage using the adapter model and began using this model as the defacto standard for projects. It was at this point we began looking at ways to implement the repository pattern which simplifies the testing process and ensures the implementation (which is often technology specific) does not get mangled with the domain model. To achieve this we needed every entity to implement an interface (or contract if you will). The problem with this of course, is that in C# generic variance is not supported. This posed a bit of a problem because we still wanted the full representation of a given entity graph to be available using our defined interfaces. To get around this, we needed to update the LLBLGEN templates to allow us to inject our own custom implementation of collections which would match our interface definitions. I have provided a few example snippets to illustrate what I am talking about. Essentially we added properties which took a Todos collection (property of a TodoList entity) such as defined below:

public virtual EntityCollection<TodoEntity> Todos
{
	get
	{
		if(_todos==null)
		{
			_todos = new EntityCollection<TodoEntity>(EntityFactoryCache2.GetEntityFactory(typeof(TodoEntityFactory)));
			_todos.SetContainingEntityInfo(this, "Todolists");
		}
		return _todos;
	}
}

and added the code below to support out interface definition:

public EntityList<ITodoEntity, TodoEntity>  TodosCollection
{
	get
	{
		if (_TodosCollection == null)
		{
			_TodosCollection = new EntityList<ITodoEntity, TodoEntity>(this.Todos);
		}
		return _TodosCollection;
	}
}

private EntityList<ITodoEntity, TodoEntity>  _TodosCollection;

where “EntityList” is a custom wrapper we wrote to get around the generic variance issue (note that EntityList understands that a TodoEntity is an implementation of ITodoEntity). This allowed us to define our entity contracts as such:

    /// <summary>
    /// Interface for the entity 'TodoList'.
    /// </summary>
	public partial interface ITodoListEntity
	{
		EntityList<ITodoEntity, TodoEntity>  TodosCollection {get;}		

		System.Int32 Id {get;set;}
		System.String Title {get;set;}
		System.String Description {get;set;}
		System.Int32 ProjectId {get;set;}
		System.Int16 Position {get;set;}
		System.Boolean Billable {get;set;}
		System.DateTime CreatedOn {get;set;}
		System.DateTime ModifiedOn {get;set;}
		System.String CreatedBy {get;set;}
		System.String ModifiedBy {get;set;}
		System.Guid CreatedUserId {get;set;}
		System.Guid ModifiedUserId {get;set;}
	}

As you can see, a standard was implemented where the original list’s name was simply extended with the word “Collection”. After modifying the adapter’s templates and generating our templates to create the entity contracts, everything fell into place and we had our repository pattern implemented. Our repository definitions ensured that only interfaces were passed round (of course implemented using LLBLGEN’s entities) which in turn ensured that our UI (or business logic) knew nothing about the underlying implementation. One benefit of doing this is that the chaps working on the UI never had to deal with the copious number of properties and methods that hang off an LLBLGEN entity by default. Of course, these properties and methods are useful in some cases and can still be used within the repository itself.

I have attached a zip file to this post with the implementation of the EntityList class as well as the templates that we modified and added to make this all happen. Let me know what you think, any comments or suggestions regarding the implementation are certainly welcome!

Rohland

Templates and supporting files

The application I was building was developed on ASP .NET MVC (C#) so naturally I was looking for some C# code I could use to implement the difference algorithm. In searching, I could not find any libraries that were worth implementing. I did come across one or two command line utilities but nothing spectacular. I widened my search to other languages and came across a neat implementation in Ruby. The algorithm was developed by Nathan Herald who generously made the code available to everyone via the common MIT license.

So, I had the algorithm I was looking for, but I didn’t speak Ruby! This was an excellent opportunity to roll up my sleeves and learn some Ruby so I fired up my browser, downloaded the Windows one-click installer and got a simple environment up and running. After toying with code for a bit, scratching my head at one or two alien Ruby constructs I got the gist of how things worked. I fired up Visual Studio, created a new project and began the process of porting the algorithm. I must admit that the process was relatively painless and I got something working in a few hours. It took about another hour or two to iron out some bugs I picked up but essentially, in a relatively short space of time, I had the C# diff library that I was originally looking for! Below is a demo of how it is used, followed by one or two screenshots demonstrating the functionality when rendered to your browser.

            string oldText = @"<p>This is some sample text to demonstrate the capability of the <strong>HTML diff tool</strong>.</p>
                                <p>It is based on the Ruby implementation found <a href='http://github.com/myobie/htmldiff'>here</a>. Note how the link has no tooltip</p>
                                <table cellpadding='0' cellspacing='0'>
                                <tr><td>Some sample text</td><td>Some sample value</td></tr>
                                <tr><td>Data 1 (this row will be removed)</td><td>Data 2</td></tr>
                                </table>";

            string newText = @"<p>This is some sample text to demonstrate the awesome capabilities of the <strong>HTML diff tool</strong>.</p><br/><br/>Extra spacing here that was not here before.
                                <p>It is based on the Ruby implementation found <a title='Cool tooltip' href='http://github.com/myobie/htmldiff'>here</a>. Note how the link has a tooltip now and the HTML diff algorithm has preserved formatting.</p>
                                <table cellpadding='0' cellspacing='0'>
                                <tr><td>Some sample <strong>bold text</strong></td><td>Some sample value</td></tr>
                                </table>";

            HtmlDiff diffHelper = new HtmlDiff(oldText, newText);
            string diffOutput = diffHelper.Build();

Using the sample web application provided with the project in Codeplex, the following is rendered based on the code above:

Old HTML

Updated HTML

HTML diff output

You can see that the algorithm as originally developed takes care of the nasty HTML parsing to figure out how to highlight the differences. The changes are marked up using “ins” and “del” tags. You can easily style these tags as I have done. The CSS below is responsible for rendering the differences as per the example.

ins {
	background-color: #cfc;
	text-decoration: none;
}

del {
	color: #999;
	background-color:#FEC8C8;
}

I hope you find the library useful. I wish I had more time to add tests and more documentation to the Codeplex project, but for now I think the implementation is reasonably solid and easy to follow. If you spot any bugs, let me know and I’ll try and attend to them. Given that I am not responsible for the original implementation as developed in Ruby, it might be a bit tricky to solve some of the fundamental issues with the algorithm but I will certainly have a crack at it since I have quite a good understanding of how it works after porting it.

Link to C# implementation: http://htmldiff.codeplex.com
Link to Ruby implementation: http://github.com/myobie/htmldiff

I am very grateful for the service made available via the dotnet.org.za portal. A year ago it allowed me to get up and running with my blog relatively quickly. To the administrators of the portal – thank you!

In terms of moving forward, I was not sure what the correct procedure for moving my existing blog away from dotnet.org.za was, so I ended up implementing a simple script to redirect to my new domain. Hopefully, I will be able to organise a mechanism whereby future posts here reflect in the dotnet.org.za main feed. If not, then I guess that is the penalty for moving my blog.

Hopefully you subscribe to the RSS feed available here, or at the very least, check back periodically for new content. Please let me know if spot any issues.

If you have landed here after clicking a link related to one of my older blog posts, simply use the search feature available in the side bar to locate the content you were originally hoping to review.

Cheers,
Rohland

I thought I would give the Microsoft Office Labs team a plug after using one of their Office add-ins in a presentation I delivered last week. It had been a while since I last put together a Powerpoint presentation and I wanted to find out if there were any new funky ways of delivering presentation content.

If you cast your mind back to Tech-Ed Africa 2008, you might remember a few demos of Deep Zoom, a technology that allows you to “infinitely” zoom and pan through a large collection of high-res images. The demos were impressive but sadly, I haven’t really seen the technology applied in the wild. So, I decided to look into any advancements in the Deep Zoom toolset that would allow me to put together a presentation relatively simply. It was at this point I stumbled across PPTPlex, a plug-in for Microsoft Powerpoint. It allows you to add some cool Deep Zoom type features to your presentation. Strictly speaking, its not as robust as a true Deep Zoom compilation, but it does allow you to put together a neat presentation without too much work.

Overall, I thought the plug-in was pretty cool and had an extremely low learning curb. I successfully delivered my presentation using the plug-in without any issues. I did have one or two gripes about the plug-in though, the main being that I could not find a way to publish my presentation (I had to have Powerpoint open to present it). Also, you cannot animate any of your presentation elements through PPTPlex – I can understand why this is missing (it would be pretty complex to implement) but it is just something you need to bear in mind.

So, if you’re bored of compiling presentations using the defacto Powerpoint toolset then I would definately recommend looking into PPTPlex. Have fun…

I picked up a blog post about this tip from one of my RSS feeds. Amr ElGarhy posted a valuable article on how to write emails to a local directory rather than sending them through a mail server. This saves a lot of time in dev.

Essentially, replace your existing mail configuration with the config below:

When you send a mail using the built in .NET classes, a *.eml file will be created in the directory you specify. You can then view the email by simply opening the file.

So, this morning I needed to remote into one of our work stations at the office but lo and behold, remote desktop was disabled (ARGGH!). This meant one of three things, either I drive to the office to get it done, forget about the work until Monday or try update the setting remotely. Suffice to say, I attempted option 3 first.

It turned out to be really easy, there are already one or two articles on the web that explain how to do this, but for the folks who don’t know (and for my future reference) I thought posting it here would be useful.

Step 1 – Download PsExec (an awesome utility from SysInternals)

http://technet.microsoft.com/en-us/sysinternals/bb897553.aspx

Step 2 – Run PsExec as follows:

psexec \\REMOTE_PC_NAME _HERE cmd

This will open a command line session on the machine you are attempting to enable RD on. Any of the commands you execute below will be executed on the remote machine.

Step 3 – Ensure the firewall on the remote machine lets you in

netsh firewall set service remotedesktop enable
netsh firewall set service remoteadmin enable

Step 4 – Update the terminal server registry key which controls remote desktop capability

REG ADD “HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server” /f /v fDenyTSConnections /t REG_DWORD /d 0

That’s it! You should be good to go.

Before going into the mechanics of creating a custom tooltip as suggested by the documentation provided with the charting framework, I thought I would simply outline how you would create an instance of the default styled tooltip:

The code above illustrates the databinding capabilities of the charting control. The data array is made up of a list of objects that are of type Point which is a simple class I created:

From the above it is obvious that each data point’s tooltip will look like something like this:

The tooltip is simply rendered using the relevant browser’s default implementation for elements.

Custom Tooltips:

You may be aware of the charting framework’s capability for creating rich HTML tooltips using the MapAreaAttributes property. As illustrated in an example provided with the framework you could create an HTML tooltip using code similar to that shown below:

The DisplayTooltip method referenced is a JavaScript method which essentially displays an absolutely positioned element which tracks your mouse position. The method is fired as you hover over the data point area (which is defined by an image area map). The parameter passed to the method is injected into the element as HTML. As you mouse out of the area (the relevant data point) the Hidetooltip method fires and hides the element displaying the custom tooltip. Using this methodology your tooltip could look something like this:

This looks promising because it illustrates the capability to extend our tooltips to include images, links etc. however, there is a caveat. I picked up an issue when you have a chart with a large number of data points, or a number of charts on a single page that utilise this feature. I started noticing that page loads took longer than usual. I put together a test page that rendered 40 instances of the same chart as shown above using the default tooltip. With tracing turned on the page took roughly 270ms to render:

By implementing one extra line of code to implement my rich HTML tooltip using the MapAreaAttributes property as outlined earlier, the page took almost 5 seconds to render!

It turns out anyone who dares to use the MapAreaAttributes property is severely penalised! Clearly we can’t put a page into production that takes 5 seconds just to render our charts, so we either need to revert to our dull looking tooltips or look for other ways to achieve rich HTML tooltip functionality.

Now, we know that setting the tooltip property doesn’t seem to have any performance impact but that it doesn’t result in a pretty looking tooltip either, but what if we could use the tooltip property to store the HTML tooltip markup. I know what your thinking:

Yuck. That will certainly have your users scratching their heads. So, what next? So far we know that using the example as provided by the charting documentation has an adverse affect on rendering times so that’s not ideal. Default tooltip styles work without performance issues but don’t allow us to render rich tooltips. Injecting HTML into the default tooltip property means our users need to slap on their XHTML goggles.

Well, there is an option available which I will outline here.  Essentially, it relies on the ability to interpret the default tooltip property and project it into a custom tooltip that we control. If we look at the HTML rendered by the chart control, you will notice an associated image map that looks something like this:

As you can see, our HTML tooltip detail is sitting inside the title property, encoded of course. If we leave the mark-up untouched and hover over any element on the chart, the default tooltip is rendered with unparsed HTML. Thankfully, we can access this image map using JavaScript to rebuild the image map with mouseover/out events to render our custom tooltip. While this is exactly what setting the MapAreaAttributes property is supposed to do, modifying the rendered HTML to do the same thing bypasses the performance issue noted. I have provided the JavaScript method below which rebuilds the image map. All that is required, from a server side scripting point of view, is the registration of a start-up script to process any chart you wish to load with custom tooltips.

The code above utilises jQuery which is useful, but not required to get the job done. If you are going to use another framework, just note that the map attribute (which contains the map’s ID) is prefixed with a #. You may want to get rid of that. The code above is a modified
snippet of an existing class. The DisplayTooltip method simply takes the tooltip HTML and loads it into a custom hidden element on the page. It then displays the element and tracks the mouse position so the element moves as the user’s cursor does. The HideTooltip method simply hides the tooltip and resets the HTML content. Using this technique, our HTML tooltip is rendered correctly without using the MapAreaAttributes  property.

So far I have tested this method of rendering custom tooltips in Firefox, IE 7/8 and Chrome. Its a pity that this was required in the first place. I am really not sure why setting the MapAreaAttributes  property has such a huge impact on rendering times. If anyone could shed light on the matter, please feel free to post the detail! For now, the implementation above will suffice. Since the image map processing is performed on the client side, there is no effect on the server side processing time.

Hope this helps someone out there.