Re: Why DotNetNuke?

Good thoughts and well positioned. You are right...the point is not that Microsoft is the only platform but it is a great, solid platform. DNN is not the only open source project in this arena, but it is a really strong offering.

DNN is a great platform for developing and as such provides amazing value. The weakest link appears to be some non-technical people who try to use it for content management and then get frustrated.

Re: Why DotNetNuke?

DotNetNuke is quite powerful. It has a wide variety of addins which you can buy from various vendors.I has power full inbuilt inline editing of site content.If you are not tied to .NET then there are various other options also but for .NET people i think DotNetNuke works best if you want to learn about DotNetNuke the go to www.youtube.com/watch?v=21jPsrIzDJI

Re: Why DotNetNuke?

A rose by any other name would be the same. Okay, so that’s not the quote but it works for me. DotNetNuke calls them Modules, SharePoint calls them Web Parts. They’re essentially the same thing. A .NET assembly (or assemblies) that makes up the logic and presentation for a function that can be placed anywhere on your portal.

A SharePoint Web Part, just like a DNN Module, is a component that can be used in a site. In DNN you add them to pages, in SharePoint you add them to Web Part pages. Same concept as they offer positioning, personalization, minimize capabilities, etc. DNN has a few extra baked in features that a SharePoint Web Part could use like RSS feeds, custom containers, and a print capability. Again, in vNext RSS is built into the entire system so your SharePoint Web Parts will now be subscribable, much like DNNs modules today.

The big advantage that SharePoint has over DNN is that DNN modules can only be used in DNN. SharePoint Web Parts can be used in other systems that use Windows SharePoint Services as a foundation (Small Business Server, Project Server, etc.). While you can’t use all Web Parts everywhere, if it works in WSS it will probably work in SBS. This feature actually becomes even more of an asset with vNext as ASP.NET Web Parts can be used in both ASP.NET apps as well as SharePoint sites so you’ll be able to say expose a data source in a business application and (depending on the codebase of course) drop it onto a SharePoint page without hassle. Again remember that this is all very dependent on how you build your Web Parts but I don’t see DNN modules being used anywhere but DNN, even with Version 4.x that is built on ASP.NET 2.0.

Having played my SharePoint Web Part card, I have to say that adding modules to DNN is a snap with it’s Private Assembly (PA) approach. Basically you package up the Module a certain way and a Host can upload it and make it available to any or all portals running under it. This is all done at runtime without the system going offline (which includes adding new tables to the database, etc.). This is great although I’m sure you could exploit this with a rogue module. Compare this to the fairly daunting task of a) adding an assembly to the bin directory or GAC b) adding the SafeControl entry to the web.config file and c) potentially doing an IISRESET or recycling the Application Pool. Now if someone were to build a “Upload Web Part Web Part” that would be something (hint, hint).

I won’t talk about developing Modules vs. Web Parts as I get into it below but it’s all very similar from a conceptual point of view (ASP.NET, User/Server Control, yada, yada, yada)

Core Modules

DotNetNuke provides about 25 core modules. These are available out of the box and ready to put onto any page by an end-user. The later releases (3.x and up) came with templates and a wizard to walk you through applying a set of pages and skins to your site immediately. This is very similar to a site or area template in SharePoint. SharePoint provides a stock number of list and document library templates along with a set of instances of these (based on the site template you select).

You might say DNN has more modules than SharePoint does but if you look at the DNN modules most can be achieved with a custom list and perhaps some custom views tossed in for good measure:

Feature DotNetNuke SharePoint Notes
Announcements Built-in Built-in Very similar but DNN offers the ability to add the date display to each announcement. Could be done with a DataView Web Part in SharePoint
Banners Built-in N/A Could be achieved with CEWP but not native. Could not accomplish banner rotation without either Java Script or custom Web Part
Contacts Built-in Built-in SharePoint wins out on this as it provides many more fields and can link to Outlook.
Discussion Built-in Built-in Both are very similar. Flat and practically useless for threaded discussions. DNN has a new core Forum module which is more like what traditional forums should be.
Documents Built-in Built-in Similar but SharePoint provides Office integration, versioning, and check in/out features that DNN doesn’t have.
Events Built-in Built-in Very similar as both offer list and calendar views, reoccuring events, expiration, etc. SharePoint provides Outlook integration with the ability to create a meeting workspace for an event.
FAQs Built-in N/A Could be done as a custom list but would need a DataView Web Part with Java Script or grouped views to do expand/collapse features that DNN has.
Feedback Built-in N/A Could be done with CEWP, Form Web Part, or a custom list but no email integration like DNN has.
IFrame Built-in Built-in PageViewer in SharePoint. CEWP can also link to content via a URL.
Image Built-in Built-in Pretty much exactly the same.
Links Built-in Built-in DNN has more flexibility around ordering and presentation of links but could accomplish similar things with SharePoint with some customization (not coding)
Newsfeeds Built-in N/A Requires third party web part but can be accomplished with Xml Web Part and XSLT file.
User Account Built-in Built-in Different access and presentation between SPS and WSS but similar to user account. Since SharePoint is using values from Active Directory rather than a custom list or database, not as much editing capability as DNN has.
Text/HTML Built-in Built-in CEWP in SharePoint. Pretty much exactly the same as DNN.
Members Built-in Built-in DNN has more features like last member logged in, current users, etc. SharePoint is generally just a list of who’s a member of the site.

It’s not an exact match, but it’s close and I would say each has advantages and disadvantages. An adventurous soul (not me, I have way too many projects on the go) might put together a custom SharePoint site template complete with the custom lists that DotNetNuke offer in a default DNN setup. There’s really no magic here although there some core DNN modules that you don’t need or have with SharePoint (like a login module). For the others, a custom list would pretty much give you similar functionality.

Putting on my DNN hat, I could say that you could add custom modules and perhaps tweak the codebase of DNN a bit to provide similar (but not 100%) funcationality of DNN that SharePoint has. After all, some of the Office 2003 integration is just done through ActiveX controls so nobody says it’s a “SharePoint” thing (for example, I’ve used the Address Book feature on a standard ASP.NET app before).

The only true gem that stands out here is the Office integration that SharePoint provides today and that may be compelling enough if you’re a MS shop and deal a lot with Office documents and Outlook contacts. You would probably have to go a long way with modifications to DNN to provide integration to Word (if that would be possible at all) and enable Word to check in a document to DNN (not saying it’s impossible, but certainly not a simple task).

Visibility

This is the primary feature in SharePoint that is missing today. In SPS we have Audience targeting and some security features to hide areas, but more often than not (and especially in WSS sites) the user sees more than he should. This is called Security Trimming, only show the end user what he can do and don’t let him get 5 steps into a Wizard only to tell him he doesn’t have access to complete the process (man does that bug the crap out of me).

Anyways, in DNN we have the ability to target modules to roles or inherit the pages security settings (which can also be targeted to roles). There is no individual user targeting here, so you have to define a role and assign that role to a user for him/her to see (or not see) a page or module. It works quite well and is vastly used on systems where clubs present information to members only, but the general public gets a different view until they register or otherwise are granted access.

Security trimming is there in SharePoint vNext (finally!) so again, the playing field is level.

Custom Look and Feel

This is a tough one but I have to give it to DotNetNuke as the winner (for now, see note below).

DNN uses something called Skins, very similar to Themes in WSS or using custom CSS files in SPS. However DNN Skins go one step further and let you design the layout of the page, including pulling in modules and controls (like the current date/time and a login control that shows who the user is or a logout button if they’re already recognized). Building a Skin for DNN is pretty basic and can take anywhere from a few minutes to a few hours (depending on how complex you create it). The great thing with DNN is that it uses the skin for every page in the system (primarily because the architecture of DNN runs off a single page). In any case, you don’t get the level of granularity in Themes vs Skins and frankly it’s easier to create a fully customized Skin in DNN (I built the WSS Skin for my personal site in about an hour).

Of course, we have to talk about SharePoint vNext as it fully utilizes ASP.NETs Master Pages so basically once that hits the streets, all bets are off. Apply a master page and instantly, Bob’s your uncle.