I am often asked why I have switched from using Rainbow Portal to DotNetNuke.  I promised I would answer that. 

Both products have matured and maintain some distinctions.  Rainbow (RB) is written in C# and DotNetNuke (DNN) is in VB.NET.  That no longer matters to me because I am not working on the core of either product.  Also, I recommend that unless you can get your code added to the core product or you are planning to support your own branch then you should avoid touching the product source code as well.  If you change a copy of the product you set yourself up for challenges with future upgrades.  Extensibility projects or modules can be written in the .NET language of your choice so I do not consider the language argument to be valid anymore.

The other major distinction that might be worth mentioning is localization.  From the beginning RB has supported localization and it is the only 1 of the 2 products that currently allows for easy content localization.  Both products now support localization of menus and commands fairly well.  DNN is aware of their deficiency here and they plan to address it as some point.

Usability is the biggest reason I now use DNN.  When I first tried version 3 I was amazed at how quickly I could add a page (tab) and fill it with modules.  I was further impressed by the content editor’s experience.  In many places where you are creating a link you get a common control that easily lets you choose between linking to a page in your site,  a file on you site or a URI offsite,.  The file dialog really won me over.  It is very common for users to want to upload a PDF or Word document and then create a link to it.  In DNN you never have to leave the link edit page to accomplish all of that.  With RB it takes several clicks and some intermediate end user training to handle the simple document upload and link creation process.  It is so painful in RB that my team typically does it for the content managers.

The other major reason for my switch was the community.  I was fine with RB because I know the people who created and maintain it.  However, those I work with and who manage the many websites at Idaho Commerce and Labor have no relationship with RB’s creators.  If I were to take a new job or simply wanted to find some training resources for them it begins to get ugly fast.  The DNN community is so large now that you can find just about any help you need without calling up one of the core team. 

Largely due to the size of the DNN community I also found a rich and active market for extensibility of the product.  Mostly I am referring to the huge number of 3^rd party modules that are available at very low prices.  Often I have requests for new features on our websites and with RB I always had to replay with a number of hours it would take to custom build that functionality.  With DNN I now replay typically with a list of 3^rd party modules and their purchase price.  The prices are very palatable to almost any DNN user and often you can find working solutions for free.

I should also mention that I have found DNN skinning to be reasonably easy and far more desirable than classic RB skinning.  I know that RB now has the ZEN skinning engine, but I am very happy with the DNN solution and skinning must remain reasonable simple for any solution to work well.  I know that RB ZEN took some magic in the page lifecycle to make it work.  DNN is much simpler in its implementation with standard .NET user controls as Skin Objects.

A brief note also needs to be included here about the roadmap in DNN.  Namely, they have one and they try to stick to it.

Personally I can see no reason to go back to RB and every reason to believe that DNN will be a great solution for some time.  It already is an amazing content management tool and application development platform.  I view DNN less as an option and more as the default foundation for nearly all sites and applications.  The best way to decide between RB and DNN is to spend a few minutes with each.  I think you will be surprised to find how much better DNN really is.

On March 2nd the very excellent group of Rainbow Portal developers released Rainbow 2005.  This is the fastest and most functional build ever.  I was very impressed with the speed when I loaded it up for the first time today.  Everything clicked into view instantly.

Excellent job my friends!

A few months back I was talking with some other developers on the v.Next project about how we could abstract security out of our code.  The desire was to have methods and code blocks that could be wrapped with security checks, but without hard coding user or role names.  The current IBuySpy and Rainbow Portal for example have code in them like this if (User.IsInRole("Editor")) {do stuff}.  That works fine for a simple application, but what happens when you want to allow Admins and Editors?  In today's model you end up modifying the code and re-compiling and deploying.  I have seen a lot of code that strings together a bunch of OR statements when additional Roles need to be supported for a given security check.  It can get very ugly.

The solution is to have the authorization and permissions abstracted from the application so that when Users and Roles change you can easily change the security inside the application without changing code.  Enter Permission Manager (PM).  PM is the coolest piece of code I have seen for Whidbey so far.  I really can't believe something this good is already available and Whidbey just hit Beta 1.  It could be that I was already talking about building something like this that makes it cool, but for me it is how nicely it fits the ASP.NET 2.0 experience.  The code looks like it is native to ASP.NET.  It seems to follow the style of Microsoft's built-in classes very nicely.  It plugs in beautifully to the provider model allowing you to use it with your own custom provider for managing the permission sets for an application.

PM works by allowing the developer to create an abstracted permission object that implements IAccessObject.  This is simple to implement with basic name and ID properties.  The object then is used with the PermissionManager to create named permissions.  The sample has a news object that is used to create various permissions.  These permissions are completely separate from Users and Roles until you map them together.  For example, within the news permission set we may want a print and copy permission.  Using the PermissionManager static methods we make simple calls like: PermissionManager.CreatePermission(news.SourceGroup, "Copy", "Copy a document"); to create the Copy Permission.  When we want to map a real Role to the Copy permission of the news object we simply execute a method like this: PermissionManager.SetPermissionForRole("Copypeople", news, "Copy");.  This maps the Role of Copypeople to the permission of Copy on the news object.  news really is just an object for grouping of permissions.  Each application could have its own set or several sets.  Through the provider model permission sets could also be shared across applications by pointing them at the same data source.  This abstraction model allows us as developers to have as many application permissions as we want without needing matching security roles for each one of them.

This abstraction of Permissions is something that applications like Rainbow portal did with a lot of database mapping.  The problem has been that some Roles are hard coded and there is not a consistent provider based system for managing permissions.  I plan to give this concept a thorough workout as I start working with Whidbey.  It could also be ported to ASP.NET 1.x if you had a Users and Roles store that you could tie it in with.