I have to say how much I appreciate the great job the new DotNetNuke Blog project team is doing.  For a long time, I blogged fairly regularly on DotNetNuke.com.  Ultimately, I decided to start writing my primary blog on my own site and only occasionally reposting to DotNetNuke.com.  When I moved to my own site, I also decided to switch blogging platforms.  I needed something which supported many of the modern blogging features.  For me the killer feature is Windows Live Writer (WLW) support. ...

It seems that everyone is jumping on the OpenID bandwagon - kinda.  First came WordPress.  Then Yahoo, AOL, Microsoft and now Google.  It seems that all the major internet players now officially support OpenID in one fashion or another.  In almost every case, the major players have really just stuck their toe in the water by becoming OpenID providers.  This means that your accounts on all of these services have now become valid OpenID tokens.  This is great news but it is not enough.

For most users, getting an OpenID account has never been a problem.  Anyone who wanted to use OpenID could easily have signed up with MyOpenID, MyID, ClaimID, Verisign or many other OpenID providers.  The real challenge for most users has been finding a site that accepts OpenID.  The list (also another one here) of sites that accepts OpenID is growing.  However, if you peruse those lists you will notice something missing.  Namely, what you won’t find is WordPress, or Yahoo, or AOL or Microsoft or Google on the list of sites accepting OpenID.

During the last couple of months as we were finalizing details for DotNetNuke OpenForce, I have been working on a Silverlight module that would allow visitors to the OpenForce website to see a real-time feed of Twitter posts related to the conference.  In the past this would have been done by using HashTags.org.  The problem with HashTags is that it requires users to remember to use the ‘#’ prefix to their terms.  It also requires twitter users to follow the @hashtags user.  Both of these requirements limit the usefulness of the service.  What I really wanted was a way to monitor anyone...

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.

It doesn’t seem like it was all that long ago that I was walking down the halls at the Mandalay Bay convention center and seeing the DotNetNuke OpenForce registration booth for the first time.  Last year was definitely an exciting time to be at OpenForce.  It was our first conference so no-one was quite certain what to expect.  The one thing I can say for sure is that it everyone who I spoke with, came away with a renewed sense of excitement and energy.

We are once again in the final stretch for the OpenForce conference.  Speakers are making the final tweaks to what I am certain will be another set of outstanding presentations. Exhibitors are busy making last minute updates to their booths.  Most of the planning is complete and we are just wrapping up the last little details.

DotNetNuke has long supported building modules as separate projects in Visual Studio.  With the release of Visual Studio 2005, Microsoft added a new compilation mode for web projects called Web Site Projects.  This required module developers to figure out how to work in the new paradigm since our previous module development methodologies would no longer work.  Anyone who was around for that transition knows how painful it was to relearn how to create modules.  The old methods no longer worked and the WSP model did not provide many of the same benefits as the compilation model in VS 2003.  Microsoft listened to the complaints of the DotNetNuke community and many other web developers who still wanted the old compilation model.  Their solution: Web Application Projects (WAP). 

WAP brought back the more traditional development style that DNN developers were used to.  Unfortunately there were some new kinks as well.  I have long advocated keeping my module projects separate from the DotNetNuke installation.  I create and destroy DNN installs quite a bit and don’t want to inadvertently delete some of my code during my frequent site purges.  Keeping my modules in a separate project directory allows me to delete websites without harming my modules.

As I posted a few weeks ago, we have added jQuery support to DotNetNuke 5.0.  This support makes it easy for developers to add jQuery to their modules and know that it will already be available on the server.  We have not yet decided on whether to also include jQuery UI support, but I suspect that it will also be made available once we figure out which specific UI features to support (the whole UI library is over 200K and definitely too much for most sites).

With jQuery we have tried to provide a mechanism that only loads the jQuery library when absolutely necessary.  If none of the modules or skin-objects on a page require jQuery, then it won’t be included in the page.  If your module wants to use jQuery then you must include a long, complicated...

Earlier today, DotNetNuke hit another milestone with the release of DotNetNuke 5.0.0 RC1.  RC1 is our first stable DotNetNuke 5.0.0 release and represents a feature complete version of the 5.0 platform.  From here on out we will be focused on fixing bugs and ensuring that any performance issues are resolved.  While it is true that DotNetNuke 5.0 represents a substantial change from 4.8.x, many of the updates in 5.0 were back ported to the recent 4.9 release.  Below is list of highlights for this release which were not included in 4.9.0.

Major Highlights Added jQuery support to the core platform.  jQuery will now be distributed as part of the DotNetNuke installation and will be available for use by module developers. Added support for...

For the last 4 years DotNetNuke has been adding more and more client-side functionality using JavaScript.  First we started with the ClientAPI which has added some great features to the platform.  When Microsoft created ASP.Net AJAX, we were quick to implement that as well since it solved several problems and didn’t require us to re-invent the wheel.  One of the key features in DotNetNuke 5.0 is the new Widget framework which simplifies the creation and distribution...

DotNetNuke 5.0 has changed the way that the page administrator edit mode works.  In previous versions of DotNetNuke, when you were in “edit” mode, the page would display the content inside of the various panes on the page.  This made it possible to see the panes when you were ready to place a new module on the page.  The downside to this behavior was that the pane borders and pane titles often caused problems with the skin.  For power users and administrators who were logged into the site, this was problematic since they would were often displayed a substandard rendering of the site.  [more]



With DNN 5.0, pane titles and borders are no longer shown in edit mode.  This allows administrators and power users to have a more pleasant experience.  The video below shows the new behavior and how it aids in module placement without the side-effect of breaking the visual appearance of the page.

The Camtasia Studio video content presented here requires JavaScript to be enabled and the latest version of the Macromedia Flash Player. If you are you using a browser with JavaScript disabled please enable it now. Otherwise, please update your version of the free Flash Player by downloading here.