In Part 1 of this series I discussed the basics of data binding in KnockoutJS. In this post, I’ll dive a little deeper in the the binding behaviors of KnockoutJS and show how you can build really responsive web apps using client side development techniques.

While data binding is an important part of KnockoutJS development, it is only part of what makes KnockoutJS so attractive. KnockoutJS is a JavaScript based implementation of the MVVM design pattern which is a derivation of the Presentation Model as described by Martin Fowler. Martin Fowler sums up the Presentation Model like this:

The essence of a Presentation Model is of a fully self-contained class that represents all the data and behavior of the UI window, but without any of the controls used to render that UI on the screen. A view then simply projects the state of the presentation model onto the glass.

As Fowler explains, the Presentation Model class should represent both the data and the behavior which are then bound to the view. Let’s dive into how KnockoutJS handles binding behaviors to your HTML.

Recently I started using KnockoutJS as a key component in my web development toolset. KnockoutJS has simplified my code while also allowing me to create richer web UIs. I have always disliked the amount of postbacks I was doing using a more traditional ASP.Net development approach. KnockoutJS eliminates many of the pain points associated with ASP.Net development and lends itself to a more modern AJAX based style of development. In this series of articles I’ll discuss some of the basics of developing ASP.Net applications using KnockoutJS. In future articles I’ll walk through some of the more advanced features of KnocktoutJS and show how you can use it in your DotNetNuke development.

 

 

After working with ASP.Net Webforms for the past decade, the time has come to move on. I have enjoyed using Webforms and I was pretty good at bending ASP.Net to my will. Having recently tried some newer web frameworks I find that I am more productive than ever before. Over the past couple of years I have dabbled with ASP.Net MVC, jQuery and even WebFormsMVP but none of them truly held my interest for long. I never felt like they really offered solutions to problems that I was worried about. Because of my involvement with DotNetNuke, and the fact that it relies heavily on Webforms, I found that I couldn’t justify the use of some of these technologies. Things like WebFormsMVP added too much friction to the way I was used to working. ASP.Net MVC couldn’t really work in any meaningful way with DotNetNuke. And jQuery was a nice add-on, but it didn’t fundamentally change the way I developed modules.

Overview

Last Wednesday night we kicked off the DotNetNuke Mobile Hackathon in St. Louis.  The focus of this hackathon is developing applications that span the DotNetNuke and mobile application space.  Participants have until the 6PM CST on August 25th to submit their entries.  As we mentioned at the user group meeting, we have been working on a community application that allows DotNetNuke users to stay connected even when they are not in front of their computer.  Starting today we are distributing the source code for DNN Pulse on the DotNetNuke Forge.

DNN Pulse is being built with Appcelerator Titanium and takes advantage of Xmlhttprequests, geolocation and mapping services to connect the user to the DotNetNuke community in their local area and on DotNetNuke.com.  During the coming months we will continue to add new features and functionality to the app so that no matter where you are, you can always stay plugged into the community.  Titanium was a natural fit for us since it allows us to target multiple mobile platforms with a single codebase, and because all of the code is written in Javascript we can re-use our existing coding skills without needing to learn a new language.

The initial code release is still beta quality code.  After the hackathon is complete we will incorporate a few remaining features which are not in the current codebase and clean up some of the error handling.  If you plan to use some of this code in your own app, then keep that in mind and code appropriately.

Background

In preparation for the upcoming DotNetNuke Hackathon in St. Louis, I have been busy working on a new mobile application for the Android and iPhone platforms.  Nik Kalyani and I have been playing with the Appcelerator Titanium product for the past several months and have been intrigued by it’s promise to allow you to quickly develop mobile applications for multiple platforms using the coding skills that many web developers already possess.  When Nik started planning for the St. Louis Hackathon he decided to focus on building apps which bridge the mobile and DotNetNuke space.  He immediately thought that Appcelerator was a natural tool to use.

What attracted Nik and I to Titanium was the ability to program in JavaScript with a light sprinkling of HTML and CSS to create native iPhone and Android applications.  It also helped that Titanium is an Open Source product which is a big plus for the DotNetNuke community.  The real Titanium magic happens when you compile your application using Titanium Developer.  At that point a native application is generated for either Android or iPhone, and coming soon the BlackBerry as well.  Titanium Developer lets you run your app on the various platform emulators as well as allowing you to push your application directly to a physical device.  As a final step, Titanium Developer even assists with publishing your finished application to the Android Market and the iPhone App store.

This morning I updated the source code for the Silverlight Pages module that I am building as part of the DotNetNuke Hackathon.  Based on some feedback from Michael Washington, I did a little refactoring to separate out my XAML display markup into a separate view.  This makes the code just a little bit cleaner and allows me to develop the view in Blend (of course that is a whole new thing to learn which will have to wait for later).  For now I will continue to hack away in XAML, learning a bit more each day and shaking off some of the cobwebs from what I had learned 2 years ago.

There are a number of cases in programming where you are often forced to store data in one format but need to convert that data to a different format for display.  One of the situations where this seems to come up quite often is in the storage hierarchical data structures.  SQL Server has traditionally had very poor support for dealing with hierarchical data.  SQL 2005 and 2008 have made some effort to try and simplify solving this problem, unfortunately, there is still a lot of data that is stored in a format that is not readily able to take advantage of these new SQL Features.

When working with legacy data, or legacy business tiers which expose the data as flat collections with ID and ParentID fields, you will likely need a simple way to convert these records into some form of nested collection.  This is a problem where people often resort to brute force methods for doing this conversion.  Unfortunately, the brute force approach is often slow and very specific to a specific set of data.

 

As part of the DotNetNuke Hackathon at the Capital DotNetNuke User Group on June 16th, I discussed using Silverlight to create rich DotNetNuke modules.  The example that I presented was a work in progress which I’ll be working on during the course of the Hackathon, even as participants are working on their own submissions.  You’ll be able to follow along with my progress over the next few days as I continue to flesh out the module.

The module that I am working on is a Silverlight based replacement for the core Pages module that appears on the Admin menu of a standard DotNetNuke installation.  That module has a very basic UI that makes it difficult to manage a site with dozens or even hundreds of pages.  The postback model used for moving pages in the heirarchy can make page re-organization...

This past year I had the pleasure of being asked by Jim Minatel at Wrox to write a Wrox Blox covering the basics of jQuery for ASP.Net Developers.  Having co-authored 2 previous books, I realized that writing a book, regardless of the size, is a lot of work, but something that I also find gratifying once you have a finished product.  Over the last 2 years, I had gotten more and more into jQuery and really loved its simplicity and power, and thought that this would be a great opportunity to share some of the knowledge I had gathered.

For those that are not familiar with the term, a Wrox Blox is a short e-book (30+ pages) which covers a narrow topic.  They are not intended to be an exhaustive discussion of a topic, but rather to cover one particular aspect of what is often a much broader subject matter.  Because of their narrower focus and the fact that they are only available as e-books, Wrox is able to keep the cost of the Wrox Blox very low.  Wrox Blox generally include a lot of code examples rather than being a purely theoretical discussion of a topic.

After a couple of months, several missed deadlines and a page count that greatly exceeded what was originally requested, I finally finished the Wrox Blox which was subsequently published last September.  I am very pleased with the final product which comes in at 66 pages and is a great introduction to jQuery and ASP.Net.  jQuery for ASP.Net Developers  includes sections on the jQuery API and its usage, and on using jQuery with ASP.Net WebForms and ASP.Net MVC frameworks.  I had a great time writing the book and like all writing assignments of this size, it really forced me to dig into jQuery much deeper than I had previously.  It also gave me a greater appreciation for why Microsoft chose to ship jQuery with Visual Studio 2010.

Why you shouldn’t learn MVC Earlier today Rob Connery posted about why he thinks You Should Learn MVC.  Rob is a great guy and we always have lively discussions whenever we meet at conferences.  I was in the middle of writing a long comment on his blog when I decided it might be better as it’s own post.

I have to say Rob, once again, another great post!  Another great use of straw man arguments and red herrings.  Come...

In 2006, Neal Ford wrote a blog post on the topic of Polyglot Programming which foresaw a future where applications will be increasingly built using multiple general purpose languages and domain specific languages.  Ted Neward has a recent article from MSDN Magazine which follows up on this theme with a discussion of Polyglot Programming in .Net.  Both Neal and Ted address some of the issues with Polyglot Programming, but I think there is one that they have missed.  Polyglot Programming can quickly lead to performance rot in application development.

In DNN Tips and Tricks #10, I presented an example of how you can use the DotNetNuke Report Module to display you data using the advanced capabilities of XSLT.  Greg Lahens pointed out an issue with my SQL code which is really highlights one of the downsides to Polyglot Programming.  As programmers, we often employ a variety of tools to solve a particular programming challenge.  Many of these tools are DSLs – XSLT, SQL, CSS, HTML are just a few of the many DSLs in common use throughout the web development world. 

In my previous post on the DNNMenu and SEO, I discussed testing user-agent strings and creating custom browser detection files.  As part of my testing I created a simple web-app that allows you to validate your browser capabilities.  By navigating to the test site, you can see exactly which features are enabled for your specific browser.  To alter how ASP.Net reports the capabilities for a specific user agent, create a custom .browser file and add it to the App_Browsers folder in your website.  See MSDN for a complete discussion of the browser definition file format.

...

I have long been a proponent of using HttpHandlers when you need to serve up content which is not HTML or where you desire an alternative to Asp.Net WebForms.  As I am sure many of you know, the standard ASPX page is a pretty heavyweight solution that is really overkill and a performance drain for many scenarios.  As a result, I tend to create a lot of custom HttpHandlers in order to squeeze the most performance out of my applications.

A few years ago, Phil Haack created a great abstract class that I used as the foundation for my HttpHandler implementations.  Over time I found that there was additional functionality which should be abstracted out and thus I have created my own version of the abstract boilerplate.  Even within Phi’s original code I have changed some basic functionality to more closely follow the ASP.Net framework rather than creating a different paradigm.  In Phil’s original code, he passed the context through numerous method calls.  Not only did the original boilerplate pass the HttpContext, but often the methods were accessing properties on the Request or Response objects.   This is very different from most other ASP.Net development where Request, Response and Context objects are all first class properties on the base class.

I have also added additional methods which can be overloaded to handle permission checks and for setting the content MIME type and the content encoding type.  Finally, because AJAX requests often send any data in the body of the HTTP call, I have exposed this data in a Content property.

Keith Elder’s recent post Dear Asp.Net Developers: Stop Making Our Technology Look Bad had a lot of great points but towards the end, I thought he suddenly swerved off the road.  In general, I agree with Keith that developers have a responsibility to provide all of their users with a good experience.  This is not always easy and I give sites lots of slack when I see they made a reasonable effort.  But when I see sites like the CodeZone example in Keith’s post, I have to wonder why those developers still have a job or where were the senior developers on...

 

There appears to me to be a recurring pattern I see on many web sites.  Often you will have a JavaScript library that you want to use which requires certain variables be defined in your web page.  I have seen this pattern repeated for many different widgets that you may want to include on your page.  [more]The pattern generally looks like this:



While this works, I didn’t like the need to create the extra script block just to set a few values.  There are some cases where the second script block is needed because you need to calculate the value, but often the values are fairly static or are calculated on the server when the page is generated.  In these cases, the extra script block should not be needed.  What I really wanted was a way...

In his recent post on Configuring the Stack, Jeff Atwood discusses the frustration that comes with installing a complete development environment. 

I'm having a hard time seeing how Microsoft's commercial stack is any easier to configure than the alternative open source stacks these days. Either the open source stuff has gotten a lot more streamlined and mature, or the Microsoft stuff is somehow devolving into complexity. I'm not sure which it is, exactly, but the argument that choosing a commercial development stack saves you time rings more and more hollow over time.

You can read through the comments and see that...

Dare Obasanjo posted about Three Things I Learned About Software in College, which Scott Hanselman followed up with Three Things I Learned About Software WHILE NOT in College. ...