AaronPowell.com

So I've been doing more and more work with the Umbraco API of recent (particularly in regards to my website) but I'm getting more and more frustrated at the interaction which occurs at an API level (not to mention that it's rather ugly in some places).

When you're working with documents which are using extended document types (and how often will Id and Text be enough data?). You're constantly populating code with getProperty(alias) and performing null checks, default data handling, etc.

This is why I wrote the Umbraco Member class, as members are the one thing that is most commonly interacted with from a code level.

So to make it easier to interact with Umbraco documents at a code level I have a preview of the Umbraco Interaction Layer.

The what?

This project aims to create a code generator for Umbraco document types. It aims to take the complexity out of interacting with the Umbraco API.
Another goal is to bring Umbraco closer to a viable choice as a data storage mechanisum, not just a CMS. Most projects I have worked across have had some form of Data content tree which contains content which is non-navigatable, just CMS manageable, such as people profiles, news articles or photo gallery items.

Quite frequently interacting with this Data content structure is done via .NET and via the Umbraco API. So having an easier way to interact with an actual representation of my document types at a code level would be a whole lot nicer.

Preview

At the moment I'm still in early stages of development, but I thought it'd be nice to share. Lets say I have the following document type (it's actually one from my site and used in my Data content tree :P):

Well now I can generate some lovely .NET code, say C#?

Or maybe you're a VB person?
Well you can join in too!

You may notice all properties decorated with an UmbracoInfo attribute, well that will be used to provide feedback about how the object relates back to it's Umbraco instace.

Well there we have it, a nice little tease of things to come ;)

So it can be generally agreed that UpdatePanels are evil. Plenty of people have blogged about this, there's a good post here which goes over it in more details.

To give a brief background the reason they are not a great idea is because of what they are, just a wrapper for the standard PostBack request to force it via XHttp rather than normal.

This results in more data being submitted and returned than is really needed, so on big pages, or big requests this can negate the point of using AJAX as you're still submitting a lot of data.

But there are instances where an UpdatePanel can be a viable choice, these are generally based around paged data.

I came across this the other day when taking an implemented ListView control and wanting to make it paged and AJAX-y. So an UpdatePanel was in order.

Lets have a look at a basic implementation of an UpdatePanel for a paged solution.

The back end

First off we're going to need a data source to display in our UpdatePanel. I've created a simple collection of people:

I'm going to be implementing this in an ASP.NET ListView control, which will be paged. So here's the ASPX:

And we're going to get the resulting page like this:

Inspecting the response

So lets look at what we're transfering back and forth on the server. I'll be using the FireBug plugin for FireFox to look at the request/ response but Http Fiddler would work just as well if you're an IE person. First we hit the page

(Click for larger version)

That's not exactly what we want to see. Sure it's not a big amount but 62kb is a lot to have received for such a small page. Now lets go to the next page of the data and get the UpdatePanel to do some work.

Again, that's not exactly appealing, 4kb just to get another 5 rows!? It's also worrying when we look at the time taken

Ouch, 2 seconds is a long time for such a small amount of data... But why is this happening? Well lets inspect the response with FireBug

(Click for larger version)

Now it starts to make sense, we're get a large, well formatted code block back. Now I am a huge fan of formatting documents. There's nothing worse that looking at a big code slab, I'm forever hitting Ctrl + K + Ctrl + D to reformat my document, but in this case it's having a very negative effect on our pages performance.

Optimising the requests

So now we've seen our simple little demo in action, the submit is a little heavy, even for what you'd like on an UpdatePanel, is there anything we can do about it?

Well there's several things we can do, as you may notice from the screen shot we are submitting and receiving the ViewState each time. This is the major problem with an UpdatePanel, especially on complex pages. So the first thing is to turn off ViewState on anything you don't need it on. Eg - Label controls, the overhead of submitting their ViewState is higher than that of repopulating the attributes during a postback (and if you're properly AJAX-ing the page, you may not even need to do that as the PostBack isn't ever done!).

But what else? Well, looking at the response there is a lot, and I mean a lot of whitespace, this adds considerable weight during submits. So what if we were to remove it?

Say I changed my ASPX to look like this

Sure, it's not overly readable, but how does it perform on the inital page load

Hmm... down 1kb! How about the UpdatePanel request?

Down a few more kb, but was it faster?

Yes it was. Keep in mind that the time is a little subjective as I'm running this on my laptop so it can have performance fluctations, but none the less you should notice a decrease in the request time. And what does our response look like?

(Click for larger version)

Hmm... not really readable, but are we after readability...

Conclusion

So my example may be some-what sanitised, we don't really have a complex page, there not much in the way of other controls bar the UpdatePanel so the ViewState isn't really coming into effect in request weight. But this should give you an idea on if an UpdatePanel is the option you're going with then here is a few tricks to make it a bit less unpleasent.

But that's not all, shortly we'll look at achieving this without the need to an UpdatePanel, or even ASP.NET controls!

So in my last post I looked at how to use an UpdatePanel to do data paging and then optimising the HTML to get the best performance from our requests, but it still wasn't optimal.

Although we can optimise the UpdatePanel response we can't do much about the request, and especially with regards to the ViewState within a page, which is the real killer.
This is when we turn to doing client-side paging using client-side templates. This concept is basically the same as what we're familiar with for the ListView and Repeater ASP.NET controls, but they operate entirely in JavaScript using JSON object collections.

There's plenty of ways to go about client-side templating, you can write your own templating engine, it's not hard, I had a crack at it and wrote a client-side repeater which consumed data from a webservice in only a few hours.
Or you can use any of the premade template engines. I'm a fan of the jQuery plugin, jTemplates or you can use the templating engine which is part of Preview 1 of the Microsoft AJAX 4.0 library.

Lets have a look at both.

Setting up the WebSerivce

Well the first thing we need is to be able to get the data, so we'll create some webservices and set them up for JSON transmission on the data.

You'll notice there's 2 services, one for the returning of the People collection in a paged format, thanks to some lovely LINQ extensions, and one to get the total number in the collection (which we'll look at later).

Using jTemplates

Now we need to set up our client side template, jTemplates has its own expression format which is very similar to using an ASP.NET repeater, and it has lots of really nice inbuilt features for executing more functions when the template is being executed. I'm only going to be using a very basic features of jTemplates. Here's the template I've created for the example:

(Click for larger version)

So theres our template, now we need to implement it. We'll use jQuery to do our AJAX requests on the initial page load, and then all subsiquent requests:

I've got a few global variables which will be used in the various locations within the JavaScript to maintain our page position.

The getPeople method will handle the AJAX request and then I have a separate load method in the form of loadPeople. getPeople will be used when ever we want to refresh the pages data. When doing the AJAX request we need to pass in parameters the webservice requires. It's best to check out the jQuery documentation for how the various properties on the $.ajax function operates.
The loadPeople is where we actually create the client template instance and load the data into it.

Yes, it's that simple to create a client template. Because the result is in JSON we don't need to worry about any kind of conversion.

Now we have the client template displaying the data we need to have to work on the paging. First we need to know how many pages to make, so it's time to use the GetPeopleCount webservice

The loadPaging method is used to output our result and then the paging itself is set up. I've also got a few methods which are then used for the next and previous buttons:

Just to make it a bit cleaner I'm also disabling the buttons when they are not required.

Well now that this is all set up, how does it perform? Well I'll just let the pictures do the talking

(Click for larger version)

I'm sure you can deduce from the above that it was much more efficient. We've got a much smaller page load, and then the request is only a fraction of what the UpdatePanel one is!

And we don't have the problem of submitting the ViewState either!

Microsoft AJAX 4.0 Previw 1

So I'll just look at this briefly, first off we need to define our template:

(Click for larger version)

I really like this template engine of jTemplates, it's much simpler (but evidently less powerful) to implement, there's no really wierd syntax needing to be remembered. The only wierdness is that the template much be a class named sys-template so the engine knows to now display it.

As can be seen above the JavaScript is also fairly easy to work with. In the Microsoft AJAX format you define the control then use a pesudo-accessor to add the data and then invoking a render.
Very much like a .NET DataBinder control.

I wont bother showing the request/ response info as they are virtually identical to what was seen in the jTemplates example.

Conclusion

So now all our paging needs should be statisfied. We've seen standard UpdatePanel implementations, then made them as optimised as possible. And to finish it off we looked at doing it using JavaScript entirely (well, for display purposes it's entirely done :P).

Hopefully this is gives a useful insight into the world beyond ASP.NET.

And to wrap it all up here's the sample project to play with yourself.

Well again my MBP is back to the repairer, I've been having intermitent issues with the keyboard and mouse since it last was repaired (on an unrelated matter) and finally I'd had enough.

I took it down to the local Mac dealer and handed it over, to be told I'd be without it for around 10 days :(

It's going to be a long 10 days, that's for sure...

So I bought a new harddrive for my MacBook Pro, the 120gb was reaching maximum capacity, and VMWare keeps expanding in disk size so this was inevitable.

Well I bought a new drive, took my MBP appart (god that's a pain in the arse!) and then popped in my Leopard disk and set to restore from Time Machine.
And this is where it started going wrong. First off, you have to have the drive formatted before the installer will pick it up. Not a real issue but a bit of a pain as I'd got to the point where it tried to detect the drive before I worked that out. So once formatting you need to restart

*sigh*

Then the next problem occured. Once TM had finished importing my old system it refused to boot. It'd display the loading screen and then reboot. Over and over and over...
No diagnostics could give an indication as to why though. Couldn't get into Single User or Safe Mode. The only course of action was to reinstall the system from scratch.
Once Leopard had installed if asked if I wanted to import from anywhere, thought I'd risk it and import from TM again (as this time it didn't have to do an OS install as part of the TM restore). And this time it appears to have worked!

My system is back, my apps are installed and all my Mail, Adium logs, etc are still here.

The other day I was chatting to Paul Stovell about his new MacBook Pro. I asked whether or not he would be running OS X or Vista as the primary OS, to which he stated that he wasn't much a fan of the OS X, particularly the interface.

I myself am a fan of OS X, I can no longer live without Spaces or Expose (but I make do without Expose as Unity still has rather poor performance in VMWare). But I'd never really stopped to pay much attention to the UI and how we interact with it.

Paul went on to make some very valid points about the UI and the feedback it provides to end users, feedback we've come to expect from a UI.
For example, when you're in Windows and you mouse-over the menu strip the current item changes to show this is where the cursor is, but in OS X there's no such feedback until you actually click on the menu.

And there are other examples of it, take the window resizing, Windows will show a different cursor to imply the kind of resizing you can do, but OS X doesn't do anything when you hover the resize spot, nor when you actually interact with it.

In fact, the only sections of OS X which respond when you interact with them via hovering is the Expand/ Minimize and Close jewels in the top-left of a application window and the Dock (in default mode it will show the application name, or it can be made to zoom when hovering).

Is this a bad thing?

I don't believe this is really a negative point on OS X's behalf. The primary reason in which we expect these things is because it's what we're use to. Most people are use to Windows, and do have expectations which have been formed by using Windows.

It more comes down to what is the intended target of your application. If it is for OS X then people wont be expecting UI reactions to hovering events from the mouse like a Windows user would.

Really, it's a case of "each to their own". I'm a keyboard man, when it comes to navigating around my system if I can't do it from a series of keyboard shortcuts then it's generally not worth doing :P.

Recently we've had several projects which have come through in which we are building a solution in Umbraco and the client wants to have memberships within the site.

Umbraco 3.x has a fairly neat membership system but it's a bit limited when you want to interact with the member at a code level. Because members are just specialised nodes they can quite easily have custom properties put against them, but reading them in your code is less than appealing.
You've got to make sure you're reading from the correct alias, typing checking, null checking, etc.

And as I kept finding I was writing the same code over and over again for the reading and writing to the properties I thought I'd put together a small framework class.

The framework requires the following Umbraco DLL's:

• businesslogic.dll
• cms.dll
  

So lets look at some sections of the class.

Default Properties

A member has a few default properties which are also built into the framework. There are also a few additional properties which the framework uses (such as the MembershipTypeId) which are coded in. All of the default properties are virtual so they can be overriden if so desired.

 An interesting addition I have made is the IsDirty property. This is used later on during the Save to ensure that only members who have actually got data changed are saved back into Umbraco. This limits database hits and improves performance.

Constructors

I've found that there are 3 really useful constructors, a new member constructor and two existing member constructors.

What you'll notice from this is that the constructor which takes an Umbraco member is actually marked as private. This is because the framework is targetted at multi-teired applications, like MVC/ MVP where you want to keep data layers separate from the others. And by doing this you can avoid having the Umbraco DLL's included in any other project in your solution.

Next you'll notice a call to the method PopulateCustomProperties, this is an abstract method which you need to implement yourself to populate your own properties on a membership object.

Saving

Obviously this is an important aspect, and by default the framework already has the saving of the default properties configured.

This is also an abstract method called PrepareMemberForSaving which can be used for preparing an Umbraco membership object for saving to the database.

Notice the use of the IsDirty flag to ensure we're only saving what we should save.

Helper Methods

I've provided a few helper methods which can be used for the reading and writing of custom properties on the Umbraco membership object.

The two get methods handle the null and default data checking, along with casting back to the appriate data type. Here's an example implementation:

The save is really just a shortcut, I was sick of typing out that same command every time, to use it you would call it from the PrepareMemberForSaving method like so:

And we're done

So there you have it, a simple little class for creating a .NET implementation of an Umbraco member.

There are two downloads available, Member.cs or a compiled DLL.

It will be interesting though when Umbraco 4 ships and the membership model changes to use the ASP.NET membership providers...

Ok, well it's actually v0.2.3143.41238 but who's counting :P

So I've got a new version of my MSBuild tasks ready, and in this new minor release I added a new namespace and two new tasks. The new namespace is AaronPowell.MSBuild.Tasks.Sql and the new tasks are DatabaseBackup and DatabaseRestore.
I'm sure you're smart enough to work out what these two tasks do, but for those who are a little slow to catch on.

DatabaseBackup

This task is designed to make it easier to backup a database as part of a build. It generates a Sql command, adds the appropriate parameters and then runs it nicely.
You can specify any location and filename to backup to, provided the Sql Server is able to connect to it to run the backup.

Note - it only supports MS SQL servers and full database backups.

The above shows how to use the MSBuild task in use.

DatabaseRestore

This task is designed to restore a database from a backup, it is slightly more advanced as it requires a few more parameters, such as where to find the log and data files of the database (full path on the Sql server).

With the above example there are two parameters left out, if the name within the data/ log files within the backup these can be provided within the DataName and LogName properties.

So there we go, two pretty new tasks. Get v0.2.3143.41238 now!

So I was going through my blog feeds the other and came across a post about the CTP release of an ASP.NET Virtual Earth server control (Channel9 video here).

I'm doing quite a bit of work with Google Maps at the moment so I was interested in seeing what was available in this Microsoft incarnation.

Well to be honest I was really quite dissapointed in the attitude of the people doing this, in regards to what an ASP.NET developer should be capable of knowing/ doing.

Essentially the control is an ASP.NET server control you put into your page and can program against using C# directly, rather than having to interact through JavaScript. Great idea in theory, poor idea in practice.
The video goes on then to show how "cool" it is to integrate with the UpdatePanel to "completely remove the need to code JavaScript".

Sorry... what? There was also some comment along the lines that ASP.NET dev's don't have the time to do JavaScript.
Again... what?

I don't believe any good ASP.NET developer, or any web developer for that matter, can survive without having knowledge of JavaScript. For making rich web UI's it can't be beaten (unless you're going down the flash/ silverlight path, but then they aren't entirely web UI's).

Another thing was a glimse of the source of the page and a quick scroll past the ViewState, which was... large.
Combine a large ViewState with an UpdatePanel as they do any you're into a world of poor performance.

Kudos to Microsoft for triyng to make Virtual Earth more accessible to web developers, but poor form in thinking that an ASP.NET server control is the best way to go about it.