typps

Backbone.js View Events not Firing?

2012-09-29T12:35:00.002+02:00

In backbone, setting the el element in the view's initialize method doesn't ensure that the events are bound correctly. Apparently the events are wired only when the el element is set via the views constructor as an option, which is not always what you'd like to do.

To workaround, if your setting the el element in the initialize method of the view, then make sure you call this._ensureElement() right after.

_ensureElement() methods description says this :

Ensure that the View has a DOM element to render into. If `this.el` is a string, pass it through `$()`, take the first matching element, and re-assign it to `el`. Otherwise, create an element from the `id`, `className` and `tagName` properties.

var MyView = Backbone.View.extend({
       'events': {
                'click .next': 'next',
                'click .cancel': 'cancel'
        },
  
        'initialize': function() {
            this.el = $('#step1');
            this._ensureElement();
            _.bindAll(this, 'render');
             this.template = _.template($('#step1-template').html());
            this.render();
        },
        
        'render': function() {
            $(this.el).html(this.template(this.model.toJSON()));
            return this;
        }, 

       'next': function(){
           window.console.log('next');
       },
  
       'cancel': function(){
            window.console.log('cancel');
       }
 });

An Ant process driven build for Javascript --Make your own Javascript IDE

2011-10-16T13:48:00.000+02:00

What we are going to setup is an IDE that can assemble Javascript code spread out in multiple script files into a single file (mimicking physically structured class files found in class based languages),compile the code getting useful warnings and errors in the process, minify the code, create documentation via jsdocs and zip+deploy . All through a build script that can be called through the push of a button F6 (Just like in visual studio).

First a quick preview of what we are building :

As you can note we used jsdocs annotations to tell the compiler what type the parameter is since javascript does not have support for declaring types like in strongly typed languages. These annotations are stripped out during minification so we don't incur the cost of verbosity in our code. We simply compile the code and dutifully get the above warning.

Another quick example :

As you can note above, we told the compiler that the shape object is an interface, we then specified that the square object implements the shape interface. We did all this using jsdocs annotations. However in our Square object we didn't provide the implementation for the draw method. This violates the contract and we are dutifully warned. Note how we've used annotations again and our code does not depend on any third party libraries. It's at a minimum.

These are simple examples. For a whole slew of compiler warnings provided, you can read the documentation provided by google since our build uses google closure compiler.

Getting started

Firstly to get such a setup in place we use Ant as our build tool. If you don't already have Ant installed, you may download it from the following location and set it up on your system : http://ant.apache.org/bindownload.cgi

You also need the java jdk, which you can download from : http://www.oracle.com/technetwork/java/javase/downloads/index.html

You may continue now after installation, but do note the location where you unzipped ant and the location of the jdk bin folder. You'll need it when setting up NppExec ( you'll find out later what this is, keep reading).

Now that you have both the Java jdk and Ant, you have the necessary tools to build. You simply call the build file from console. However, working in this manner is quite difficult and you'll find yourself switching too much between a console window, your favorite code editor and perhaps the windows explorer.

What we need is a way to integrate our build into an existing code editor. For this we will use Notepad++, not only is it open source and has no costs involved but also it's in continuous development and has a good community backing it. Moreover, there are many plugins already written that will make our integration work to a minimum.

You may download notepad++ from the following url :
http://notepad-plus-plus.org/download/

Now that we have notepad++, lets integrate it with our Ant build script. Our expectations are simple. What we want to do is sit in notepad++ as we edit our code and then, without leaving the editor we'd like to simply press F6 when we are ready to compile. Lastly get a status report in console within notepad++ ; In this manner we never leave our editor. In addition it would be nice to browse our files within notepad++ itself. There are quite a few nice add-ins that supply a file explorer. I use Light explorer. You'll find it in the plugin manager explained below.

Setting up Notepad++

First, you'll need to add a plugin capable of processing our build file in a console that is displayed inside notepad++ itself. The plugin is called NppExec and it can be added through the plugin manager :

When your plugin manager loads, it will list all available plugins. Select NppExec form this list, in addition you may also want Light Explorer and JSLint. JSLint is a good tool and will aid you in writing and debugging your js code, you will be happy to run this tool every once in a while on your *.debug.js file generated by the build.

As you can note from the plugin manager in the screenshot above, i have already installed all 3 plugins we'll need. You'll have to select them from the “Available” tab. Once you have NppExec installed, you need to tell it about your build.xml file.

Before we do that, try to find a way to organize your projects, because for each project you create which may not be very often, you'll end up doing the follow steps manually each time. Basically once per project. So organization is quite important.

The following screenshot demonstrates how I organize projects, if you come up with something more clever, feel free to share it :

As you see, we have Project1 and Project2, each has it's own copy of the ant build script. The version file is where you can store the current version number. All your builds will deploy to a dst folder (even to a path of your choosing) using the version number.

The tools folder you see in the root folder contains the tools necessary that the build uses such as YUICompressor, Google closure compiler, jsdocs-toolkit and ant-contrib (we use some extensions to ant so we need this too). It's all provided along with the build script on codeplex.

You may later download newer versions of these tools from their respective authors and replace them as you see fit keeping everything up to date.

Now, lets proceed to tell NppExec about Project1.

Setting up NppExec plugin in Notepad++

Before we start, we need to configure the build file manually and tell it the name under which it needs to build the folder structure. You start with a vanilla version of build.xml, in our example from the above screenshots, for project1's build file, we'll chose “MySite”.

Open the build file under Project1 and run a search replace for all instances of “projectname” to the actual name you'd want to use. Now save it. OK, we are ready! After installing the plugin, we need to set it up to process our build file which we have organized in Project1 and Project2 folders as in the previous screenshots above. In notepad++, go to the menu bar, under plugins – NppExec – Execute

The execute dialog will show up :

Now we are ready to include a piece of code that will prepare the console environment for us.
The code to include is :
ENV_SET PATH = $(NPP_DIRECTORY);C:\apache-ant-1.8.1\bin;D:\Program Files (x86)\Java\jdk1.6.0_22\bin
cd c:\HTML5\Project1
cmd

As you can see, we have told it where to find Ant executables that will process our build file and of course, Ant requires Java so also the Java jdk executables path is included. There are many different ways to set this up, I found doing the above the most straight forward and explicit.

You may experiment differently because for each project you will be copying and pasting this same piece of code. The part that will change is the Project name and perhaps the path. Right now we have setup the build for Project1

Next, we don't want to be doing this repeatedly everytime we open notepad++ so we'are going to save it under a name, in this case “Project1”

And that's it. Save it and from now on, every time you open notepad++, you will hit your F6 key to execute your project and then you will find Project1 in the dropdownlist to select from. The script you wrote in the execute box will run and prepare your console for you as follows:

Now you are ready to simply build hitting your F6 key every time you want to build. You'll be doing this after you've written a piece of code, so quite often. It's important to be able to do this in a single click, F6 is awesome that way.

The execute dialog will look like this now :

In the exit message you write the commands you want to execute on your build file. Above we execute the build using Ant, this will run all tasks.

All tasks means, it will concatenate script files, compile your js through google closure, your css files also undergo the same procedure and will be processed by YUICompressor, if you have documentation, then js docs will also be generated. If the build is successful without errors, it will be packaged in the dst folder.

That's quite a lot of tasks the build is doing and as your script files grow you'll waste quite a bit of time just waiting for it to finish. So instead of calling your build using the ant command, you can call individual tasks. For instance minifyjs or minifycss etc. It's detailed out in one of the sections below, for now, let's see what happens the first time we run the ant command.

As you can note from the above screenshot, calling ant alone without any arguments will run all tasks which is fine the first time because we have nothing, What's going to happen is that it will create the folder structure for us and we end up with the following.

Note how everything is under com.MySite folder. This is because prior to starting, if you still remember, we ran a search and replace in the build.xml file and changed all instances of “projectname” to “MySite”. We're using a domain name convention for this but if your a little ant savy, you can change this to whatever you prefer by editing the build manually. It's all declarative code and very friendly. I love it and so you get my very biased opinion.

However, if you are new, it won't hurt if you can get a book on Ant, there's quite a lot of good material as it enjoys a lot of popularity. Before we proceed, let's look at what happens after we close notepad++ and try to open it again. After re-opening notepad++, hit the F6 key and you get the execute dialog again. But this time the project is saved, so you don't have to enter the commands to warm up the console.

As you add projects and save them, they will appear under the dropdownlist you see in the screenie below. You simply select the project from this list and click OK, then F6 again.

The first time you plan to load a projects build, you may have noticed that's it's a 2 step process because the first time you have to select the project and it will prepare the console environment executing the script you see in the dialog above.

The second time onwards you hit F6, you get the Exec dialog that will take your ant command. And this same dialog will appear every time you hit F6 from now on, unless you decided you wanted to change project. You basically have to try it 2 or 3 times to get accustomed to it. It's quite difficult to put in writing and may seem too complex but really, it's not.

OK, we are ready. Now lets write a bit of code and then Build.

Making your javascript or css code part of this build process is quite simple. Your code has to go in either the Scripts or Css directory the build created for you. These are the directories that will get processed by the build. We'll discuss javascript now, however keep in mind that the same procedure is available for css as well. For css you get concatenation and minification too. Lets pretend we want to create a script file named “MyScript”.

We start by creating a “MyScript” folder under the Scripts folder. Within MyScript, we can create an unlimited number of subfolders and within each we can add script files. How you arrange your script files is up to you. The important thing to consider is that the build file will process the script files starting with the folder then filename in ascending order, so if order is important to you, it certainly is to me, you will find a way to arrange your files alphabetically or numerically.

The way I do it is I start in alphabetic order so I name the first folder i want processed “a”, and the second “b” etc. But lets do a code example. I don't like to keep my code in the global namespace so I start with a closure, this is simply going to be an anonymous outer function that will embody all the code I write eg:

(function(window, document)
{
    //everythign else will go in here
}(window, document));

The anonymous function above is called by passing the window and document as parameters. In order to ensure that all the code is enclosed within a closure as the code above, we can arrange the scripts as in the following screenshot:

Note the 3 folders under MyScript. Folder “a” has a script file that contains the opening parts of the anonymous function, and folder “z” contains the closing, and since our code will be processed and assembled into a final single file in ascending order, anything in between will get embodied within. Make sense? I hope so because if you understood that then you are ready to write your code and build it!

The final script file is going to be created when you build and it will be deposited in the MyScript folder under the same name so, you'll end up with MyScript.debug.js and MyScript.min.js respectively. The “debug” file contains your code without minification, while the “min” file contains optimization's and minification produced by google closure compiler. So, we end up with this after a successful build (F6) :

Note above, that apart from the stuff that went into dst folder (your deployment folder), the build also generated 4 new files. MyScript.debug.js, MyScript.min.js, MyScript.extern.local.in and MyScript.extern.thirdparty.in. We'll get to the last 2 files that were never mentioned before soon enough, for now focus on *.debug.js and *.min.js files produced.

The first thing to note is that the name of the files has been acquired from the root folder under Scripts. And the contents of these files is the combination of all script files within the MyScript folder.

If we inspect the contents of MyScript.debug.js, we see :

(function(window, document)
{
 //everythign else will go in here
}(window, document));

If you remember from our earlier setup of script files, each line of the code above was in a separate file.

C:\HTML5\Project1\src\com\MySite\scripts\MyScript\a\a.start.js contained :

(function(window, document)
{

C:\HTML5\Project1\src\com\MySite\scripts\MyScript\b\a.myObject.js contained :

//everythign else will go in here

C:\HTML5\Project1\src\com\MySite\scripts\MyScript\z\a.end.js contained:

}(window, document));

Now it's all combined into a single file. Perfect! We now have everything working. Let's introduce a small error in our js code, for instance let's add a function in a.myObject.js and deliberately miss a closing brace. Just something simple to see if everything is working. Now lets build and see what happens:

If you open debug.js and go to line number 5, you will see that your missing a closing brace. For a complete list of compiler warnings that you will find useful, visit the following online document : http://code.google.com/closure/compiler/docs/error-ref.html

About *.extern.local.in and *.extern.thirdparty.in

Remember the *.extern.local.in and *.extern.thirdparty.in files that were generated when you first build the project? They are useful when compiling in Advanced mode. These are simply files where you can include methods from getting renamed when using google closure in dvanced mode. This is necessary because the closure compiler will rename everything in the project and you wont be able to access any methods in your objects using their original names you provided.

The minification process wants to give you a very tiny hyper crunched file. So it's your job to tell it what method names to leave in tact.

The other *.extern.thirdparty.in can contain a third party library's extern file. Most third parties will provide you with one. For example, jquery has an extern at the following url :
http://code.google.com/p/closure-compiler/source/browse/trunk/contrib/externs/jquery-1.3.2.externs.js?r=66

You just need to copy that into your third party extern file. The third party extern is useful when your calling methods from external libraries like those in jquery. The extern will contain all method names which will result in the compiler not renaming any of these methods in your code.
I don't want to repeat what the google documentation says about this so go ahead and have a good reading at the following url :
http://code.google.com/closure/compiler/docs/api-tutorial3.html#externs

Externs are only a small part of it. There are many other things to keep in mind when using google closure in advanced mode. Why is this the default? I don't know, good question, I guess because I work in the advanced mode. I encourage you to do the same.
Just make sure you read the following document as well :
http://code.google.com/closure/compiler/docs/api-tutorial3.html

Advanced mode can be turned off in the build. There are instructions on how to do this in one of the sections below.

Don't forget about strong typing in javascript. You can achieve similar functionality using jsdocs annotations to decorate your code and tell the compiler some extra information about your types, arguments, constructors and so forth.
Google closure will warn you when you do something silly and in this way you can make use of strong typing in javascript. Read all about it at the following url:
http://code.google.com/closure/compiler/docs/js-for-compiler.html

In this way you can tell the closure compiler what arguments in a function are optional, what the return type of a function is, the type of a variable and so forth. The above document is complete and a good reading. By using these annotations not only do you make use of strong typing but also the build can use this to generate your documentation. Two birds with one stone. Perfect!

Selectively excluding script files from the build

You can add your third party code in the script folder too. But by doing so the build will process it and try to minify that code as well. Third-party code is already minified by their respective publishers so it makes sense wanting to exclude these from the final build. But why put third party code in the script folder? The reasons can vary, I put third party in there because I unit test within the src folder and if my code relies on third party, I'd like the code there.

Another reason you may want script files excluded is if you have two different versions of the same js object ( in a separate class files *.js) that does a particular task but targeting different builds. So before a build you can exclude one, build, then exclude the other and produce two different versions of your code that behave a little different, perhaps one version with particular functionality against jquery and the other against dojo lib or what have you. In order to exclude a script file, open your build.xml and look for the following property :

<property name="scripts.exclude" value=”” />

In the value attribute, provide the name of your script file you want excluded. For instance if you wanted to exclude files foobar1.js and foobar2.js, from being assembled and processed you can specify this as follows :

<property name="scripts.exclude" value=”foobar1.js, foobar2.js” />

The same applies for css files, you simply exclude them by providing the filename in the css.exclude property. Look for it in the build file.

<property name="css.exclude" value=”foobar1.css, foobar2.css” />

Excluding scripts from documentation Script files in the scripts folder after getting assembled, the *.debug.js is then processed for documentation. If you wish to not document a certain *.debug.js file, you may specify this in the build.xml manually as follows :

<property name="docs.exclude" value="foobar.debug.js"/>

Jsdoc-toolkit Templates Note that jsdocs is very flexible and you can create your own custom templates in the templates folder. For the meat and potatoes about how it works you may reference the jsdoc-toolkit project templates section :
http://code.google.com/p/jsdoc-toolkit/wiki/Templates

As far as our build is concerned, if you want to use a specific jsdocs template, you can specify this in the following property : By default, it's using the jsdocs template as you can see from the setting in the value attribute above. You'd replace jsdocs with the name of your custom template. Controlling compilation level : By default the build will compile in advanced mode. If you want to go into the simple mode, you can change this in the following property :

<property name="closureoptimizations" value="ADVANCED_OPTIMIZATIONS" />
<!-- ADVANCED_OPTIMIZATIONS or SIMPLE_OPTIMIZATIONS-->

Just change the contents of the value attribute to “SIMPLE_OPTIMIZATIONS” Pretty Print the minification: Sometimes when i'm debugging the minified code, I'd like it to be nicely formatted, it's so much easier, that way I can inspect the output. At some point you will appreciate this feature of the google closure compiler, so if you want the minified code to be nicely formatted, add the following line :

<arg line="--formatting=PRETTY_PRINT" />

You can add the above line right below this :

<arg line="--compilation_level=${closureoptimizations}" />

If you have other google closure compiler arguments to set, this is how you do it. Other advanced options can be set in their respective tasks, you'll need to look at the build yourself and make sense out of it. I have tried to make it as clear and obvious as possible, but when in doubt, just follow how I coded each task and replicate, in case you want to make your own custom task.

In addition some tasks like minifyjs and minifycss can take additional arguments, for example in case you want to specify the compilation level for google closure compiler or formatted pretty print after minification, you can do so by adding a custom argument or modifying an existing one.

You'll need to look at their relevant documentation too : http://code.google.com/closure/compiler/docs/compilation_levels.html

Build Tasks

We can supply build tasks invidually in the execute dialog :

Calling ant alone, will run all tasks.

ant

Executing tasks individually

To build, compile and minify, supply :

ant minifyjs

To concatenate our script files only, supply :

ant concatjs

To concat and minify our css, supply :

ant minifycss

To concatenate css files only, supply :

ant concatcss

To generate documentation only, supply :

ant jsdocs

Final Notes

HTML5 is all the rage now. We've started moving most of our code to the clientside and Javascript is more important now than ever. The productivity of an automated build is hard to ignore. As you have seen, our solution involves using Ant to drive our build process. While there is quite a bit of competition in this space Ant enjoys a lot of popularity and there is plenty of adequate documentation written through the years.

We also made use of notepad++ due to it's popularity as a light weight free code editor. One hiccup might be that notepad++ is windows only, but the build itself can be called from console so if notepad++ is not available for your platform, you can very well try to integrate it into your favorite code editor as we did in this article or simply call the build script from console.

Lastly, while I come from a .NET background, the urge to use MSBuild and integrate it into Visual Studio was great. One reason I never pursued this route is because I've been actually using Visual Studio .NET over the years to edit and debug my Javascript, and I'm not impressed. It's too heavy.

I wanted to enjoy more freedom on how I write Javascript without the limitations of a single IDE, platform and extra costs. Writing an Ant build opened up a lot of possibilities.

How good is this build?
I've wrote this build somewhere in November 2010 and I've been using it since. I must say that I've never had any real problems and its worked flawlessly for me. I release it in the hope that you too have the same experience or are capable of adapting it to your own setups and environments.

Download

The project can be downloaded from http://jsbuild.codeplex.com/
accompanied with a MIT license, feel to use it in anyway you see fit.

Abmho --A syntax highlighter that runs online and offline

2011-10-02T22:19:00.001+02:00

Introducing Abmho –the syntax highlighter wizard

The first stable release of Abmho is out. It is by no means the first or only syntax highlighter on the web. There are quite a few out there but the vast majority aren't usable. Abmho can run on the web or as a standalone silverlight application on your desktop.

Since I like my code colored and styled when pasting code snippets in blog posts, I decided to write an app that did only that. I hardly blog by the way, hopefully this will motivate me more.

Now, lets look at how Abmho works and what it can do. There are four steps in the process.

You start by pasting your code, as you see in the screenie below, this is done in the first step.

Step 1 - Paste your code

Next, you need to state what language your code is in. This step also lets you set a language at the line level. What this means is that you can mix languages in a single snippet. No other syntax highlighter can do this by the way.

Step 2 - Compose the language

Mixing languages has always been problematic for me because in asp.net you can mix code and markup in the same template file. This meant that I had to copy the code separately and the markup separately. Quite the work it used to be but not anymore.

By default, the selected language will apply to all lines. If you want to mix languages, you must first “Uncheck” the checkbox and then select line/s and apply at the line level.

Step 3 - Settings and live preview

One thing to note in the above step is that when setting the background color, the code highlight will try to contrast the background automatically. This is not a predefined scheme and there are some edge cases where the contrasting might not be perfect. Luckily you have many colors to choose from.

Lastly, you collect the output. You simply copy the code by either right click (select all – copy) or use the apposite copy button. The code is then embeded in your page manually. The generated output as you can see is clear css/html where you can optionally specify that classes be used instead of inline css for styling the layout.

Step 4 - Copy the output and embed directly on a web page

The application is written in silverlight and hosted online, but you can opt to run it in OOB mode (out of browser mode). In this mode, the application will run as a desktop application, meaning it will be available to you in offline mode and you don't have to navigate to our website. Instead the application gets installed locally on your desktop and you will be able to launch it from either your start menu or desktop shortcut.

Currently I don't run ads and there is no business model to support this project. Creating the application in silverlight allowed me to keep server costs at a minimum as I have no code running serverside (The only cost to maintain is the domain Abmho.com). The silverlight application itself is hosted on google app engine.

Why did I make it?
While I find it helpful as an application for my own purposes, whether my requirement is to provide highlighted syntax in my applications or in my blog posts, having writing this application has also permitted me to experiment in silverlight/mvvm pattern/prism. Simple applications like this help me to improve my coding efforts on larger projects and make better decisions overall. So why not?

What's next?
Not much really. Next I will be porting this application to metro style on windows 8. Hopefully with minimum effort ( or I like to think so). If I feel like it, ofcourse!

Updates
10/10/2011 --A new version of abmho is out. For those of you who installed the oob mode (desktop version) must first uninstall the previous version (control panel, find abmho and uninstall). And then proceed to our install page and reinstall it. ~~Subsequent releases will update automatically.~~

Update
10/11/2011 --A new version is out. Abmho v1.3 Thanks to everybody reporting problems through the app itself. For OOB mode, we are unable to provide automatic updates because it requires a digital signed code trusted certificate which costs an arm and a leg.

This is a free app, so follow the instructions in the install page. Basically simply right click on the install page, choose to "Remove the application", then proceed to re-install using the same page ( The install button will re-enable itself).

Update
10/11/2011 --A new version is up. Abmho v1.4. Why so many versions in one day? Because I'm making fixes and pushing them out as they are available. This will probably the last one in a while. We now do not require elevated permissions for OOB. What a relief since we don't want to invest in a code signing digital certificate. I'm happy!

Update
10/14/2011 --A new version is up. Abmho v1.6. This fixes an unexpected background worker error when using the wizard then navigating within the site and returning to the wizard again. Many of you reported this problem and you were all very kind. Thanks! We were not disposing the wizard correctly when navigating out of the home page. This is fixed now and I am happy!

Binding data from the ViewModel to the Wpf Menu control

2011-05-05T08:47:00.004+02:00

Databinding the Menu Control in wpf to a viewmodel can require a little bit of effort. As a menu control can contain hierarchical data, you must think of a data model to represent your menu items upfront, so I've decided to write a little about it. But before we dive into the meat and potatoes, lets try the basics first.

Lets see what a simple statically defined menu control looks like and then we'll transform this into a data model we can bind to from our viewmodel.

The statically defined menu :

<Grid>
    <Border VerticalAlignment="Top" Height="25" BorderThickness="0,0,0,1" 
            Background="#FFE4E2E2" BorderBrush="#FFA0A0A0">
        <Menu Height="25" VerticalAlignment="top">
            <MenuItem Header="_File">
                <MenuItem Header="New/Open project"/>
                <MenuItem Header="Save"/>
                <MenuItem Header="Exit"/>
            </MenuItem>
            <MenuItem Header="_Help">
                <MenuItem Header="About us"/>
            </MenuItem>
        </Menu>
    </Border>
</Grid>

When you run the above piece of code, this is what you will see:

Notice that each MenuItem is a HeaderedItemsControl. This is simply an ItemsControl with a Header.

Because each MenuItem is a HeaderedItemsControl, this allows our Menu to have an unlimited number of nesting as each Item has a header ( a label, the title you see displayed in the menu) and then an items collection (the sub menu items). If we wanted to see a qiuck example, this can be easily represented declaratively as follows :

<Menu>
      <MenuItem Header="_File">
           <MenuItem Header="New/Open project"/>
...

See how each MenuItem can in turn contain nested MenuItems, and a Header property is set to the title we want to display.

To bind the Menu control from our viewmodel, we need to be able to set the bindings for each menu items header and additionally we'll need to set a command argument so that we can identify the item clicked.

In order to achieve this we'll have to set bindings through the ItemContainerStyle. This will allow us to target the element generated for each MenuItem so that we can pass the Header value and additionally a command argument value to identify the item. By using a style element in ItemContainerStyle, we can set the TargetType to MenuItem as in the example code below, and the property setters will apply the value bindings to each MenuItem. Perfect.

<Menu ItemsSource="{Binding MenuItems}">
    <Menu.ItemContainerStyle>
        <Style TargetType="MenuItem">
            <Setter Property="Command" Value="{Binding Command}" />
            <Setter Property="CommandParameter" 
                       Value="{Binding CommandParameter}" />
            <Setter Property="Header" Value="{Binding Header}" />
            <Setter Property="ItemsSource" Value="{Binding Items}"/>
        </Style>
    </Menu.ItemContainerStyle>
</Menu>

Let's quickly walk through the piece of xaml above. As you can note, the Menu control itself is bound to a MenuItems collection exposed in our viewmodel.

Xaml :

<Menu ItemsSource="{Binding MenuItems}">

ViewModel:

public ObservableCollection<FileMenu> MenuItems
{
 get
 {
  return (_menuItems = _menuItems ??
   new ObservableCollection<FileMenu>());
 }
}

Xaml :

<Style TargetType="MenuItem">
            <Setter Property="Command" Value="{Binding Command}" />
            <Setter Property="CommandParameter" 
                       Value="{Binding CommandParameter}" />
            <Setter Property="Header" Value="{Binding Header}" />
            <Setter Property="ItemsSource" Value="{Binding Items}"/>
        </Style>

The above xaml binds to each item in the MenuItems ObservableCollection our viewmodel exposes.

Model:

public class FileMenu : ModelBase
{
        ...
 public string Header { get; set; }

 public string CommandParameter { get; set; }

 public ICommand Command
 {
  get
  {
   return (_command = _command ??
    new DelegateCommand<string>(
     OnMenuItemClick, (x)=> IsEnabled));
  }
 }
...
 public ObservableCollection<FileMenu> Items
 {
  get
  {
   return (_items = _items ??
    new ObservableCollection<FileMenu>());
  }
 }
 ...
}

The FileMenu class above represents each item in the MenuItem's collection. As you can see, it's a very simple object with just the needed properties. Note also that each item can also contain child items, this allows us to build a hierarchical menu dynamically in code. If we go back to look at the previous xaml listing above, this is exactly what the following line does :

<Setter Property="ItemsSource" Value="{Binding Items}"/>

The ItemsSource property is exposed by the MenuItem control. In this manner, if each FileMenu Item contains submenu items in turn, they will be bound. Nice!

We now have a perfectly bindable hierarchical menu and what more, it follows the MVVM pattern with clear separation.

Be sure to check out the sample application since code speaks for itself!

Download the sample code

Getting the Most Out of the Winforms PropertyGrid Control in WPF

2011-04-29T17:39:00.015+02:00

The PropertyGrid control has been missing in WPF since it's release and sadly it's still missing! There have been various attempts by third parties to provide one and I cant speak for the commercial offerings but I find the ones in the open source space to be quite lacking and incomplete. Most projects I found on codeplex are still in beta!

I really like the api exposed by the original PropertyGrid which I have been using for years now but it's a Winforms control. This presents some problems. The main issue for me with the Winforms version of the PropertyGrid is that it's not styleable. So it means that I'll have some inconsistency in my UI and it will stick out as shabby and odd.

Below is a screenshot of the PropertyGrid bound to a simple “Person” object, that exposes a complex type Address and a vehicle collection property.

As old as it may look, it works so well and does it job so nicely! I love this control. In the end, I've decided to use this in my Wpf application regardless of the oddity it brings. Clearly, functionality is a lot more important and since beauty lies in the eyes of the beholder, it's a subjective matter. And writing a brand new native Wpf PropertyGrid control is out of the question.

Looks apart, think of the great things this control can do. You practically bind your objects to it and it will list them in a neat grid, categorized, with many builtin editors for color editing, navigating for images, browsing and editing collections using the builtin CollectionEditor etc. And if this is not enough you can write simple extensions with your own custom editors. Indeed this control is a gem!

Update 4/30/2011
It seems since we are referencing a Winforms library, in particular System.Windows.Forms, our client app is forced to reference the fatter .NET 4.0 version versus just the slimmer .NET 4.0 client profile which is the default.

It's not such a big con, but most certainly something to consider. I've left some more instructions at the bottom of this post.

One thing in particular that I've done is to wrap it up in a Custom Wpf Control because in order to use the Winforms version in Wpf, we'll need to :

Interop via WindowsFormsHost (as easy as eating cake)
We'd like to bind our ViewModel to the PropertyGrid directly from the View declaratively. This will allow us to avoid tight coupling with our ViewModel.

Here's what the custom controls template looks like :

<ResourceDictionary xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
                    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
                    xmlns:local="clr-namespace:WpfLab2.Controls"
                   xmlns:o="clr-namespace:System.Windows.Forms;assembly=System.Windows.Forms">
    <Style TargetType="{x:Type local:WpfPropertyGrid}">
        <Setter Property="Template">
            <Setter.Value>
                <ControlTemplate TargetType="{x:Type local:WpfPropertyGrid}">
                    <Grid>
                        <WindowsFormsHost x:Name="host">
                            <o:PropertyGrid x:Name="propertyGrid1"/>
                        </WindowsFormsHost>
                    </Grid>
                </ControlTemplate>
            </Setter.Value>
        </Setter>
    </Style>
</ResourceDictionary>

Minus the namespaces and the common style declarations you'll likely do for any templating requirement, it's fairly simple. All we need is to nest the Winforms PropertyGrid inside a WindowsFormsHost.

<Grid>
    <WindowsFormsHost x:Name="host">
        <o:PropertyGrid x:Name="propertyGrid1"/>
    </WindowsFormsHost>
</Grid>

That's pretty much all of the code. Simple indeed. The Wpf Control itself consists of a single dependency property minus a small plumbing effort. Attached to this article I include a sample application containing the control, so you can get a hang of how it works. Our View itself that consumes the PropertyGrid, just comes down to a single line of code that includes the Custom control binding to a property in the ViewModel declaratively eg:

 <local:WpfPropertyGrid SelectedObject="{Binding PersonItem, Mode=TwoWay}" />

See! Now powered with such a fantastic control you can provide easy editing of objects in your application and maintain your MVVM pattern. I love it.

Make sure you also read the following resource on msdn if your new to the PropertyGrid. It provides all the basics you'll need to know to get you up and running quickly.

http://msdn.microsoft.com/en-us/library/aa302326.aspx (Basics about the PropertyGrid)
http://msdn.microsoft.com/en-us/library/ms742875.aspx (About hosting winforms in wpf)

The sample application included is a basic example using a single person object that in turn has a complex property and a collection property. Once you edit the properties and hit the Ok button, it will display the changes in the object via a messagebox.

Nothing fancy, but you can see some simple mvvm, creation of a simple custom value converter for the complex type “Address” exposed as a property and a the creation of a simple collection editor to allow editing the “Vehicles” collection property. Just enough to get you started.

Update: 4/30/2011

A gotcha I forgot to mention is that you'll have to reference System.Windows.Forms which resides in the System.Windows.Forms assembly. The PropertyGrid control resides in this dll. When trying to reference this library from the project references dialog, you won't find it in the list of available dlls. That's because by default your project is using the .Net 4.0 client profile, so go in your project properties window and change it from .Net 4.0 client profile to .Net 4.0. After this step you can try referencing the dll again and it will be in the list.

The Microsoft .NET Framework 4 Client Profile provides a subset of features from the .NET Framework 4. The Client Profile is designed to run client applications and to enable the fastest possible deployment for Windows Presentation Foundation (WPF) and Windows Forms technology. Application developers who require features that are not included in the Client Profile should target the full .NET Framework 4 instead of the Client Profile.

Update: 5/25/2011

I was able to change the target framework back to the default Client profile after referencing System.Windows.Forms ; It seems this is already in the Client profile. What will throw you off is if your referencing System.Design.dll which will require the Full version of .NET. One typical requirement will arise for you when developing custom TypeEditors because most of the existing type editors are in the System.Design dll. Still thankfully, my needs for custom type editors was pretty basic and I got away developing one from scratch ( inheriting TypeEditor).

I found that not setting height and width explicitly for the control makes its load time slow and at most awkward even. The fix is to be explicit with the height and width. This must be due to layout differences between WPF and Windows Forms. The following article on msdn has the meat and potatoes.

http://msdn.microsoft.com/en-us/library/ms744952.aspx

So, in case its not clear, when using the control, this is what you want to attempt :

<my:WpfPropertyGrid SelectedObject="{Binding PersonItem}" Width="290" Height="350">
            </my:WpfPropertyGrid>

Notice the explicit Width and Height above. Now the speed should be super fast! Keep reading the article on msdn I link to above, it has some pretty good information.

And a small correction to the article, it's not entirely true that you cannot style the property grid. You can do some basic styling of the Winforms PropertyGrid. What you cannot do is enjoy a complete designer experience like you can currently with WPF controls. So, it's not as traggic as I made it sound.

Download the sample application

Custom popup and windows in WPF the MVVM way

2011-04-26T09:11:00.000+02:00

In WPF, using the regular window control to launch child windows makes MVVM and separating a View concern from the ViewModel very difficult.

The problem:
The window control works nicely as a shell for your application, however, launching child windows is problematic because the window control cannot be defined in xaml unless as the root element.
So, if you wanted to launch child windows inside a parent window, you lose the ability to declare these in xaml. This loss means you will not be able to bind to properties in your ViewModel from the view for the purpose of opening/closing a window. Instead you end up doing this imperatively in code which means more code, more thought, more work.

Following is what you end up doing in the most minimalistic cases.

MyWindow window = new MyWindow();
window.ShowDialog();

Adding code such as the above means you are forced to make your ViewModel create instances of your Window and launch them when needed. Clearly something you will not appreciate during testing and since this will provide a tight coupling to a Window control in your ViewModel, it is useless to your tests and eventually breaks your pattern.

What would have been nice instead is if we could do the following :

<my:ModalDialogPopup IsOpen="{Binding FirstPopupIsOpen, Mode=TwoWay}"/>

If we could define our window declaratively in Xam as above, then we use the databinding capabilities in WPF and bind to an FirstPopupIsOpen property in our ViewModel, which is what we are after but sadly not currently possible.

The solution 1: A custom Control that behaved like a Window
Writing a custom control was pretty simple as we make use of the existing Popup control in Wpf. The popup control is pretty wild and requires taming but solves this problem.

Some reasons to design our solution around the existing Popup control:

The popup control is designed to stay always ontop, which has it's pitfalls but it solves more problems than it brings. More specifically we will want the ability to hide the content under the popup while the popup is in view.
The popup control can be positioned in so many ways, however what we are after is the ability to define a set of Left, Top coordinates and this is supported out of the box.
The popup control supports a few animations out of the box. This means we can apply a nice sliding or a fade effect with zero effort.
The popup control can contain child controls obviously. This is great and serves our purpose very well.
Enjoy the beauty of an adorner masking the background beneath the ModalDialogPopup.

The solution we end up with is a control like the following :

<my:ModalDialogPopup IsOpen="{Binding FirstPopupIsOpen, Mode=TwoWay}">
            <my:ModalDialogPopup.HostedContent>
                <ContentControl>
                    <Grid Height="200" Width="300">
                        <TextBlock VerticalAlignment="Center"                              HorizontalAlignment="Center" FontSize="20">
                            This is the first modal popup
                        </TextBlock>
                    </Grid>
                </ContentControl>
            </my:ModalDialogPopup.HostedContent>
        </my:ModalDialogPopup>

One inherent problem I had not considered while writing this control is that just like the Window control, even with a custom popup control, the limitation to not being able to nest a popup in another popup existed. That's because when showing the child, we are forced to hide the parent for technical reasons that exist in the popup control only(the popup control will always be the top most control).

That means if the parent is larger than the child in dimention, portions of controls in the parent will show and interaction with those pieces becomes possible. When a child popup is launched, we want it to behave as a modal window, so it shouldn't be able to interact with controls in popups beneat it. Sadly the adorner cannot help us here as it cannot cover the “Always ontop” popup.

Ofcourse, the solution to deal with this limitation is to hide the parent when the child is in view, which doesn't help the nesting because if the parent is hidden, then the child will be hidden too! I guess there is a good reason why the Window control in WPF does not allow nesting! Too bad I had to discover this at my own expense.

Even with this shortcomings, in most cases, you can workaround the nesting limitation by designing your solutions with this drawback in mind.

As you can note from the piece of xaml code in the previous code listing above, we have a control that can be defined in our view declaratively that takes content via the HostedContent template. We can also set a Title, and content in it's HostedContent template. In the previous code listing, everytime the property FirstPopupIsOpen evaluates to “true” in our ViewModel, the popup will open.

By default the custom popup provides an OK and Cancel button whose caption/visibility you can set. If you need more customizations you can very well customize its template by providing a custom style. Attemping to supply custom styling is quite simple because the default markup we use is plain and this is intentional since styling is subjective and a trival matter. This enables you to provide custom styling of your own without fighting your way through heavy use of xaml.

If you take a look at the code listing below, all we have is a 3 row grid, one holding the title, the second holding the content you define in the HostedContent template and the last row to hold the OK and Cancel buttons. Simply put, you are in control of the styling and the default style template is prive of any bloated styling markup to distract you.

<ResourceDictionary xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
                    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
                    xmlns:local="clr-namespace:WpfPopup.Controls">
    <Style TargetType="{x:Type local:ModalDialogPopup}">
        <Setter Property="Template">
            <Setter.Value>
                <ControlTemplate                      TargetType="{x:Type local:ModalDialogPopup}">
                    <Popup x:Name="dialog" AllowsTransparency="True">
                        <Grid x:Name="content">
                            <Grid.RowDefinitions>
                                <RowDefinition Height="20"/>
                                <RowDefinition Height="*"/>
                                <RowDefinition Height="20" />
                            </Grid.RowDefinitions>
                            <TextBlock Grid.Row="0" x:Name="title" />
    <!-- the hosted content -->
                            <ContentPresenter x:Name="contentHost"                                 Grid.Row="1" Margin="5"/>
                            <StackPanel Grid.Row="2" Orientation="Horizontal"                                 HorizontalAlignment="Right">
                                <Button Content="Ok" x:Name="buttonOK"                                   MinWidth="100" Margin="0,0,5,0" />
                                <Button Content="Cancel" x:Name="buttonCancel"                                    MinWidth="100" Margin="0,0,5,0" />
                            </StackPanel>
                        </Grid>
                    </Popup>
                </ControlTemplate>
            </Setter.Value>
        </Setter>
    </Style>
</ResourceDictionary>

And here it is when popped open in the example solution attached to this post :

It's actually quite a minimal control without any bells and whistles and leave the responsibility of styling it in your hands, any way you want. Notice the adorner masking the background and the convenient Ok/Cancel buttons. It's so much simpler to use and easy to test. The amount of work need to set this up compared to a window control (solution 2 below) is minimal.

Surely there is some value for such a control but it is most definitely not a resonable replacement to the Window control entirely, as far as launching child windows is concerned.

Fortunately, the needed work to decouple the existing Window control from the ViewModel could very well be done with a simple interface contract, which brings us to the next solution.

Solution 2 : Decoupling the Window control from the ViewModel
This solution relies on dependency injection to provide proper decoupling of the Window control from the viewmodel. So, we'll need a dependency injection container. You may use any at this point, I'll be using Microsofts Unity. This will also make it a breeze to inject a stub in place of the Window control when Unit testing.

First, let's look at what we're going to construct. It's going to be a series of dialogs. The main Window, and 2 child windows.

The main window :

A child window launched from the main window above :

And finally another child window launched from the child window above :

Ok, now that we know what we are building, lets start. The procedure is simple. We'll start by defining the common functionality we'd normally use from the Window Control in our ViewModel by throwing it into an interface.

public interface IChildWindow
{
 void Close();
 bool? ShowDialog();
 void SetOwner(object window);
 bool? DialogResult { get; set; }
}

We do this for each View that is a window control. The reason is simple, in order to decouple the window from the viewmodel, what we are going to do is use constructor injection. By injecting this dependency in the constructor we can ensure easy substitution with fake stubs during testing and everything will just work.

Let's also decouple the window we plan to launch by adding yet another interface :

public interface IChildWindowNested
{
 void Close();
 bool? ShowDialog();
 void SetOwner(object window);
 bool? DialogResult { get; set; }
}

And finally, the viewmodel:

public class ChildWindowViewModel
{
 private readonly IChildWindow _childWindow;
 private readonly IChildWindowNested _childWindowNested;
 private ICommand _okCommand;

 private ICommand _openCommand;

 public ChildWindowViewModel(IChildWindow childWindow,
    IChildWindowNested childWindowNested)
 {
  _childWindow = childWindow;
  _childWindowNested = childWindowNested;
 }

 public ICommand OpenCommand
 {
  get
  {
   return _openCommand ?? (_openCommand =
    new DelegateCommand(OpenClick));
  }
 }

 public ICommand OkCommand
 {
  get
  {
   return _okCommand ?? (_okCommand =
    new DelegateCommand(OkClick));
  }
 }

 private void OpenClick()
 {
  _childWindowNested.SetOwner(_childWindow);
  _childWindowNested.ShowDialog();
 }

 private void OkClick()
 {
  _childWindow.DialogResult = true;
  _childWindow.Close();
 }
}

As you can notice in the above class, we are passing 2 interfaces in the constructor. The first is the window using this viewmodel : ChildWindow.xaml and the second is the window it will launch : ChildWindowNested.xaml

The relationship between these two windows is a typical parent child relationship, ChildWindow.xaml is the parent, while ChildWindowNested.xaml is the child being launched.

The reason we pass IChildWindow, the parent window in this case is because :

We need to tell the child Window we are launching who it's owner is. That way we can nicely position the child window relative to it's parent.
As this is the viewmodel of ChildWindow.xaml, we will also want to handle closing this parent window when it's Ok and Cancel buttons are clicked.

The reason we pass IChildWindowNested, the child window we are launching is because:

We want to launch this dialog based on an action in ChildWindow.xaml
To decouple the window from the viewmodel, because we will be using dependency injection to set up this dependency on the window control.

Now the codebehind for ChildWindow.xaml :

public partial class ChildWindow : Window, IChildWindow
{
 private readonly IUnityContainer _container;

 public ChildWindow()
 {
  InitializeComponent();
  _container = UnityContainerResolver.Container;
  var childWindowNested =                              _container.Resolve<IChildWindowNested>();

  DataContext = new ChildWindowViewModel(this,                                                 childWindowNested);
  Closing += ChildWindowClosing;
 }

 #region IChildWindow Members

 public void SetOwner(object window)
 {
  Owner = window as Window;
 }

 #endregion

 private void ChildWindowClosing(object sender, CancelEventArgs e)
 {
  e.Cancel = true;
  Visibility = Visibility.Hidden;
 }
}

We can setup the viewmodel binding to the DataContext in several ways however doing this in the codebehind of the view as in the sample code above is the most flexible of all solutions especially if your moving beyond the typical blog post samples.

At the end of the day, it's only a matter of opinion and what's important is that there is no dependency impeding you from testing your application. And ofcourse that it does not break your pattern. In our case, it's both convenient as we want to pass a reference of the current window to the viewmodel and at the same time, we want to do it in a very decoupled way to help us test our viewmodel.

Also note that we are hooking into the closing handler and cancelling the default close behavior of the Window control. That's because once a window is closed, we cant reopen it and we'll need to create a new instance of the window.
Certainly this depends on your use case. For me, my requirements are such that I need to reuse the window being closed. This works nicely.

What about dependency injection and how is our Unity container setup ? It's quite simple in this case. For this sample code, I just created a singleton that registers all dependencies with the container :

public class UnityContainerResolver
{
 private static IUnityContainer _container;

 private UnityContainerResolver()
 {
 }

 public static IUnityContainer Container
 {
  get
  {
   if (_container == null)
   {
    _container = new UnityContainer();
    RegisterTypes();
   }
   return _container;
  }
 }

 static void RegisterTypes()
 {
  _container.RegisterType<IMainWindow, MainWindow>();
  _container.RegisterType<IChildWindow, ChildWindow>();
  _container.RegisterType<IChildWindowNested,                                                     ChildWindowNested>();
 }
}

That's it. By registering dependencies with a dependency container, it becomes so easy to inject fakes in our viewmodel in place of the real object. In our case, when testing, we can make a different registration by mapping to our fake mock objects and this is relatively simple when using a dependency container :

static void RegisterTypes()
{
 _container.RegisterType<IMainWindow, MockMainWindow>();
 _container.RegisterType<IChildWindow, MockChildWindow>();
 _container.RegisterType<IChildWindowNested,                                   MockChildWindowNested>();
}

And MockChildWindow having enough code to satisfy the contract of IChildWindow.

public class MockChildWindow : IChildWindow
{
 public object Owner { get; set; }
 public void Close()
 {
  //
 }

 public bool? ShowDialog()
 {
  return true;
 }

 public void SetOwner(object window)
 {
  Owner = window;
 }

 public bool? DialogResult
 {
  get;
  set;
 }
}

The viewmodel itself only uses methods exposed by the contract so we are safe to use a fake object as above for testing.

I have added a test app containing the custom popup and all code discussed here. Be sure to check it out!
Download sample application

Display and Editor Templated View Helpers in ASP.NET MVC

2011-04-21T19:11:00.000+02:00

Templated view helpers simplify your work greatly by allowing you to specify that rendering is required for display or input via Display and Editor templated Helpers respectively without needing to explicitly specify what Html element to map the properties to, in our model.

For example, given the following controller that is passing a model to the view :

// Get: /Home/Edit/1
public ActionResult Edit(int id)
{
 var p = GetPerson(id);
 return View(p);
}

Now, without resorting to Templated View Helpers, in order to display our model for edit, in the view we can attempt to offload the task of rendering an appropriate Html element for a property in our model to a View Helper :

@model MvcLab.Models.Person

@{
    ViewBag.Title = "Edit a person";
}

@using (Html.BeginForm()) {
    @Html.TextBox(Model.FirstName);
}

in the above example, Html.TextBox will output :

<input id="FirstName" name="FirstName"        type="text" value="Alessandro" />

By using the Html.TextBox helper, we were able to specify explicitly what input element we wanted mapped to a property in our model.

This is nice but we've had to explicitly state that we wanted a TextBox mappped to the FirstName field.

The same can be achieved by using Templated View Helpers which are yet a more convenient way to associate an Html element to a property in our model :

@using (Html.BeginForm()) {
    @Html.EditorFor(x => x.FirstName);
}

The above piece of code will also render an Html input element :

<input class="text-box single-line"       id="FirstName" name="FirstName" type="text" value="Alessandro" />

The output is pretty much the same, but notice that we didn't explicitly state what element to associate to the FirstName property. How this works is that it bases its assumption on the data type of the property and whatever model attribute meta data decorations set on it.

In ASP.NET MVC 2 onwards, there are 3 Editor Helpers that do the same thing with slight differences in usage. @Html.Editor, @Html.EditorFor and @Html.EditorForModel, the first can take a string containing our property name and the second a strongly typed model to property mapping expression and the third will just use the strongly typed model passed to the view by default.

They each provide some flexibility how the Editor Template View Helper is used. We'll be using @Html.EditorFor and @Html.EditorForModel for the remainder of this post.

The following piece of code in the view uses EditorForModel.

@model MvcLab.Models.Person

@{
    ViewBag.Title = "A person";
}

@using (Html.BeginForm()) {
    @Html.EditorForModel();
<p><input type="submit" value="Save" /></p>
}

<p>
    @Html.ActionLink("Back to List", "Index")
</p>

Something as simple as @Html.EditorForModel(); will output an input element for each property in our model. Notice how we didn't loop nor needed to pass the model. Since we're passing the Model in the view, using the default no arguments overloads works just nicely. The above piece of code in the view will output to screen :

While this renders our model, we can see that the output needs a bit more tweaking, for example the field labels are using the property name, this can be tweaked on the model itself using attribute decorations such as :

[DisplayName("First name")]
public string FirstName { get; set; }

Next, the id field is displaying. We'd rather this was not displayed, as this too can be compensated for by providing another attribute decoration on the property such as :

[HiddenInput(DisplayValue = false)]
public int PersonId { get; set; }

Completed person class after the noted changes :

public class Person
{
 [HiddenInput(DisplayValue = false)]
 public int PersonId { get; set; }
 [DisplayName("First name")]
 public string FirstName { get; set; }
 [DisplayName("Last name")]
 public string LastName { get; set; }
 public Address Residence { get; set; }
}

This renders as below :

That's much better, yet now we can note that our complex property Residence, which is a class with its own set of properties, did not render. In order to fix this we can try the following :

@using (Html.BeginForm()) {
    @Html.EditorForModel();
 @Html.EditorFor(x => x.Residence);
<p><input type="submit" value="Save" /></p>
}

<p>
    @Html.ActionLink("Back to List", "Index")
</p>

While this is all great and works by convention, we do eventually lose fine grained control over how each field is rendered in the end. One option is to go back to rendering each field individually eg: @Html.EditorFor(x => x.FirstName) directly in the view, but then if we need to reuse this model in another view, we keep repeating each field over and over again. The extra code in each view also begins to weigh on us and becomes unmaintainable sooner than later.

One way to solve this is to move the logic into a Partial view which can then be reused in a single line of code on other views where we'd want to render a Person model. An even nicer approach is to use convention, again designating Editor and Display templates for our Templated View Helpers. Using this approach will result in providing us with fine grained control over the output. Lets try that now.

Instead of creating the rendering for our model in the view directly, lets move it to a partial view. Following convention for Templated View Helpers, the partial view (template) needs to be stored in the following locations :
/Views/Shared/DisplayTemplates/TemplateName.cshtml and /Views/Shared/EditorTemplates/TemplateName.cshtml.

And since our model is a Person object, we will name our template Person.cshtml for both Display and Editor templates. This is to follow convention as that is the template it will look for based on the type name. There is still more flexibility in defining a template by using meta data attributes UIHint and passing a template name there or by passing a template explicitly in the Templated View Helper itself.

To keep the post simple we are going to use only default convention and setup custom EditorTemplates as the procedure is the same for DisplayTemplates. Along with the article I've included a sample application that shows usage for both Display and Editor templates.

/Views/Shared/EditorTemplates/Person.cshtml :

@model MvcLab.Models.Person

@Html.ValidationSummary(true)
<fieldset>
    <legend>Person</legend>

    @Html.HiddenFor(model => model.PersonId)

    <div class="editor-label">
        @Html.LabelFor(model => model.FirstName)
    </div>
    <div class="editor-field">
        @Html.EditorFor(model => model.FirstName)
        @Html.ValidationMessageFor(model => model.FirstName)
    </div>

    <div class="editor-label">
        @Html.LabelFor(model => model.LastName)
    </div>
    <div class="editor-field">
        @Html.EditorFor(model => model.LastName)
        @Html.ValidationMessageFor(model => model.LastName)
    </div>
</fieldset>

<!-- Note that the Residence property is a complex type for whom
 we've defined a template too in : Views\EditorTemplates\Address.cshtml -->
 @Html.EditorFor(model => model.Residence)

and now a Template for Address, though we could have done it in the Person object itself, as this gives us the flexibility of reusing the Address models rendering in any view.

/Views/Shared/EditorTemplates/Address.cshtml

@model MvcLab.Models.Address

    <fieldset>
        <legend>Address</legend>

        <div class="editor-label">
            @Html.LabelFor(model => model.City)
        </div>
        <div class="editor-field">
            @Html.EditorFor(model => model.City)
            @Html.ValidationMessageFor(model => model.City)
        </div>

        <div class="editor-label">
            @Html.LabelFor(model => model.Country)
        </div>
        <div class="editor-field">
            @Html.EditorFor(model => model.Country)
            @Html.ValidationMessageFor(model => model.Country)
        </div>
    </fieldset>

Note that, upto this point, we have not written a single line of code. What we see so far is all auto generated scaffolding when electing to set a strongly typed class on a partial view in Visual Studio itself. This is much quicker and we're left with remodeling the markup to fit our design requirements.

Below is a screenshot of the Add View dialog that we've used to autogenerate most of the code above.

Next, we are finally ready to reuse these templates in our views :

/Views/Home/edit.csHtml

@model MvcLab.Models.Person

@{
    ViewBag.Title = "Edit a person";
}

@using (Html.BeginForm()) {
    @Html.EditorForModel();
<p><input type="submit" value="Save" /></p>
}

<p>
    @Html.ActionLink("Back to List", "Index")
</p>

Note that the code in our view and every other view that wants to reuse the Person model has gone down to a single method call : @Html.EditorForModel()

and the output :

Final conclusions :
As we have seen, by using Templated View Helpers, we were able to promote reusability of our models rendering and in the process we were not limited by typical black box solutions as we were able to gain fine grained control by defining custom templates for our models.

Best yet, we followed convention over configuration and ended up doing little work with improved productivity and maintainability of our code. Following the same procedure here on this post, we can define custom templates for Display View Helpers too in the same way we provided templates for Editors.

The sample application provided along with this post defines templates for both Display and Editor Helpers.

This is what it all looks like in solution explorer :

Sample application : download
Reference material :
http://msdn.microsoft.com/en-us/library/ee402949.aspx
http://msdn.microsoft.com/en-us/library/system.componentmodel.dataannotations.uihintattribute.aspx

MARS - Multiple Active Result Sets support in SQL Server 2005 and above

2011-04-19T12:11:00.000+02:00

SQL Server 2005 onwards supports MARS - Multiple Active Result Sets. MARS enables you to reuse an existing connection to perform operations on SQL Server. This makes MARS a viable alternative to server-side cursors with significant performance boosts. As powerful that may seem it has it's drawbacks so care needs to be taken when using it.

Here's an example from msdn:

SqlCommand cmd = conn.CreateCommand();
SqlCommand cmd2 = conn.CreateCommand();
cmd.CommandText = @"select operation_id, operation_code, product_id, quantity 
      from dbo.operations where processed=0";
cmd2.CommandText = @"update dbo.operations set processed=1 
      where operation_id=@operation_id";
SqlParameter opid=cmd2.Parameters.Add("@operation_id", SqlDbType.Int);
reader=cmd.ExecuteReader();
while (reader.Read())
{
   ProcessOperation();
   opid.Value=reader.GetInt32(0); // operation_id
   //notice how we are trying to execute an update query on the second command
   //this is going to fail miserably because
   //we did not set MutipleActiveResultSets=Yes 
   //on the connectionstring
   cmd2.ExecuteNonQuery();
}

By default MARS is not enabled. So reusing the same connection as the example above will throw an exception of type :

InvalidOperationException, There is already an open DataReader associated with this Connection which must be closed first.

Say hello to MARS :

Enabling usage of MARS is as simple as setting MultipleActiveResultSets=Yes on your connectionString, eg:

<connectionStrings>
    <clear />
      <add name="TyppsDB" 
         connectionString="Data Source=typps-pc;Initial Catalog=TyppsDB;
                 Integrated Security=True;MultipleActiveResultSets=Yes" />
 </connectionStrings>

you can now issue multiple commands on the same connectionstring which can result in a performance boost since opening and closing a connection can be expensive.

When retrieving recordsets, the client has to eager load, meaning consume the resultsets immediately as oppossed to executing the command and not reading the data. Not doing so will cause the server-side buffer(Where sql server is hosted) to hold on to the data in memory and tie up resources, locks, threads etc something you want to avoid.

Instead you want the data to stream to the client as fast as possible as the server returns the resultset without the server holding a large recordset in memory and tying up resources. This is not specific to MARS by the way, but when used correctly with eager loading meaning you consume the data as the command is executed you can benefit from a significant performance boost as you have the ability to execute more commands and retrieve data seamlessly without the overhead of closing and reopening a connection to Sql Server.

myReader = myCommand.ExecuteReader(); while(myReader.Read())
{
 //consume immediately now, don't wait.
}

Any command that is a SELECT, FETCH, READTEXT, RECEIVE, BULK INSERT (or bcp interface) or Asynchronous cursor population can take full advantage of MARS.

What this means is that with MARS enabled, each of these commands listed above are defined in terms of interleaved executions, allowing them to be processed atomically within the same connection but with the ability to interleave, this means they can resume execution from the points where they were suspended if at all suspended.

For instance, INSERT and UPDATE cannot take advantage of MARS. Now, consider a long running INSERT or UPDATE operation followed by a SELECT statement, all executing within the same connection. Such an operation will suspend the SELECT command until the UPDATE or INSERT has completed and then resume the SELECT operation.

Consider reversing the above example where you had a SELECT followed by an UPDATE or INSERT operation within the same connection. Even in this case, if the UPDATE or INSERT command are issued while the SELECT is executing, then the SELECT command will interleave and as such become suspended until the INSERT or UPDATE complete and only after completion of the UPDATE or INSERT operation, will it resume execution.

This is because the SELECT command can take advantage of MARS and has the ability to resume from the point where it was suspended making it an interleaved execution.

Lastly, note that there are some intricacies when using transactions with MARS. You will need to workaround using recommendations provided eg: by using batch-scoped transactions.

References :
http://msdn.microsoft.com/en-us/library/ms345109(v=sql.90).aspx
http://msdn.microsoft.com/en-us/library/ms174377.aspx

.NET exceptions, error handling for the exceptional case

2011-04-18T11:25:00.000+02:00

The tip of the day consists of, in making sure to use a try/catch block to trap individual exception types such as SqlException which is specific whereas Exception being more general.

For instance, imagine you are connecting to a database, it's quite common to experience a connection failure that you might not expect. So it makes sense to try to handle any unexpected connection failures.

First, try and discover the SqlConnection members class on msdn and drill down to the SqlConnection.Open method, there's a section including the exceptions that the open method may throw and we find two :

InvalidOperationException and SqlException with the specifics on what the conditions are when these exceptions are thrown.

Similarly, we can write code likewise :

try
{

 //connect to db and do something useful
}
catch(InvalidOperationException invalidException)
{
 // specific exception
 // usually occurs when trying to open a conenction
}
catch (SqlException sqlexception)
{
 // specific exception
 // will occur when opening a connection
}
catch (Exception exception)
{
   // lastly the general exceptional case will kick in
   // could be anything that the first two exceptional cases didn't catch.
}

Note how Exception ( the mother of all exceptions) is handled last and instead we branch out by starting with more specific exceptions, InvalidOperationException and SqlException. This allows us to catch more specific exceptions and then move on to the more general exceptions. This is a good practice.

Lastly, when logging your exceptions, use the default implementation of ToString of the exception thrown to obtain the name of the class that threw the current exception, the message, the result of calling ToString on the inner exception, and the result of calling Environment.StackTrace with line number etc.

Final notes:
If an exception can be handled programmatically without resorting to try/catch then investigate that route first. Handle the exceptions that are relevant to your code, throw back everything else. Read Best Practices for Handling Exceptions

References :
http://msdn.microsoft.com/en-us/library/seyhszts.aspx
http://msdn.microsoft.com/en-us/library/system.exception.tostring.aspx
http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlconnection_methods(v=VS.71).aspx
http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlconnection.open(v=VS.71).aspx

Silverlight or Html5 - from A .NET developer perspective.

2011-04-15T10:43:00.000+02:00

Html5 vs Silverlight for the .NET developer :

If you are already invested in .NET, then you have been honing a particular set of skills for the past decade. This puts you at a position where it is difficult to favor Html5 simply because you lose some agility and sometimes this may make all the difference.

Since MIX11, there is much debate with regard to Html5 vs silverlight. And developers continue to ask, what should I use. When I try to make a decision on the technology to use and power my applications the following facts helps me consolidate my ideas and beliefs further and this is also my current state of mind.

Silverlight is cross browser / platform

Note: This is great news if we are comparing silverlight to wpf but when compared to html5, we can agree on one thing. Html5 will be available on many more devices so it's not actually a pro for silverlight however, it's good to note that silverlight runs on those devices where it counts :

All major browsers on both the mac and windows are supported. *nix support through Novell mono moonlight, which currently lags a bit behind but don't let this be a show stopper for you. You can easily develop a secondary slim version that works for moonlight which currently fully supports version 2.0 of silverlight and one that supports 3.0 is almost complete.

Depending on the features your using, you might even be able to provide support for your application in it's full glory or perhaps with a minor workarounds if this audience is very important to you. Finally you also get to target the mobile platform wp7(Currently html5 support is lagging on wp7).

Strongly typed languages support (c#, vb.net). Unlike losely typed languages, you will benefit greatly from compile time error checking, and many language specific features.

Easy deployment --your compiled silverlight assembly includes the compiled code and xaml files for all your pages in your application. These files are embedded as resources and are compressed. While this is the default, it's also very flexible, meaning you can split your code in modules that can be dynamically downloaded by your silverlight application upon request. Tip: Prism is a great library if you want to benefit from modularity among other things in your silverlight apps.

First class IDE support. Not only are you benefiting from superb IDE support for both designing your applications in expression blend while doing the development in visual studio, but your way of working changes very little if you are already a developer in the microsoft space. Note that we will soon see some pretty good IDE support for Html5 as well, so this particular con for html5 won't hold true for very long.

Reuse existing known code patterns. Patterns and practices have been gathered over the years and are a way for us to reuse "experience" in our development. Some are our own, some are industry known patterns and practices. On the other hand, Javascript too has been around for a very long time and they too have adopted their own set of patterns and practices, but clearly as a .NET developer, with silverlight, you don't have to relearn anything. I do heavy development in both c# and javascript, so this point is pretty moot for me, however, it's an important decision maker when chosing the right technology.

Reusing existing code --You already have existing code written for the .net framework, be it code that simply executes on the server or perhaps a WPF desktop application. Porting this code to run on the client instead in silverlight is much easier than rewriting it from scratch in javascript.

As a web developer, you write client-side code for Silverlight in the same language that you use for server-side code (such as C# and VB), similarly you will be able to leverage the same objects you use on the server, so : generics, LINQ, Lambda, collections and many more even though only a subset of the .NET framework classes.

IE8, 7 and 6 support is important to you because you still have a lot of clients on these browsers. This is a given in silverlight, yet these browsers currently do not support the html5 featureset. Using another third party plugin such as google frame to target content to this user group ( also currently constituting the majority) is out of the question. Why should the largest portion of your userbase be served in downlevel?

Install and upgrade --fully managed install and upgrade mechanism in place for Silverlight. This means as new versions of silverlight are made available, we can start using them in our applications right away and based on the runtime version of silverlight your applications are built against, that version will be used or the user will prompted to download and install it. This is fully managed by Microsoft and you do nothing in this department other than some minimal configurations such as MinRuntimeVersion and so forth.

Counter this with Html5, where features that constitute Html5 are supported at the discretion of the browser vendor. This means each browser vendor will pick up the feature they think is useful or important and will implement it. This makes it quite easy to find a feature that works in one browser but doesn't work in another or simply a feature that works in the latest versions of the browser while your left working around to compensate for the feature loss in older versions.

In fact not too long ago whatwg has officially moved to a non-versioned model where Html5 is simply known as Html. This move by whatwg makes sense to me also because no browser currently supports the entire featureset of Html5 and therefore the name is misleading. Infact no browser ever supported html4 completely. Silverlight, being a plugin does not suffer from this lack of feature uniformity across browsers/devices.

Final notes :
One thing is sure, Html5 has been a hot topic for a while now and with the release of ie9 it has gotten even hotter. This is a fresh area with room for plenty of innovation and new business opportunities to tap into. Like all new things, there's a gold rush. Everybody is pushing out web applications that uses shiny new Html5 features, because that is the current trend and there's lots of room for investment. This is a large market segment with a wider audience.

As a .NET developer, if you are selling development tools, you are no longer confined to Microsoft developers, instead suddenly the web is your oyster. Lastly, it makes the headlines to invest in Html5 at this early stage, which can quickly translate to free marketing for you. That's someting to consider as well.

So, in the end, which one is the better? Today I'm confident about my silverlight investment because it made sense for my application and it's needs. However on a different project, I may sing a different tune all together. Sadly, there is no better choice. You know your application, only you know what it needs.

For instance I developed Abmho based on need. I couldn't find a proper syntax highlighter on the web that simply worked, that wasn't riddled with adverts and one that didn't require me to make a request to the server everytime. Soon this became irritating and so I decided to make one myself.

It was important that my syntax highlighter executed in the browser as an application and was fast and responsive. I also wanted to complete development fast and I have a .NET background. I also already had a syntax highlighter library in c#. Rewriting this library in javascript would have simply taken forever. It was certainly not worth the effort.

This move allows me to ship a wpf version (currently in the works) that requires subtle minimal changes to get working as a full fledged desktop application that I will be making available soon since Silverlight is a subset of Wpf. All this wouldn't be possible if I had gone the Html5 route.

Setting up a ConnectionStrings in .NET

2011-04-15T10:16:00.000+02:00

ConnectionStringBuilder :

Tip for today is the ConnectionStringBuilder class. This is quite an unknown class but can result very useful in building your connectionstring. Normally, you'd take a connection string and pass it directly to your connection objects such as SqlConnection or DbConnection classes directly.

Quick example from msdn :

private static void CreateCommand(string queryString,
    string connectionString)
{
    using (SqlConnection connection = new SqlConnection(
               connectionString))
    {
        SqlCommand command = new SqlCommand(queryString, connection);
        command.Connection.Open();
        command.ExecuteNonQuery();
    }
}

As you can note from this classical example above, the connectionstring is passed directly to the SqlConnection object's constructor. While this is fine, any error in the connection and it's quite easy to make a mistake, won't be known until the connection is opened.

Further more, if you want to pass some additional values, or modify existing values in the connectionstring it can be time consuming and again error prone and more effort than you want to invest.

Say hello to the ConnectionStringBuilder. What this class does for you is that it facilitates parsing a connection string and also provides named properties you can simply set in code or whose values you want retrieved. A classic code example from msdn itself :

using System.Data;
using System.Data.SqlClient;

class Program
{
    static void Main()
    {
        // Create a new SqlConnectionStringBuilder and
        // initialize it with a few name/value pairs.
        SqlConnectionStringBuilder builder =
            new SqlConnectionStringBuilder(GetConnectionString());

        // The input connection string used the 
        // Server key, but the new connection string uses
        // the well-known Data Source key instead.
        Console.WriteLine(builder.ConnectionString);

        // Pass the SqlConnectionStringBuilder an existing 
        // connection string, and you can retrieve and
        // modify any of the elements.
        builder.ConnectionString = "server=(local);user id=ab;" +
            "password= a!Pass113;initial catalog=AdventureWorks";

        // Now that the connection string has been parsed,
        // you can work with individual items.
        Console.WriteLine(builder.Password);
        builder.Password = "new@1Password";
        builder.AsynchronousProcessing = true;

        // You can refer to connection keys using strings, 
        // as well. When you use this technique (the default
        // Item property in Visual Basic, or the indexer in C#),
        // you can specify any synonym for the connection string key
        // name.
        builder["Server"] = ".";
        builder["Connect Timeout"] = 1000;
        builder["Trusted_Connection"] = true;
        Console.WriteLine(builder.ConnectionString);

        Console.WriteLine("Press Enter to finish.");
        Console.ReadLine();
    }

    private static string GetConnectionString()
    {
        // To avoid storing the connection string in your code,
        // you can retrieve it from a configuration file. 
        return "Server=(local);Integrated Security=SSPI;" +
            "Initial Catalog=AdventureWorks";
    }
}

Note: the same applies for the generic non SqlClient class DbConnection and you'd use the apposite DbConnectionStringBuilder class.

Lastly, retrieving the connectionString itself can be facilitated by using Server explorer, after having made the connection to the database visually in VS.NET you need to select your database in solution explorer and right click - Properties. From the property grid you can see the connectionstring VS.NET is using. That is the connectionstring you want.

Alternatively you can use create a DataLink and copy the autogenerated connectionstring created by the DataLink. Follow the url in the references section below.

Reference material :
http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlconnectionstringbuilder.aspx
http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlconnection.aspx
http://msdn.microsoft.com/en-us/library/ms718102(v=vs.85).aspx ( DataLink )
http://msdn.microsoft.com/en-us/library/33wwc2yw(v=VS.80).aspx (Server Explorer)

Typps 3.1 released

2011-04-10T18:00:00.000+02:00

A new 3.1 stable release is available for download.

Typps 3.0 released

2011-03-29T08:59:00.000+02:00

We haven't been blogging much. We'll try to improve in that too. In the mean time know that

3.0 is now released. This version fixes many problems among which issues in IE9.

Typps Version 2.7 released

2010-11-12T22:47:00.000+01:00

We have a new release that fixes an important bug in when running the editor in a website that targets .NET 4.0 and Ajax control Toolkit. This release does not break any features so it should be a fairly easy upgrade.

Currently we are restructuring code in preparation for new features. So unless there is a major bug to fix, we will be skipping a few iterations.

One of the things we don't currently do is check in our code on codeplex. Instead we make releases and put out packages in the download section. Hopefully from the next release onwards we will start doing that too.

Silverlight is all that and a bag of chips

2010-11-11T02:19:00.000+01:00

Recently there's been a lot of FUD around silverlight and how microsoft is making a shift in strategy, which by the way is a good thing. Silverlight questions for more.

While I like standards and HTML5, I want it all today. I'm currently invested in silverlight, I love the DEV tools, great community that Microsoft managed to build around it during the past 3 years and currently it enjoys a good 60% penetration rate.

60% is kind of OK for me, afterall, it's a free plugin with a small footprint. It costs nothing to the end user to install. If they want to use my application, they will eventually get it. Best yet, I don't have to worry about ie6,ie7 and ie8 not supporting it.

People right now are still confused on which way to swing. Silverlight vs Html5 because IE9 is releasing soon with support for HTML5.

My reasons to continue to stick to silverlight is simple.

I am porting existing c# code I used to run serverside, to now run on the client.
IE6,IE7,IE8 support. Even with IE9 out there, we still have to worry about these currently dominating browsers. I simply refuse to use yet another plugin ( google frame ) to provide HTML5 support.
Silverlight has proper development tools, enviornment and a thriving community. I cannot say the same about HTML5 and SVG.

What are others worried about ?

Silverlight

Flash

HTML5

whoops, I might be in a little trouble <:o) Just kidding. I understand the fear. But nothing is going to change, reality is what it is. Silverlight is all that and a bag of chips. I shall continue developing my application in silverlight. I will update this post when the release is up.

Update 4/19/2011 : The release is up and has been up for almost a month. I just forgot to update this post.
Your all welcome to check it out. abmho.com

It's still in beta.

Typps Version 2.2 released

2010-08-21T18:36:00.000+02:00

After 8 months of heavy development, Typps is back with a vengence. This new version marks a milestone because the code base has gone a partial rewrite and includes numerous bug fixes and new features that we shall be documenting soon.

Infact we shall soon provide a backlog so people know what feature is being worked on and where we are headed. In this release we have stalled many times but this is due to the numerous problems we were trying to tackle in Typps. To make it worse, we under went a complete rebranding phase and we are now officially called Typps. Along with the new name we have revamped our site, moved our discussions to codeplex ( much more consistent and less maintenance work for us).

We are however still lacking in documentation and demo pages to showcase on http://demo.typps.com/ ; the demo pages are also downloadable on codeplex. This allows you quick access to seeing how everything works. There are a lot of plans for typps and where we are headed, eg : more documentation, video tutorials, a faster release sprint (while adopting agile methodologies), supply more unit tests ( our current unit tests are quite scarce and broken). Moving forward, we also want to provide MVC support and silverlight.

MVC and silverlight are important, in this manner we can reuse the same components across various project types without resorting to alternatives etc.

This new release does not offer an upgrade, so don't expect to upgrade your existing apps by simply copying the dll. There are a lot of breaking features to take this to the next level. If you encounter issues, report them on codeplex.

We have rebranded to Typps (Formerly jiffycms)

2010-08-01T05:32:00.000+02:00

Lots to do and so little time. With a little bit of patience it will all be done and we will put up the latest release on codeplex.
This is the very first post on our new blog! Finally. In the my next post entry I'll write a little on why we rebranded and the reason to move into the cloud. Why google apps and blogger and what happened to our cms? ಠ_ಠ
But now it's time to put up some documentation and wrap up this release.

Note that previously we maintained our own forums too. We are now using the forum on codeplex, so use that to report any issues or ask for help http://typps.codeplex.com/Thread/List.aspx

Conserving Resources When Writing BLOB Values to SQL Server and Streaming BLOB Values back to the Client

2008-09-23T01:22:00.003+02:00

Reading and writing blob data to/from your database can be a resource hog, because it normally involves holding the entire stream in memory. Holding 10kb, 20, 100kb in memory might not be an issue, however as you start allowing larger file uploads, your application starts to feel the stress and easily starts to run out of resources.

Particularly, say you had a relatively small file (2mb) your allowing users to upload from your pages. User A uploads, it's only 2mb, you have not exceeded your memory allocation yet. However, as more users try to upload simultaneously, now your allocating more memory slots at a time, eg. if they were 5 simultaneous users, that's 2*5 = 10mb, 100 users, then it's 2*100.

This is all too stressful on your webserver, or atleast was until ASP.NET 2.0. Since, things have changed and now asp.net supports setting a diskThreshold that allows you to specify the amount of data buffered in server memory for the request. So, say you wanted to keep the default diskThreshold of 256 bytes, when the file is larger than 256bytes, asp.net begins to write the filestream to disk Versus keeping it in memory. This is just great because i remember back in the day, this was quite annoying. Glad it's fixed. This means we do nothing as far as the upload is concerned from the client to your webserver.

Still, if we are storing the stream in SQL Server, now we have a whole new scenario, and the question remains, how do we stream this data to sql server while conserving memory ? Should we stream the entire data as is in one lump ? Wont that allocate memory on our database server before writing to the database field ? This is what i want to address. Basically, what we want to do is save our file stream to sqlserver in smaller chunks, that way our database server will allocate only enough memory for that little chunk before writing it to the database field, in this way conserving memory at the cost of write speed(no free lunch, i'm afraid).

However, the price to pay in latency for streaming chunks of data to sql server might be well worth, because the alternative is to tax your database server when memory is available and to crash it (I assume it may crash when it runs out of memory. I have not tried personally. You may try that yourself if your feeling curious. Do not forget to share your findings if you do :P)

Take, SQL SERVER Express edition as an example which has the imposed limit of 1gb memory. That's not a whole lot is it ? Streaming the data to sql server in chunks is actually not as taxing as it may seem. True, the write performance is degraded but you can regulate it by increasing/decreasing the size of your chunk to find a compromise.

So, how do we do this ? SQL Server 2005 has a new feature that enables it to update a field with .WRITE ; as you stream your chunks it just appends it to the existing field. You can read about it here : http://msdn.microsoft.com/en-us/library/ms177523.aspx

To Quote the documentation from the above link :
Because the .WRITE clause cannot be used to modify a NULL column, the column is first populated with temporary data. This data is then replaced with the correct data by using the .WRITE clause

Now, that's not cool! We can work around that nicely though. Ineffect, it does not even feel like were working around anything. I've basically followed microsofts own documentation located at : http://msdn.microsoft.com/en-us/library/aa719771.aspx, which had the proper code, however, instead of .Write, it uses an older method that is not compatible with the newer varbinary,varchar(max),nvarchar(max) datatypes supported by SQL Server 2005 as opposed to the older not recommeded types -> image, text, and ntext.

Following is an extract of the code i use to stream chunks of data to sql server using the .Write method. The purpose of the sample code is to display how you can go about writing your own ofcourse. I have just ripped the piece of code out of my DAL with a few minor adjustments, so just running a copy/paste of the code below will or may not yield much depending on your level of expertise. I am just way too lazy to write a completely contained example so bear with me. As it is, this article has gotten longer than I want it to be.

public void InsertFile(string applicationName, Stream data,
  string mimeType, string fileName)
 {
  int fileId = -1;
  using (SqlConnection myConnection = GetSqlConnection())
  {
   myConnection.Open();
   SqlCommand cmd = new SqlCommand(DbOwner +
    ".DataFile_Insert", myConnection);
   cmd.CommandType = CommandType.StoredProcedure;
   cmd.Parameters.Add("@applicationName",
    SqlDbType.NVarChar, 256).Value = applicationName;
   cmd.Parameters.Add("@mimeType",
    SqlDbType.NVarChar, 50).Value = mimeType;
   cmd.Parameters.Add("@length",
    SqlDbType.Int, 4).Value = data.Length;
   cmd.Parameters.Add("@fileName",
    SqlDbType.NVarChar, 256).Value = fileName;
   SqlParameter fileIdParam =
    cmd.Parameters.Add("@fileId", SqlDbType.Int, 4);
   fileIdParam.Direction = ParameterDirection.Output;
   cmd.ExecuteNonQuery();
   // now insert in chunks
   fileId = (int)fileIdParam.Value;
  }
  if (fileId > -1)
  {
   //The size of the "chunks" 
   // 128 bytes, regulate at will
   InsertFileByChunks(fileId, data, 128);
  }
 }

note how we are calling InsertFileByChunks from our insert method above ?

public void InsertFileByChunks(int fileId, Stream data, int bufferLen)
{
   using (SqlConnection myConnection = GetSqlConnection())
   {
      myConnection.Open();      SqlCommand cmd = new SqlCommand(DbOwner +         ".DataFile_InsertChunk", myConnection);      cmd.CommandType = CommandType.StoredProcedure;      cmd.Parameters.Add("@fileId",      SqlDbType.Int, 4).Value = fileId;      SqlParameter paramData = cmd.Parameters.Add("@data",      SqlDbType.VarBinary, 128);      SqlParameter paramOffset = cmd.Parameters.Add("@offset",            SqlDbType.BigInt);      cmd.Parameters.Add("@length",         SqlDbType.Int, 4).Value = bufferLen;      using (BinaryReader br = new BinaryReader(data))    {         byte[] buffer = br.ReadBytes(bufferLen);         int offset = 0;         while (buffer.Length > 0)       {          paramData.Value = buffer;          paramOffset.Value = offset;          cmd.ExecuteNonQuery();          offset += bufferLen;          buffer = br.ReadBytes(bufferLen);       }    }    data.Close();}
}

As you can see the above method just writes chunks of data at a time(the accompanying stored procedure DataFile_InsertChunk uses .Write to update the field with the new chunks as they come in).

And now the accompanying stored procedures DataFile_Insert and DataFile_InsertChunk :

CREATE PROCEDURE [dbo].[DataFile_Insert]
@applicationName nvarchar(256),
@mimeType nvarchar(50), 
@length int, 
@fileName nvarchar(256),
@fileId int output
AS
BEGIN
DECLARE @applicationId UNIQUEIDENTIFIER
SELECT  @ApplicationId = ApplicationId FROM dbo.aspnet_Applications 
WHERE LOWER(@ApplicationName) = LoweredApplicationName

INSERT INTO dataFile (applicationId, data, mimeType, [length],  
[fileName], dateCreated, lastDateModified)
VALUES (@applicationId, 0x0, @mimeType, @length, @fileName,  
GETDATE(), GETDATE())
SET @fileId = SCOPE_IDENTITY()    
END 

Note above how we introduce the value 0x0 (null) as per the article on MSDN into the data field ? "data" is the name of the field that will be holding our data stream and is a varbinary type. The reason we introduce the value 0x0 is because .Write cannot write into a NULL field. This is the workaround i was talking about earlier and it does not effect the appended chunks in anyway.

CREATE PROCEDURE [dbo].[DataFile_InsertChunk]
@data varbinary(MAX), 
@length int, 
@fileId int output,
@offset bigint
AS
BEGIN
UPDATE dataFile SET data.WRITE(@data, @offset, 
@length) WHERE fileId = @fileId    
END

As you can see, it all boils down to this. Quite simple indeed. the .WRITE method takes as argument your chunk, the offset and the length. Not much for me to add here. Oh one thing you may also want to note is that .WRITE is called via the field to which it needs to write to. so the syntax takes the form of -> fieldName.WRITE(...) ; in my case the field name is "data" as you can note from the code in the stored proc above.

We have now successfully stored our file stream in chunks. Next we want to see how to retrieve our filestream in a similar manner, that way we do not hog resources on our webserver when binary content is requested, requiring us to stream it out from the database server to the webserver where our code streams it out again to the client. Firstly, I hope you are already familiar with an HttpHandler, if not you can look it up on google.

An HttpHandler/Module is general knowledge so i'm not going to get into it. I've mapped somefile.ashx to my HttpHandler, that way, every request that comes in will be handled by my custom handler, where i request the file stream from the database and then stream it out again in chunks to the client. My HttpHandler looks like this :

public class BinaryDataHandler : IHttpHandler
{
   public void ProcessRequest(HttpContext context)
   {
      int fileId;      bool success = int.TryParse(    context.Request.QueryString["fileId"],      out fileId);      if (success)    {       IDataReader r = FileManager.GetFileById(fileId);       StreamData(r, context);    }}
   void StreamData(IDataReader r, HttpContext context)
   {
      if (r.Read())    {       DataFileItem dfi = new DataFileItem();         dfi.Length = (r["length"] is DBNull) ?            -1 : (int)r["length"];         dfi.MimeType = (r["mimeType"] is DBNull) ?         string.Empty : (string)r["mimeType"];         if (dfi.MimeType != string.Empty)          context.Response.ContentType = dfi.MimeType;       dfi.FileName = (r["fileName"] is DBNull) ?         string.Empty : (string)r["fileName"];       dfi.Extention = (r["extention"] is DBNull) ?         string.Empty : (string)r["extention"];       context.Response.AddHeader("Content-Disposition",         string.Format("inline;filename={0}{1}",             dfi.FileName, dfi.Extention));       context.Response.AddHeader("Content-Length",         dfi.Length.ToString());         int dataOrdinal = r.GetOrdinal("data");         if (!(r[dataOrdinal] is DBNull))           StreamByteArrayInChunks(r, dataOrdinal, context);    }}
   public void StreamByteArrayInChunks(IDataReader r, int ordinal,
         HttpContext context)   {
      //102400 is 100kb at a time buffer      byte[] buffer = new byte[102400];      int index = 0;      while (true)    {         long count = r.GetBytes(ordinal,       index, buffer, 0, buffer.Length);         if (count == 0)       {            break;       }         else       {          index = index + (int)count;            context.Response.BinaryWrite(buffer);            context.Response.Flush();         }      }      //closes datareader + underlying db connection    r.Close();}
   // Override the IsReusable property.
   public bool IsReusable
   {
      get { return false; }}
}

A few things i will explain quickly from the above code is how we retrieve an IDataReader from our DAL instead of retrieving a stream. The reason is i want to retrieve the filestream in chunks from the DataReader and every chunk i read from the database, i want to write it out to the client, as i receive the chunks without storing them in memory on my webserver where my application resides.

Another thing you may want to notice is the usage of the Http Header Content-Disposition and Content-Length ; basically, it was important for me to flush out the file with the original filename when the user choses to save the file and Content-Disposition helped there. Whereas Content-Length helped ensure the filesize on the receiving end (the client) since without it i was getting errors unzipping a file for example where winzip complained that the file was corrupt :-)

So that's pretty much it. And oh, the method in my DAL that returns the IDataReader follows :

public override IDataReader GetFileById(int fileId)
{
   SqlConnection myConnection = GetSqlConnection();
   myConnection.Open();
   SqlCommand cmd = new SqlCommand(DbOwner +
      ".DataFile_GetFileById", myConnection);   cmd.CommandType = CommandType.StoredProcedure;
   cmd.Parameters.Add("@fileId",
      SqlDbType.Int, 4).Value = fileId;   SqlDataReader r = cmd.ExecuteReader(
      CommandBehavior.CloseConnection);   return r;
}

With that i think we have succeeded in conserving resources on both our database server and our Web server. One last thing, when you got this all working, experiment by changing the buffer size and regulate it to the write speed that is acceptable as per your standards. Basically from my tests on my dev machine, i was getting a download speed of 500KB - 517KB/sec with a buffer size of 100kb (102400 bytes). While setting the same buffer size to 10kb (10240bytes), i was getting a download speed of 50KB - 60KB/sec ;

These tests are ofcourse based on what i see as i request a file handled through my custom httphandler above. These values are more or less the same i reckon when streaming the same data to sql server in chunks or a good approximation, so use that as a starting point to regulate the desired speed/latency required by your app based on how much resources your webserver/database server has. Normally, uploads are usually restricted to a certain amount by most ISP's so it means you can set a much smaller chunk size when streaming from your application to sql server. And increase the chunk size when streaming from your webserver to the client (since your requesting clients download speeds are significantly high). It will also depend on the bandwidth availability of your webserver and other factors ofcourse, but that's off topic.

Update 23 september 2008 :

One last thing i forgot to mention but my friend filip duyck brought up is that now since we are sending the data in chunks to sql server (whilst reusing the same connection), it's still additional hits to our database server. So consider that too while you evaluate how big you want your chunks to be.

Part 2 : Building and binding hierarchical data from the database to the ASP.NET Navigation Controls

2008-03-01T17:14:00.003+01:00

I wrote about how we can make use of some of the databinding capabilities of controls, that can bind to hierarchical data like the TreeView around last week. While I covered pretty much everything, the data i was binding to was not deeply nested. Instead the data we were consuming was just 3 levels deep and that was that.

Today, we will be binding to a hierarchical datasource whose nesting structure is not known and can go as deep as it wants. Here, also SQL servers XML capabilities seem to come short since it does not support recursions. so if our data had this kind of deep nesting, SQL Servers FOR XML queries are not helping out much and we'd need to combine XSLT to our FOR XML Query.

Because of that, and since we end up using XSL for the transformation anyway, i'm going to be using the Dataset/XSLT approach I discussed in my previous post.

First, lets create a "pages" table in Sql server with the following schema as you can see in the screen shot below :

As you can note from above, we have a parentId field which is a self related field, related to the pageId in the same table. I personally prefer to move this field out to a junction table but each approach has it's pro's and con's, and this is simpler and serves our purpose :-)

Now, let's fill it with sample data, as you can note in the screenshot below :

ohh perfect. Now it's time to put together some c# code :

protected void Page_Load(object sender, EventArgs e)
{
if (!IsPostBack)
XmlDataSource1.Data = GetHierarchicalData();
}
string GetHierarchicalData()
{
string queryString =
"SELECT pageId, pageDisplayName, parentId FROM pages;";
DataSet ds = new DataSet("Pages");
string connectionString = ConfigurationManager.
ConnectionStrings["LocalSqlServer"].ConnectionString;
using (SqlConnection connection = new SqlConnection(
connectionString))
{
SqlDataAdapter adapter = new SqlDataAdapter();
adapter.SelectCommand = new SqlCommand(
queryString, connection);
adapter.Fill(ds);

ds.Tables[0].TableName = "PageItem";
// relate our tables
DataRelation dr = new DataRelation("FK_pageId_parentId", 
ds.Tables["PageItem"].Columns["pageId"],
ds.Tables["PageItem"].Columns["parentId"]);
// we'd like the page items nested within 
// each node for every child page.
dr.Nested = true;
ds.Relations.Add(dr);
}
return ds.GetXml();
}

The xml returned by our dataset looks like this : Dataset generated XML

Notice how every pageId that had a corresponding parentId was nested within it's parent, forming a hiearchical set of data. This is just perfect, all thanks to the dataset's DataRelation capabilities and our setting Nested=true on the DataRelation. This kind of recusive nesting didn't seem supported by SQL Servers FOR XML queries, and if it was, then it's probably trival. I did find a few implicit hints in the documentation that recursive nesting was not supported on SQL Server FOR XML Queries, however i could be wrong (so please do your homework).

Now our XSL file that does the recursion, but it's easier to make the transformation now, because the data is already structured out nicely with the proper hierarchical structure. Only thing missing and why we need to perform transformation is as i explained in the previous post, we need the fields as attributes and not as xml elements. So here is our recursive xslt that does just that :

<?xml version="1.0" encoding="utf-8"?>

<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output method="xml"/>
<xsl:template name="Menu" match="/">
<xsl:element name="Pages">
<xsl:for-each select="Pages/PageItem">
<xsl:variable name="parentId" select="parentId/text()"/>

<xsl:element name="PageItem">
<xsl:attribute name="pageId">
<xsl:value-of select="pageId/text()" />
</xsl:attribute>
<xsl:attribute name="pageDisplayName">
<xsl:value-of select="pageDisplayName/text()" />
</xsl:attribute>

<xsl:call-template name="processChildren" />

</xsl:element>
</xsl:for-each>
</xsl:element>
</xsl:template>
<!-- recursive template -->
<xsl:template name="processChildren">
<xsl:for-each select="PageItem">
<xsl:element name="PageItem">
<xsl:attribute name="pageId">
<xsl:value-of select="pageId/text()" />
</xsl:attribute>
<xsl:attribute name="pageDisplayName">
<xsl:value-of select="pageDisplayName/text()" />
</xsl:attribute>
<xsl:call-template name="processChildren" />
</xsl:element>
</xsl:for-each>
</xsl:template>
</xsl:stylesheet>

And here is the output of this miraculous transformation : XSL Transformed XML

Ohhh what beauty :-) and to complete, here is the declarative code to bind our asp.net menu to the XmlDataSource control that consumes this data :

<form id="form1" runat="server">
<div>
<asp:Menu ID="Menu1" MaximumDynamicDisplayLevels="1000" 
Orientation="Horizontal"
DataSourceID="XmlDataSource1" runat="server">
<DataBindings>
<asp:MenuItemBinding DataMember="PageItem" 
TextField="pageDisplayName" ValueField="pageId" />
</DataBindings>
</asp:Menu>
<asp:XmlDataSource ID="XmlDataSource1" XPath="Pages/PageItem"
TransformFile="~/MenuTransform.xsl" runat="server"></asp:XmlDataSource>
</div>
</form>

One gotcha you want to watch out for is the root node showing in the menu. Since we do not want to show the starting node, we explain this to the XmlDataSource nicely by setting an XPath expression : XPath="Pages/PageItem".

And below is our menu, when previewed in the browser. Time to congratulate ourselves on a job well done :-)

Update 21 May 2008

A note i forgot to mention is that the XmlDataSource control has caching turned on by default. So in case you made a change in your xslt file and didn't see the change occuring, then you know it's using a cached copy. So make sure you disable caching during development.

Building and binding hierarchical data from the database to the ASP.NET Navigation Controls

2008-02-20T22:30:00.003+01:00

If we need to bind our navigations controls to hierarchical data we define manually ourselves in an xml file, this is easy as pie. However, things can get rather complicated or not so obvious when we need to generate this data from a database. First off, what can we use that is already provided to us for binding hierarchical data to our navigation controls in ASP.NET ?

The already out of the box approach and ideal solution is to use the XmlDataSource control. This is quite a flexible datasource control since it not only enables us to define the path to our xml file containing the structure we need but also it allows us to define xml data to it via it's "Data" property. As you may have already guessed, because our data is going to be retrieved from our database, this is the property we shall be using :-)

But first let's look at a sample data structure we may have in our database. I'm using the classic Northwind database. Let's imagine we want to display products grouped by category. So in short, for every category node, we want to show products under it. Following is a screenshot of the categories and products table and how they relate :

The most common thing i see done is to manually loop through the records returned, create TreeNodes again manually and keep adding till you've build the TreeView or Menu, etc. Nothing wrong with this approach, since it works, however it is quite lengthy in code and time consuming too.

But that's not the main reason why I'm writing this article. The main reason is that all these navigation controls in ASP.NET know how to consume hierarchical data. Once they have this, they know how to render themselves without you needing to do anything special. This is indeed some powerful databinding support that we miss out on when we go the manual approach. Here i am going to list two different approaches :

1) DataSet and XSL Transformations, which while being clean and gives a more declarative model to work with (XSLT) versus the manual c# code approach.

2)The second approach uses SqlServer's XML generating capabilities which allows us to skip XSLT and the dataset all together.

DataSet and XSL Transformation approach:

Note below how our select statements retrieves all categories, while the second statement retrieves all products. We then relate both these tables using a key field they have in common "CategoryID". We also use a dataset since it's providing us a lot of functionality like relating the tables after data retrieval and representing the data in xml.

string GetHierarchicalData()
{
string queryString =
"SELECT CategoryID, CategoryName, Description FROM Categories AS Category;";
queryString +=
"SELECT ProductID, CategoryID, ProductName FROM Products AS Product";
DataSet ds = new DataSet("TreeView");
string connectionString = ConfigurationManager
.ConnectionStrings["LocalSqlServer"].ConnectionString;
using (SqlConnection connection = new SqlConnection(
connectionString))
{
SqlDataAdapter adapter = new SqlDataAdapter();
adapter.SelectCommand = new SqlCommand(
queryString, connection);
adapter.Fill(ds);

ds.Tables[0].TableName = "Category";
ds.Tables[1].TableName = "Product";
// relate our tables
DataRelation dr = new DataRelation("FK_Products_Categories",
ds.Tables["Category"].Columns["categoryId"],
ds.Tables["Product"].Columns["categoryId"]);
// we'd like the products nested within 
// each Category Node. Thank you :-)
dr.Nested = true;
ds.Relations.Add(dr);
}
return ds.GetXml();
}

A small sample output of the generated xml we get by calling dataset's GetXml() method is here -> DataSet Generated XML

As you can see, we have our rootnode "TreeView", then a childNode "Category", which in turn will contain every product node within it that belongs to this category. This nesting was established when we created a relationship btw the Categories table and the Products table using a DataRelation, where we set Nested = true; on it. Enabling the Nested property did just what the name says. It nested all our products within it's specific Category node.

While this is great, it does not help much with the TreeView control. Notice how every field our select statement returned is now an xml node and the data for the field is contained as inner text in our node. The TreeNodeBinding instead expects the fields to be contained as attributes, and the data as attribute values. Following screenshot is what we get when we run our TreeView bound to XmlDatasource

Definately, not what we are after. This is because the datasets GetXml method returned :

<Category>
<CategoryID>1</CategoryID>
<CategoryName>Beverages</CategoryName>
<Description>Soft drinks, coffees, teas, beers, and ales</Description>

while, what we need instead for the TreeNodeBinding to work is :

<Category CategoryID="1" CategoryName="Beverages"

     Description="Soft drinks, coffees, teas, beers, and ales">

Had we the above xml structure with the fields defined as attributes we could easily create a TreeNodeBinding like this :

<asp:TreeNodeBinding Depth="2" DataMember="Category"

  TextField="CategoryName" ValueField="CategoryID" ToolTipField="Description" />

So, our next task is to transform our xml to represent fields as attributes and their data as attribute values. We can accomplish this easily using XSL Transformations. By defining some instructions in our XSL file, we can read our XML(what our dataset GetXml method output) and transform it into what the Navigation Controls expect, outputting a totally new XML document.

<?xml version="1.0" encoding="utf-8"?>
<xsl:transform version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output method="xml"/>
<xsl:template match="/">
<xsl:element name="TreeView">
<xsl:for-each select="TreeView/Category">
<xsl:element name="Category">
<xsl:attribute name="id">
<xsl:value-of select="CategoryID/text()" />
</xsl:attribute>
<xsl:attribute name="name">
<xsl:value-of select="CategoryName/text()" />
</xsl:attribute>
<xsl:attribute name="description">
<xsl:value-of select="Description/text()" />
</xsl:attribute>
<xsl:for-each select="Product">
<xsl:element name="Product">
<xsl:attribute name="id">
<xsl:value-of select="ProductID/text()" />
</xsl:attribute>
<xsl:attribute name="name">
<xsl:value-of select="ProductName/text()" />
</xsl:attribute>
</xsl:element>
</xsl:for-each>
</xsl:element>
</xsl:for-each>
</xsl:element>
</xsl:template>
</xsl:transform>

As you can see from the above XSL, we have defined two for-each loops, one that loops through category nodes and the other that loops through product nodes. Very simple but powerful stuff indeed.
The output xml after this transformation is XSL Transformed Xml output

<TreeView>
<Category>
<CategoryName name="" id="" description="" />
<Product name="" id="" />
...
</Category>
...
</TreeView>

ohh this is perfect. It was fun using XSL for the transmformation. Now, now, while it was fun, it can be a big pain in the behind if I'd have to do this all over again and again (Fortunately, i don't. Atleast now right now) :P

So, can we have made this job easier ? Surely. SQL Server and FOR XML Queries to the rescue

SQL Server and FOR XML Queries approach :

Now, what if, instead of having to do all this manual labor, we could get SQL Server to do all the xml generation for us, the way we wanted it ? Very much possible indeed. In effect this does not even need any explainations. Code speaks a thousand words, so here it is, the same xml output but this time we didn't use XSLT, nor did we use a dataset and the code is even more minimized.

string GetHierarchicalDataFromSqlServer()
{
string xml = string.Empty;
string queryString = @"
SELECT Category.categoryName as [name], Category.categoryId as id, 
Category.description as description, 
Product.productName as name, Product.productId as id
FROM categories AS Category 
INNER JOIN products AS Product
ON Category.categoryId = Product.categoryId
ORDER BY Category.categoryId                    
FOR XML Auto, ROOT('TreeView')";

string connectionString = ConfigurationManager.
ConnectionStrings["LocalSqlServer"].ConnectionString;

using (SqlConnection connection = new SqlConnection(
connectionString))
{
SqlCommand SelectCommand = new SqlCommand(
queryString, connection);
connection.Open();
XmlReader xr = SelectCommand.ExecuteXmlReader();
xr.MoveToContent();// move to the root node
xml = xr.ReadOuterXml();
}
return xml;
}

The c# code to pass the XML data to our XmlDataSource bound to a treeView :

protected void Page_Load(object sender, EventArgs e)
{
if (!IsPostBack)
XmlDataSource1.Data = GetHierarchicalDataFromSqlServer();
}

That's it. No fuss, SQL Server's xml generation capabilities are just outstanding. And here is the declarative code i used to bind this hiearchical data to a treeview :

<form id="form1" runat="server">
<div>
<asp:TreeView ID="TreeView1" DataSourceID="XmlDataSource1"                  runat="server">
<DataBindings>
<asp:TreeNodeBinding Depth="1" DataMember="Category" 
TextField="name" ValueField="id"                                   ToolTipField="Description" />
<asp:TreeNodeBinding Depth="2" DataMember="Product" 
TextField="name" ValueField="id" />
</DataBindings>
</asp:TreeView>
</div>
<asp:XmlDataSource ID="XmlDataSource1"                   runat="server"></asp:XmlDataSource>
</form>

And here below is a screenshot of the treeview rendering itself. Fantastic!

Update 21 May 2008

Customizing the ChangePassword control and removing the required CurrentPassword field

2008-02-15T16:47:00.002+01:00

It's very rare that what is already provided in asp.net under the Login controls fits my requirements out of the box without some tweaking. Not that any of these controls offer anything specialized, but certainly they are a big time saver if we can re-utilize their functionality.

First some background as to why i personally want to customize the ChangePassword control to suit my needs :

Password recovery is what i was after today, however i have hashed passwords, and recovery is impossible. If the user lost their password, then there is no way for me to know what their password is and send it back in clear text.

The ideal solution is to reset the password, however the autogenerated password is quite ugly and quite hard to remember. What I've decided to do is send the email during password recovery, but as part of the email, instead of telling the user their old password(which i can't).

I'm instead going to ask them to click on a tokenized link that will guarantee to me that they are indeed the ones that requested the password, send them to the page where they can provide a new password, in the background i'd be autogenerating a password first ofcourse, then updating the password with their new password because the MembershipUser.ChangePassword(oldPassword, newPassword) method requires Old password as one of it's two parameters.

This password change step, i'd like to be done using the ChangePassword control, however to my big surprise CurrentPassword Field is a required field that i cannot remove. This is also a field that I do not want asked for during the password change request(since my user has forgotten their password and are now going to provide their new pasword).

There is ofcourse no property or method in this control that removes the CurrentPassword field requirement, below is a screenshot of the ChangePassword control in designview, as you can note, the highlighted field is the CurrentPassword field i do not want.

I've done a quick look on google and in the asp.net/forums and didn't find anybody providing any proper solutions either, mostly vague replies : http://forums.asp.net/p/1189347/2038354.aspx

As you can read from the posts there, the issue seems to be two things which were also my same issues :
1) Remove the current password label/TextBox
2) Pass the new resetpassword to CurrentPassword Property which by the way is a getter only and not settable (SAD SAD)

Both of these things are not supported in this control. So let's quickly fix requirement 1 and there are a couple of ways to fix this :
a) You have to define a custom <ChangePasswordTemplate>. This can be easily done by taking your ChangePassword control into DesignView in Visual studio, right click on the control and select "Convert to template". You can then switch to HtmlView and set the visibility of CurrentPasswordLabel, CurrentPassword and CurrentPasswordRequired controls.

b) If you prefer to do this in code, then you can find the Label and TextBox for CurrentPassword and set its visiblity to false. Since a is a nobrainer, i'm including a sample code of method (b) :

Label l = (Label)changePassword1.ChangePasswordTemplateContainer.

         FindControl("CurrentPasswordLabel");

if (l != null)

{
    l.Visible = false;
}
TextBox tb = (TextBox)changePassword1.ChangePasswordTemplateContainer.
FindControl("CurrentPassword");

if (tb != null)

{
    tb.Visible = false;
}
RequiredFieldValidator rfv =

        (RequiredFieldValidator)changePassword1.

ChangePasswordTemplateContainer.FindControl("CurrentPasswordRequired");

if (rfv != null)
{
    rfv.Visible = false;

}

Now that we have the fields we want disabled, let's head onto fix issue 2 :
We can't pass the Autogenerated password to the CurrentPassword Property because its a getter only, however this getter returns the value from our CurrentPassword TextBox, and this job is done immidiately after ChangingPassword event fires. This is good news for us, so we can resolve issue 2 like this :

void changePassword1_ChangingPassword(object sender, 
LoginCancelEventArgs e)
{
    changePassword1.UserName = user.UserName;
    TextBox currentPassword = (TextBox)changePassword1.
    ChangePasswordTemplateContainer.FindControl("CurrentPassword");

    if (currentPassword != null)

    {
        currentPassword.Text = user.ResetPassword();

Note that in the above code, user is a reference to a field of type MembershipUser. Ok, that's it. Now we have what were after, look at the screenshot below :

Reducing UpdatePanel bloat by utilizing UpdateMode="Conditional" and ChildrenAsTriggers="false"

2008-01-30T12:41:00.001+01:00

Just the other day, i was playing around with my DataControls nested inside an updatepanel. While this was working well, since everypostback was being done via an ajax callback, the amount of traffic going back and forth was simply way too bloated. It's easy not to notice at first, because everything is working as expected. however imagine a simple situation as the following pseudo code below. Things could be very complex, depending on how many datacontrols you have and the level of nesting.

<asp:updatepanel id="UpdatePanel1" runat="server">
<ContentTemplate>
    <asp:GridView ID="GridView1" AutoGenerateSelectButton="true" 
runat="server" 
OnSelectedIndexChanged="GridView1_SelectedIndexChanged">
</asp:GridView>


<asp:DetailsView ID="DetailsView1" AutoGenerateEditButton="true"
runat="server" OnModeChanging="DetailsView1_ModeChanging">
</asp:DetailsView>
</ContentTemplate>
</asp:updatepanel>

As you can note from the code, this is a simple GridView, which enables a DetailsView when a row in the GridView is selected. We then have an Edit button on the DetailsView that should send the DetailsView in edit mode when clicked. All nice so far. Now, this is going to work as advertised ofcourse, all postback is done silently in the background.

But if you look closely enough, both the gridview and the DetailsView are contained within a single UpdatePanel, so obviously the postback caused from any child control nested in the updatepanel will cause the entire contents of the updatepanel to refresh and send back the collective rendered content to the client.

Below screenshots is the traffic analysed through firebug (a firefox extention). Hilighted data denotes the extra data we do not need rendered to the client.

As you can note from the screenshots above, my clicking the select button in the gridview, which should be launching the DetailsView in turn, while i'd only need the rendering of the DetailsView send back to me (since the gridview shouldn't need to change), i actually end up with both the rendering of the GridView and the DetailsView. Indeed, there is extra data(the GridView) being rendered which we do not need.

Ok, this is indeed a problem. Were doing things wrongly. So, how do we cause only the DetailsView to render back instead ? One might quickly think, let's put each into their own individual UpdatePanels ? :-)

So, let's try that. Nothing to be ashamed of. It was the first solution that came to my mind too :P

<asp:UpdatePanel ID="UpdatePanel1" runat="server">
<ContentTemplate>
     <asp:GridView ID="GridView1" AutoGenerateSelectButton="true" runat="server" 
OnSelectedIndexChanged="GridView1_SelectedIndexChanged">
     </asp:GridView>
</ContentTemplate>
</asp:UpdatePanel>

<asp:UpdatePanel ID="UpdatePanel2" UpdateMode="conditional" runat="server">
  <Triggers>
    <asp:AsyncPostBackTrigger ControlID="GridView1" EventName="RowCommand" />
  </Triggers>
<ContentTemplate>

<asp:DetailsView ID="DetailsView1" AutoGenerateEditButton="true" runat="server" 
OnModeChanging="DetailsView1_ModeChanging">
</asp:DetailsView>
</ContentTemplate>
</asp:UpdatePanel>

And here below is the screnshot of the traffic as seen through firebug. Hilighted data denotes the extra data we do not need rendered to the client.

As you can see, we ended up with the same data as before. Nothing has changed, even though we included them in two separate UpdatePanels. Strange ? Not really. If you think about it, both panels are included in the page, and by default, both panels have UpdateMode="Always" set on them, which causes both to refresh upon an async callback.

azzzz we have a problem indeed. Time to read the documentation :P

The first thing the docs hint about are two things : UpdateMode="Conditional" versus the Default which is "Always" and the second thing is ChildrenAsTriggers="false" ; both of which are handy.

If my postback was being caused only by children in UpdatePanel2, i couldof just set UpdateMode="Conditional" on UpdatePanel1 and i'd actually achieve what i was after. Only UpdatePanel2's content will be send back to the client. However if you will note in my example above, a control in UpdatePanel1 is the one who is triggering the postback. This satisfies the "Conditional" bit and UpdatePanel1 also renders its contents. Again not what i'm after.

In effect, i've had to set both UpdateMode="Conditional" and also set ChildrenAsTriggers="false" on UpdatePanel1. This stopped the unwanted behaviour. ChildrenAsTriggers property has a proper explaination in the documentation, you can look it up. In short, it simply stops any direct children from making it refresh. This is good for us and what we are after.

That's just perfect. Using this combo, i can keep the panel i do not want updated, while letting the panel with the update trigger refresh at will. This also allows me to control who gets updated by calling the update method manually on the panel that interests me. For example if i edit a record in the detailsview and want to show the change in the gridview, i'd run the update operation and then right after that, call update on the panel that contains my gridview manually.

<asp:UpdatePanel ID="UpdatePanel1" UpdateMode="conditional" 
ChildrenAsTriggers="false" runat="server">
<ContentTemplate>
   <asp:GridView ID="GridView1" AutoGenerateSelectButton="true" runat="server" 
OnSelectedIndexChanged="GridView1_SelectedIndexChanged">
   </asp:GridView>
</ContentTemplate>

</asp:UpdatePanel>
<asp:UpdatePanel ID="UpdatePanel2" runat="server">
   <Triggers>
      <asp:AsyncPostBackTrigger ControlID="GridView1" EventName="RowCommand" />
   </Triggers>
<ContentTemplate>


<asp:DetailsView ID="DetailsView1" AutoGenerateEditButton="true" runat="server" 
OnModeChanging="DetailsView1_ModeChanging">
</asp:DetailsView>
</ContentTemplate>
</asp:UpdatePanel>

here are the screenies, you can see, only the detailsview is now present in our callback. Just perfect.

While this is a simplistic example, had you many deeply nested updatepanels you can easily workout who gets updated and whose data gets rendered reducing bloat, using the same method i've mentioned above. Don't simply include EVERYTHING in one updatepanel or multiple and depend on the default, posting back un-necessary bloat on each callback. Firebug for Firefox and Fiddler for IE are both great tools for inspecting and analysing your callback traffic. Use either. I prefer firebug :p

Ok, so that was easy(just set UpdateMode="conditional" ChildrenAsTriggers="false"), nonetheless i ended up with quite a lengthy post :x

Failed to load viewstate ? Typical problem, with an obvious solution.

2008-01-04T15:51:00.000+01:00

Understanding viewstate is fundamental in asp.net, especially if you had run into :

Failed to load viewstate. The control tree into which viewstate is being loaded must match the control tree that was used to save viewstate during the previous request. For example, when adding controls dynamically, the controls added during a post-back must match the type and position of the controls added during the initial request.

The only way to resolve is a proper understanding of viewstate.

http://geekswithblogs.net/FrostRed/archive/2007/02/17/106547.aspx is a interesting post on viewstate that i happen to read today, pointed out to me by someone who ran into a viewstate problem about the control tree not matching and was clearly afraid of adding controls dynamically after reading some facts presented in that article. Who wouldn't ?

While the post gives us a very good understanding of viewstate and how it can fail, so i encourage you to read it first, might seem lengthy but I assure you, it's quite interesting. However, when you're done, follow my rant here, since I feel it's important to know, that, the failure can only happen when either done deliberately as per the sample code in the post i linked to above or to *not* understanding viewstate and how it works.

So how can we easily avoid these failures ? Let's look at his first code example, and build onto that :

protected void Page_Init(object sender, EventArgs e)
{
    if (!IsPostBack)
    {
       Button btnClickMe = new Button();
       form1.Controls.Add(btnClickMe);
       btnClickMe.Text = "Click me";
    }
    else
    {
      Label label = new Label();
      form1.Controls.Add(label);
    }
}

As you can note above, this is problematic, since the control into which viewstate is restored is matched by control index, so when the index changes, as is clear in the above code, because if btnClickMe was loaded in for example index [0], now upon postback, after the page has been recreated and rebuilt, the Label "label" is loaded in index [0] instead and takes the place of the button. So this means viewstate that was meant for the button is loaded into the label instead, and the output in the screen after clicking the button is "click me" which was clearly not provided to the label's text property.

Now that we understand the problem, how can this sample apply in real world or why would anybody want to do something like this ? Basically in short, why is viewstate being utilized, if it's not needed after postback ? Button btnClickMe is not reloaded after postback, so it's safe to turn off viewstate on this control, and problem is solved.

This is a typical situation where you deliberately want viewstate to fail, apart from that i see no real use to want to maintain viewstate, which is also bloat on a control that clearly is not utilizing it.

so a rewrite ? here :

protected void Page_Init(object sender, EventArgs e)
{
    if (!IsPostBack)
    {
        Button btnClickMe = new Button();
        // note the addition of the following line
        btnClickMe.EnableViewState = false; 
        form1.Controls.Add(btnClickMe);
        btnClickMe.Text = "Click me";
    }
    else
    {
      Label label = new Label();
      form1.Controls.Add(label);
    }
}

Otherwise, again as per the sample code above, had we been using viewstate, then the problem would resolve itself, if we recreated the control also after postback, which is one of the basic rules of dynamic controls creation. I say rules but really it's the logical thing to do since the page is destroyed after postback and asp.net will have no recollection of controls you added dynamically since memory is cleared, so it's upto you to build it up again manually.

protected void Page_Init(object sender, EventArgs e)
{
       // button will be created even after postback
       Button btnClickMe = new Button();
       btnClickMe.EnableViewState = false;
       form1.Controls.Add(btnClickMe);
       btnClickMe.Text = "Click me";
       if (IsPostBack)
       {
         Label label = new Label();
         form1.Controls.Add(label);
       }
}

So, bottom line, a proper understanding of viewstate, knowledge of the page life cycle, so you know in what phase it's safe to build your control, which will guarantee that viewstate is reloaded into the control(so you load it prior to page_load), and you got it right. For a proper understanding of the page life cycle, you can read the following document on msdn : http://msdn2.microsoft.com/en-us/library/ms178472.aspx?wt.slv=ColumnA

Update Jan/04/2008: I forgot to mention a gotcha, so here it is :

Another gotcha you want to avoid is also the order of controls, that is, when you're loading a dynamic control, make sure the order in which you create it, has the same order when you recreate it. Confused, here let me explain better :

protected void Page_Init(object sender, EventArgs e)
{
   if (IsPostBack)
   {
      Label label = new Label();
      label.ID = "label1";
      form1.Controls.Add(label);
      label.Text = "label";

      Button btnClickMe = new Button();
      btnClickMe.ID = "button1";
      form1.Controls.Add(btnClickMe);
      btnClickMe.Text = "Click me";
   }
   else if (!IsPostBack)
   {
      //Now lets change the order 
      //during postback and we are
      //recreating the controls
      Button btnClickMe = new Button();
      btnClickMe.ID = "button1";
      form1.Controls.Add(btnClickMe);
      btnClickMe.Text = "Click me";

      Label label = new Label();
      label.ID = "label1";
      form1.Controls.Add(label);
      label.Text = "label";
   }
}

As you can note above, the order in which controls are added changes after postback. In this scenario what really happens ? The viewstate meant for the button is loaded into the label and the viewstate meant for the label is loaded into the button. So, you really want to be careful with the order in which you recreate your controls.

UpdatePanel Css StyleSheet upon partial-refresh bug in IE

2008-01-01T03:50:00.001+01:00

The update panel seems to have a bug when registering an external stylesheet or including css styles from within the contents that will be getting partially rendered. The bug only seems to occur in IE, works nicely in firefox. Impressive indeed. My problems started when i had a control that needed to render a link to an external stylesheet, which was quite mm easy and normal.

I mean i've been there and done that plenty of times, however this time there were situations in which the stylesheet needed to be registered if my control was included in an updatepanel and kept invisible during inital load, while enabling it only upon a partial postback. TRICKY TRICKY TRICKY!

More over, there is an old bug opened and closed with a reason "this is by design". Seems awkward to me that this is by design and only effects IE :-(
The url to the bug report is here :

https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=103134

I resolved by registering the css in the OnInit phase of my custom control. Since this would run and register the css even if the control was disabled or invisible, which is what i was after, since it registered the control with the page on first load instead of trying to rendering the style link as part of my rendering for the control(which obviously didn't work in IE). A simplied piece of my code of how i have worked around this problem is as follows :

protected override void OnInit(EventArgs e)
{
    base.OnInit(e);
ScriptManager sm = ScriptManager.GetCurrent(Page);
    if (!sm.IsInAsyncPostBack)
{
       string css = string.Format("<link rel=\"stylesheet\" 
        href=\"{0}\" type=\"text/css\" />", 
ResolveUrl(CssClassFile));

ScriptManager.RegisterClientScriptBlock(this, 
      typeof(MyBlahControl), "MyBlahId", css, false);
}
}

Update 01/01/2008 : Please read the first two comments below. CSS contianment from within the <body element violates xhtml specs and as such here is an update that includes the css in the <head section. Thanks to Ram Krisna for pointing out/commenting this.

protected override void OnInit(EventArgs e)
{
  base.OnInit(e);
ScriptManager sm = ScriptManager.GetCurrent(Page);
  if (!sm.IsInAsyncPostBack)
{
HtmlLink l = new HtmlLink();
l.Href = ResolveUrl(CssClassFile);
l.Attributes.Add("rel", "stylesheet");
l.Attributes.Add("type", "text/css");
Page.Header.Controls.Add(l);
}
}

A simplified test of what I feel is an open bug and should be fixed can be seen below. After clicking the button, the style applied to the label is lost and happens only in IE7, donno about previous versions since i have not tested :

<%@ Page Language="C#" %>

<script runat="server">

protected void Button1_Click(object sender, EventArgs e)
{
// do something
}

</script>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 
Transitional//EN" 
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
<title>Untitled Page</title>
</head>
<body>
<form id="form1" runat="server">
<div>
<asp:ScriptManager ID="ScriptManager1" runat="server">
</asp:ScriptManager>
<asp:UpdatePanel ID="UpdatePanel1" runat="server">
<ContentTemplate>
<!-- 
Note below that for simplicity i am not
using an external stylesheet. Anyway, even with an external style
sheet the result is the same. The style is 
not applied after partial postback 
-->
<style type="text/css">
.MakeGreen{background-color:green;}
</style>
<asp:Label ID="Label1" CssClass="MakeGreen" 
runat="server" Text="Label"></asp:Label>

<asp:Button ID="Button1" runat="server" Text="Partial refresh"
OnClick="Button1_Click" />

</ContentTemplate>
</asp:UpdatePanel>
</div>
</form>
</body>
</html>

Custom Serverside paging in GridView Vs DataGrid

2007-10-09T17:29:00.000+02:00

When doing serverside paging(that is paging at the database layer by returning only the paged result), one of the things I miss in the GridView control is the VirtualItemCount, which is supposedly only supported in the older control's like the DataGrid.

This property was quite useful because while being able to supply to the DataGrid a variable number of paged result sets, i was also able to tell the DataGrid, the total number of records, that way it knew how many pager buttons to display.

Eg. If we had, say a total of a 100 records and had the pageSize set to 7, so only 7 records are shown at a time, then how does the grid know how many numbered pager buttons to display allowing us to navigate from one page to another ? That's where the VirtualItemCount came into play and saved the day. To this property we'd pass a total records count and that was it. In the GridView today ? There is no VirtualItemCount present. The way it were planned it seems is to use the ObjectDataSource, which in my honest opinion is simply extra work, however it does abstract much of this code nicely and put it where it should be, in the data tier.

In all the example code in this post, I shall be using the MemberShip.GetAllUsers method. This method is overloaded and can retrieve a paged result of users Versus returning all the user's in the database, which is a quite handy overload and works out nicely for the code i want to use in this post.

Let's look at a simple example of how we couldof performed custom paging on the DataGrid control back in the old days :

int virtualItemCount = 0;
protected void Page_Load(object sender, EventArgs e)
{
if (!IsPostBack)
{
DataGridMembers.DataSource = Membership.GetAllUsers(0, 
DataGridMembers.PageSize, out virtualItemCount);
DataGridMembers.VirtualItemCount = virtualItemCount;
DataGridMembers.DataBind();
}
}

Note the VirtualItemCount ? Then on the PageIndexChanged event of the DataGrid we did :

protected void DataGridMembers_PageIndexChanged(object source, 
DataGridPageChangedEventArgs e)
{
DataGridMembers.CurrentPageIndex = e.NewPageIndex;
DataGridMembers.DataSource = Membership.GetAllUsers(e.NewPageIndex, 
DataGridMembers.PageSize, out virtualItemCount);
DataGridMembers.DataBind();
}

And that was it, it was as simple as that.

Now try to do that on the GridView ? Can't be done and this is a control that is replacing the old DataGrid control. To make things worse, the DataGrid is not a supported control anymore in 2.0 ; It's been obsoleted and by default you wont even find this control in your toolbox. You can still use it however by manually adding it to your toolbox. Unfortunate, because there are moments like this custom paging situation and i'm getting nostalgic already.

So, how to achieve the same thing in the GridView control which happens to replace the DataGrid ? Well, it's a long shot. Since we cannot achive this directly on the GridView, we are going to have to do it via the DataSource control, which is actually the control that is populating the data for the gridview and also the control that handles paging and sorting amoung other things. While i like this kind of data abstraction, i'm actually doing more work and making the extra effort,but this is how you would implement custom paging on your GridView control.
The GridView alone is lacking a VirtualItemCount property, which i believe shouldn't have been so hard to implement. To compensate for this lacking, you perform custom serverside paging by using an ObjectDataSource control, defining a SelectMethod and a SelectCountMethod method. The SelectCountMethod is your custom method that returns the Total records count.

So let's look at some code, and there are few gotcha's that weren't exactly obvious to me in the begining :
First our custom SelectMethod :

public MembershipUserCollection GetAllUsers(int startRowIndex, 
int maximumRows)
{
if (startRowIndex > 0)
startRowIndex = startRowIndex / maximumRows;
return Membership.GetAllUsers(startRowIndex, 
maximumRows, out selectCountValue);
}

One gotcha you want to make note of is how i have some extra code to divide startRowIndex by maximumRows ; This is because startRowIndex is actually the first row in the resultset as the variable name indicates, however what i really need is the current page index, because that is what our stored procedure is expecting, in this case that is what the internal MemberShip.GetAllUsers method is expecting.

Next we need to add a SelectCountMethod :

int selectCountValue = 0;
public int SelectVirtualCount()
{
return selectCountValue;
}

The code is minimum as you can note, but ofcourse, there is some extra effort to making the abstraction. The code above goes into the data layer.

And lastly, we need to subscribe to PageIndexChanging event of our GridView and pass the selected page index :

protected void GridViewMembers_PageIndexChanging(object sender, 
GridViewPageEventArgs e)
{
GridViewMembers.PageIndex = e.NewPageIndex;
}

A peculiar behaviour you will notice is that the SelectCountMethod and the SelectMethod both share the same SelectParameters if SelectParameters are defined. Peculiar because i was not really expecting it, however I have no issues with it, For example if we had to rewrite our previous example to include also a search by userName, then our ObjectDataSource would be expecting some SelectParameters like this :

<asp:ObjectDataSource ID="ObjectDataSourceMembers"
EnablePaging="True"
SelectCountMethod="SelectVirtualCount"
SelectMethod="GetAllUsers"
TypeName="MembersData" 
runat="server">
<SelectParameters>
<asp:ControlParameter ControlID="TextBoxUserName" Name="userName" 
PropertyName="Text" DefaultValue="All" />
</SelectParameters>
</asp:ObjectDataSource>

And then modified our SelectMethod as such :

public MembershipUserCollection GetAllUsers(int startRowIndex, 
int maximumRows, string userName)
{
if (startRowIndex > 0)
startRowIndex = startRowIndex / maximumRows;
if (userName == "all")
{
return Membership.GetAllUsers(startRowIndex,
maximumRows, out selectCountValue);
}
else
{
return (MembershipUserCollection)
Membership.FindUsersByName(userName + "%", 
startRowIndex, maximumRows, out selectCountValue);
}
}

As you can see while our GetAllUsers(SelectMethod) has the needed userName parameter, our SelectVirtualCount method defined above does not have any parameters defined on it, since we don't need to pass it anything. However, the ObjectDataSource is going to complain with :

ObjectDataSource 'ObjectDataSourceMembers' could not find a non-generic method 'SelectVirtualCount' that has parameters: userName

So it means both the SelectMethod and the SelectCountMethod share the same Select parameters. I resolved by adding the extra userName parameter in the SelectCountMethod as well, while i did not clearly need it, but no big deal.
Here is what the modified SelectCountMethod wouldof looked like :

int selectCountValue = 0;
public int SelectVirtualCount(string userName)
{
return selectCountValue;
}

The SelectCountMethod is treated exactly in the same way the SelectMethod is treated, so the ObjectDataSource's Selected Event is going to fire twice for example, once when the SelectMethod is called and once when the SelectCountMethod is called. These are all gotchas i was not really prepared for.

Full code for custom serverside paging in DataGrid :

<%@ Page Language="C#" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<script runat="server">

int virtualItemCount = 0;
protected void Page_Load(object sender, EventArgs e)
{
if (!IsPostBack)
{
DataGridMembers.DataSource = Membership.GetAllUsers(0, 
DataGridMembers.PageSize, out virtualItemCount);
DataGridMembers.VirtualItemCount = virtualItemCount;
DataGridMembers.DataBind();
}
}

protected void DataGridMembers_PageIndexChanged(object source, 
DataGridPageChangedEventArgs e)
{
DataGridMembers.CurrentPageIndex = e.NewPageIndex;
DataGridMembers.DataSource = Membership.GetAllUsers(e.NewPageIndex, 
DataGridMembers.PageSize, out virtualItemCount);
DataGridMembers.DataBind();
}

</script>

<html xmlns="http://www.w3.org/1999/xhtml" >
<head runat="server">
<title>Untitled Page</title>
</head>
<body>
<form id="form1" runat="server">
<div>
<asp:DataGrid ID="DataGridMembers" AllowPaging="True" 
AllowCustomPaging="true" PageSize="2" runat="server" 
OnPageIndexChanged="DataGridMembers_PageIndexChanged">
<PagerStyle Mode="NumericPages" 
HorizontalAlign="Right" />
</asp:DataGrid>
</div>
</form>
</body>
</html>

And the full code for custom paging in GridView :

<%@ Page Language="C#" %>
<%@ Import Namespace="System.Data" %>
<%@ Import Namespace="System.Data.SqlClient" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<script runat="server">

protected void GridViewMembers_PageIndexChanging(object sender, 
GridViewPageEventArgs e)
{
GridViewMembers.PageIndex = e.NewPageIndex;
}

</script>

<html xmlns="http://www.w3.org/1999/xhtml" >
<head runat="server">
<title>Untitled Page</title>
</head>
<body>
<form id="form1" runat="server">
<div>

<asp:GridView ID="GridViewMembers" DataSourceID="ObjectDataSourceMembers" 
runat="server" AllowPaging="True" PageSize="2" 
OnPageIndexChanging="GridViewMembers_PageIndexChanging">
</asp:GridView>
<asp:ObjectDataSource ID="ObjectDataSourceMembers"
EnablePaging="True"
SelectCountMethod="SelectVirtualCount"
SelectMethod="GetAllUsers"
TypeName="MembersData" 
runat="server"></asp:ObjectDataSource>
</div>
</form>
</body>
</html>

public class MembersData
{
public MembersData()
{
//
// TODO: Add constructor logic here
//
    }
int selectCountValue = 0;
public int SelectVirtualCount()
{
return selectCountValue;
}
public MembershipUserCollection GetAllUsers(int startRowIndex, 
int maximumRows)
{
if (startRowIndex > 0)
startRowIndex = startRowIndex / maximumRows;
return Membership.GetAllUsers(startRowIndex, 
maximumRows, out selectCountValue);
}
}