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.

More...

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.

More...

Over the last several years DotNetNuke has maintained a policy of providing an upgrade path for users running previous versions of the platform.  Only in rare instances will we intentionally break a feature or an API or do something that would cause 3rd party extensions to break.  Customers have expressed to us over the years how important it is to maintain an upgrade path.  This concept is not unique to DotNetNuke.  Various projects and companies will take a different stance on the topic.  I was reminded of this recently with the Windows 7 launch where XP users were forced to make a tough decision – go through the hassle of installing a clean version of Windows 7 and then installing all of their old software and migrating their data (I hope grandpa had good backups), just stick with Windows XP, or move to a competitor.  Even Apple recognized the problem with the Windows 7 approach as evidenced by their Mac vs PC commercials.

More...

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.

More...

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 on really?  You are going to trot out jQuery as a reason to try MVC?  Why not say “Use MVC because it runs on Windows and works with IIS”.  Come on, at least use real arguments if you are going to make the case for MVC.  I’m sure you know that jQuery works wonderfully with WebForms.  People like Rich Strahl, Dave Ward and others have a ton of great blog posts on the topic.  I even have a few myself.  jQuery is a valid argument if you are trying to sell people on adding more JavaScript, but the argument as framed does not make the case for MVC.

More...

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. 

More...

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.

The below sample shows the capabilities I have configured for the Yahoo! Slurp web crawler.  This is not a definitive list of capabilities, but rather some custom values that I needed for my testing.  Feel free to alter this file as needed to more fully emulate the features supported by the Slurp engine.

<browsers>

    <browser id="Slurp" parentID="Mozilla">

        <identification>

            <userAgent match="Slurp" />

        </identification>

        <capabilities>

            <capability name="browser" value="Yahoo!Slurp" />

            <capability name="crawler" value="true" />

            <capability name="cookies" value="false" />

            <capability name="css1" value="true" />

            <capability name="css2" value="true" />

            <capability name="javascript" value="false" />

            <capability name="tables" value="true" />

            <capability name="w3cdomversion" value="1.0" />

            <capability name="xml" value="true" />

            <capability name="tagwriter" value="System.Web.UI.HtmlTextWriter" />

        </capabilities>

    </browser>

</browsers>

The screen below shows a short list of capabilities detected for Firefox 3.

  Download the BrowserCaps web application

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.

More...

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 the project.

Where I vehemently disagree with Keith is that his “solution” is for Asp.Net developers to adopt the MVC framework and NVelocity (or other non-webforms or non-Microsoft tools).  To me this is a complete non-sequitur.  You can create perfectly useable, XHTML/CSS compliant websites using WebForms and Visual Studio.  It is not hard.  It is just a matter of caring.  Hundreds of thousands of developers do it every day.  Lazy, uncaring developers will still be lazy and uncaring even if they are using the MVC framework. More...