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.  Editing a long blog post in the FCK editor is painful.  Anyone who has ever lost a blog post because of a login timeout knows just how painful it truly can be.  I spend an hour or more writing my blog posts and to have it just disappear is enough to make you cry.

Not only have the blog team answered my desire for WLW support, but they have also been slowly but surely addressing many other pain points with the Blog module.  They are quickly bringing the look of the blog up to modern standards and are retrofitting many key features into the blog.  I am almost ready to dump this other blogging platform and move back to the DotNetNuke blog module.

Now I just need to find some time to write some code to support BlogML and I'll be good to go.  Of course, if the blog team beats me to it that would be great.  In the meantime I have to say well-done and a big kudos to you all.

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.

More...

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 on Twitter who was talking about the conference.

My first attempt with Silverlight quickly ran into technical challenges.  Between cross domain requests (XDR) and the indexing/filtering challenges plus the requirement to have twitterati follow another “special” user, it just seemed like the project would never be complete.  Nor would it achieve the critical mass needed to make such a service valuable.

Well, even while I was working on my solution, Twitter went and bought out the major Twitter search service – Summize.  Summize provides a real-time search service for the twitter feed that allows you to see exactly what people are talking about.  Twitter wasted no time in integrating Summize which can now be found at search.twitter.com.  The Summize search service not only provides a great website for searching twitter posts, but it also provides a simple, yet powerful API as well. 

Yesterday I had the fortune to stumble across the Monitter.com website which leverages jQuery to provide access to the Twitter search API.  This is exactly what I was looking for.  I took the Monitter widget, made a few tweaks and wrapped it in a DotNetNuke module.  I did this to simplify installation and configuration for DotNetNuke administrators.

I dogfooded the module on the OpenForce website for the upcoming North American conference in Las Vegas.  Now that all the obvious bugs have been worked out, I have uploaded the module to the DotNetNuke Forge.  The Forge is a frontend for CodePlex that allows DotNetNuke users to quickly find DotNetNuke modules without requiring DotNetNuke to actually host the project management infrastructure.  You can download the initial release from the Monitter For DNN page on CodePlex.

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

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.

More...

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.

More...

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 block of code that looks like this:

DotNetNuke.Framework.jQuery.RequestRegistration()

Ok, maybe it wasn’t so complicated.  For those C# developers who may not be able to read this VB code, just add a semi-colon

During the rendering phase of the page lifecycle, the framework will determine if anyone has requested jQuery and will add the appropriate jQuery reference to the page header section.  This ensures that jQuery is loaded on the page before any other scripts which might use it. 

NOTE: The framework will not remember who requested the jQuery service after a postback, so make sure to call RequestRegistration for each page request.

Because DotNetNuke 5.0 will include both Asp.Net AJAX support and jQuery support, you should read up on potential problems and conflicts that can occur if you are not careful.  A great place to start is Dave Ward’s blog.  He has a number of posts, which discuss some of the difficulties you may encounter.  I expect that with the pending jQuery inclusion in VS 2010, Microsoft will spend some effort to minimize any potential conflicts.

When you are first developing your module, you may want to step through your own JavaScript and into the jQuery script.  If that is the case, then go to the Host Settings page and turn on the jQuery Debug feature which will use the full jQuery library rather than the minified version of the file (trust me - you don’t want to try stepping through the minified version).

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 Internet Explorer 8 Web Slices.  Administrators can configure any module to use IE8 Web Slices including the ability to set time-to-live and expiration values.
• Removed distinction between admin modules and pages and normal pages.  This allows administrators to easily delegate access to any portion of the application to any group of users.
• Updated the installation services to support manifest files for all extension types.  Now skins, containers, providers and modules are all first class citizens that can be installed and uninstalled.
• Expanded XHTML, WCAG and ADA compliance.
• Refactored core to improve support for Unit Testing.  Refactored several core classes to use interfaces and added a simple component factory to provide dependency injection support. 
• Added ability to deny permissions in the permissions grid.  This new feature extends the permission framework to give administrators greater flexibility in defining permissions.
• Added Widget framework.  The new Widget framework allows you to quickly add JavaScript/html widgets to your site with very little effort.  The framework supports the use of a simple object tag based representation which means you don’t have to know JavaScript in order to add the widgets.
• Added new Object notation for using skin objects in Skins.  Skin designers will no longer need to include separate XML files when creating and packaging skins.  No more funky “[SKINOBJECT]” tags littering your html.  This significantly simplifies the process of creating skins and further opens up skin development to a broader group of designers.  If you include a simple JavaScript reference in your HTML skin, you can even get a full WYSIWYG experience when designing your skin.

In addition to these highlights there are literally hundreds of bug fixes in this release.

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 of JavaScript widgets.  In looking at an upcoming refresh of our admin UI, we were looking around at our various options.  We really need a richer user experience that will continue to have cross-browser support and that can easily be extended and used by the developer community when creating their own modules. 

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