Dare Obasanjo's 3 Laws of Platform Adoption: A DotNetNuke Perspective

Dare Obasanjo has an informative post up about the 3 Laws of Platform Adoption, which got me thinking about DotNetNuke as a platform for developers. The first competitor that comes to most peoples minds when thinking about DotNetNuke is Sharepoint but there are other Content Management Systems out there that are viable alternatives to small and medium businesses looking to step up their website in a cost efficient and functionality rich way. Joomla! seems to be getting a lot of attention among developers on the LAMP stack as a hip new replacement for phpNuke.

When it comes to using the 3 Laws of Platform Adoption as a metric I think DotNetNuke stacks up pretty well for your small to medium business. Lets take a look at the condensed version of the 3 Laws.

1. Developers adopt a platform when it offers differentiation from competitors


2. Developers adopt a platform when it reduces the cost of software development


3. Developers adopt a platform when it provides reach and/or better distribution

So, starting with the obvious number 1, what differentiates DotNetNuke from its competitors? For me, DotNetNuke is different than its competitors in that it is designed to run atop your existing Microsoft software without adding any licensing fees. Small business clients running *nix servers are few and far between, so the ability to leverage your existing technology resource investments gives people a warm and fuzzy feeling. As far as Sharepoint as a competitor is concerned, it just doesn't make sense for small businesses because of the licensing fees. I know that Sharepoint Services 3.0 is free to download for Windows Server 2003, but most of the cool features are only available by ponying up extra for MOSS.

In the world of providing custom solutions for small businesses, Cost = Time = Money. This is why DotNetNuke also has a good footing for number 2. From a developers standpoint DotNetNuke runs on very familiar, some would say it's even cheap (as in inexpensive), technology (Visual Studio Express, IIS, Windows Server, Vista, even XP), which means less setup, implementation, deployment and maintenance time. Developers can use the .Net language they are most comfortable in (C# all the way!) and utilize the functionality that DotNetNuke comes with right out of the box. Functionality like user profiles, role based security, multiple authentication providers, secure file access, and rich content editing.

DotNetNuke also has a strong and innovative community of users. The DotNetNuke Marketplace allows developers a place to distribute their products and services to a wide range of customers (current registered user base on DotNetNuke.com. The DotNetNuke core team has made it easy for users of DotNetNuke to find products in this marketplace by way of a link to the "Solutions Explorer" that is standard in all DotNetNuke installations. DotNetNuke acts like an open source community with a business mind. Along with the Marketplace, the introduction of Service Level Agreements that are competitively priced give other businesses the opportunity to make profits on helping users with their DotNetNuke problems.

DotNetNuke Search Engine Optimizing - Step 7 Good HTML

I found an interesting post in a blog written about a year ago from Tom Kraak, owner of Seablick Consulting. The post gives a good list of SEO tips to consider when using the DotNetNuke framework which I think is helpful for all the people involved in creating a web site. Your modern day web developer simply has to be cognizant about the SEO ramifications of their implementation details.

The one that comes to mind first when thinking about my role, as developer (see previous post about "Three D's", I'm the one with the halo ), is number 7.

Write well-formed, standard compliant HTML to improve accessibility and "crawlability." Consider excessive in-page JavaScript, HTML layout tables and frames junk food for search engines spiders. I'm well aware that strict XHTML remains a challenge with DNN, but let's make an effort to move away from quirks mode by adhering at least to XHTML transitional.

Number 7 is one of several good reasons why I am an advocate of DIV's over Tables. Regardless of the fact that all the cool kids seem to be using div's these days, I still like to be able to answer the question "Why do people use div's over tables?" when occasionally asked by the seasoned developer (aka Old Fogey) and ordinary Dreamweaver adept (aka Graphic Designer). Here is my basic response: Tables were meant for tabular data, that is what they should be used for. Now to add to that, tables are incredibly helpful in some situations; I'm not an advocate of throwing them completely under the bus for all layout handling.

The problem with using tables for layouts (that I personally have found) is that they are very frequently rendered differently in every browser. As a corollary (albeit slightly contrived) to this problem, I like to also point out that it often takes more HTML to do the same layout with tables. One single 120 x 120 block of glorious green background is done in one div tag and some CSS, whereas if it were done with tables it becomes 3 tags and some CSS. The increase in the number of tags means an increased surface area for rendering problems with the browser, not to mention the increase in the amount of code to maintain.

Glorious Green

Now Playing: T.I. - Swagger Like Us

Leveraging DotNetNuke Event Logging

We recently worked on a project where we were faced with logging some events that a custom module was creating. I decided to take a look at the DotNetNuke EventLogging API.




Here is some hacked together code that implemented this… Check out the sexy aggregate function at the bottom… :)

DotNetNuke.Services.Log.EventLog.EventLogController lc = new DotNetNuke.Services.Log.EventLog.EventLogController();
// Check if the logtype exists.
List logs = new List(lc.GetLogTypeInfo().Cast());
if ( !logs.Any(x => x.LogTypeKey == "IPVideo_Links") )
{
// If Not, create the logtype.
LogTypeInfo lt = new LogTypeInfo();
lt.LogTypeCSSClass = "IPVideo_Links";
lt.LogTypeDescription = "Logging the IPVideo Links Module";
lt.LogTypeFriendlyName = "IPVideo Links";
lt.LogTypeKey = "IPVideo_Links";
lt.LogTypeOwner = "DotNetNuke.Logging.EventLogType";
lc.AddLogType(lt);
}

// Add a log entry.
lc.AddLog(new LogProperties{
new LogDetailInfo("Property1", "Some Value 1"),
new LogDetailInfo("Property2", "Some Value 2"),
new LogDetailInfo("TimeSubmitted", DateTime.Now.ToString())
},
this.PortalSettings,
this.UserId,
"IPVideo_Links", /* Should probably make this a enum value */
true);

// Retrieve the events for the log.
int total = 0;
List details = new List(((LogInfo)lc.GetLog("IPVideo_Links", 100, 0, ref total)[0]).LogProperties.Cast());

// Get the events properties.
// I know you like my sexy use of Aggregate, admit it, its sexy.
string props = details.Aggregate("",
(result, logInfo) =>
String.Format("{0}{1}: {2}\n", result, logInfo.PropertyName, logInfo.PropertyValue));

// Show the properties.
txtDetails.Text = "Got the details\n" + props;

---

Here are some links I found useful when coming up with this code.

DNN Core API - Logging (pdf)

MSDN Aggregate Documentation