Professional DotNetNuke 4.0: for ASP.NET 2.0 by Shaun Walker, Bruce Hopkins, Joe Brinkman, Patrick J. Santry, Scott McCulloch

From the Publisher

DotNetNuke is a powerful open source framework that creates and deploys robust modules on the ASP.NET platform. Written by its core team of developers, this book will provide you with the tools and insight you'll need to install, configure, and develop your own stunning Web applications using DotNetNuke 4.

You'll first gain an inside look into the history of this project as well as the basic operations of a DotNetNuke portal. You'll then find detailed information on how the application is architected and how you can extend it by building modules and skins. With this information, you'll be able to complete projects such as commercial Web sites, corporate intranets and extranets, online publishing portals, and custom vertical applications.

What you will learn from this book

• The latest features and functionality of DotNetNuke 4 for ASP.NET 2.0
• The best way to install DotNetNuke on the server
• Proven tips for managing and administering a DotNetNuke portal
• How to dramatically enhance your Web site's user interface using skins
• Techniques for extending the portal framework
• Ways to create a unique look for your porta

Who this book is for

This book is for the nondeveloper or administrator who wants to dive into the exciting DotNetNuke framework. It is also for experienced ASP.NET developers who want to use DotNetNuke to build dynamic ASP.NET sites or create add-ins to DotNetNuke.

Wrox Professional guides are planned and written by working programmers to meet the real-world needs of programmers, developers, and IT professionals. Focused and relevant, they address the issues technology professionals face everyday. They provide examples, practical solutions, and expert education in new technologies, all designed to help programmers do a better job.

Product Details

• Table of Contents
• Read a Sample Chapter

Table of Contents

Read a Sample Chapter

Professional DotNetNuke 4

John Wiley & Sons

Chapter One

By Shaun Walker Project Founder

As much as DotNetNuke is an open source software application written for the Microsoft ASP.NET platform, it is also a vibrant community with developers, end users, vendors, and volunteers - all working together collaboratively in a rich and diverse ecosystem. This chapter attempts to capture the essence of the project, expose its humble beginnings, provide insight into its evolution, and document its many achievements, but not shy away from some of the hard lessons learned in the process. The lifeblood of any community is its people; therefore, it is a distinct honor and privilege to be able to share some of the emotion and passion that has gone into the DotNetNuke project so that you may be able to establish a personal connection with the various stakeholders and perhaps precipitateyour own decision to join this burgeoning ecosystem.

In 2001-2002, I was working for a medium-sized software consulting company that was providing outsourced software development services to a variety of large U.S. clients specializing primarily in e-Learning initiatives. The internal push was to achieve CMM 3.0 on a fairly aggressive schedule so that we could compete with the emerging outsourcing powerhouses from India and China. As a result there was an incredible amount of focus on process and procedure and somewhat less focus on the technical aspects of software engineering. Because the majority of the client base was interested in the J2EE platform, the company primarily hired resources with Java skills - leaving me with my legacy Microsoft background to assume more of an internal-development and project-management role. The process improvement exercise consumed a lot of time and energy for the company, attempting to better define roles and responsibilities and ensuring proper documentation throughout the project life cycle. Delving into CMM and the PMBOK were great educational benefits for me - skills that would prove to be invaluable in future endeavors. Ultimately the large U.S. clients decided to test the overseas outsourcing options anyway, which resulted in severe downsizing for the company. It was during these tumultuous times that I recognized the potential of the newly released .NET Framework (beta) and decided that I would need to take my own initiative to learn this exciting new platform to preserve my long-term employment outlook.

For a number of years, I had been maintaining an amateur hockey statistics application as a sideline hobby business. The client application was written in Visual Basic 6.0 with a Microsoft Access backend and I augmented it with a simplistic web publishing service using Active Server Pages 3.0 and SQL Server 7.0. However, better integration with the World Wide Web was quickly becoming the most highly requested enhancement, and I concluded that an exploration into ASP.NET was the best way to enhance the application, and at the same time acquire the skills necessary to adapt to the changing landscape. My preferred approach to learning new technologies is to experience them firsthand rather than through theory or traditional education. It was during a Microsoft Developer Days conference in Vancouver, British Columbia in 2001 that I became aware of a reference application known as the IBuySpy Portal.

IBuySpy Portal

Realizing the educational value of sample applications, Microsoft built a number of source projects that were released with the .NET Framework 1.0 Beta to encourage developers to cut their teeth on the new platform. These projects included full source code and a liberal End User License Agreement (EULA), which provided nearly unrestricted usage. Microsoft co-developed the IBuySpy Portal with Vertigo Software and promoted it as a "best practice" example for building applications in the new ASP.NET environment. Despite its obvious shortcomings, the IBuySpy Portal had some strong similarities to both Microsoft Sharepoint as well as other open source portal applications on the Linux/Apache/mySQL/PHP (LAMP) platform. The portal allowed you to create a completely dynamic web site consisting of an unlimited number of virtual "tabs" (pages). Each page had a standard header and three content panes-a left pane, middle pane, and right pane (a standard layout for most portal sites). Within these panes, the administrator could dynamically inject "modules"-essentially mini-applications for managing specific types of web content. The IBuySpy Portal application shipped with six modules designed to cover the most common content types (announcements, links, images, discussions, html/text, and XML) as well as a number of modules for administrating the portal site. As an application framework, the IBuySpy Portal (see Figure 1-1) provided a mechanism for managing users, roles, permissions, tabs, and modules. With these basic services, the portal offered just enough to whet the appetite of many aspiring ASP.NET developers.

ASP.NET

The second critical item that Microsoft delivered at this point in time was a community forums page on the www.asp.net web site (see Figure 1-2). This forum provided a focal point for Microsoft developers to meet and collaborate on common issues in an open, moderated environment. Prior to the release of the forums on www.asp.net, there was a real void in terms of Microsoft community participation in the online or global sphere, especially when compared to the excellent community environments on other platforms.

One discussion forum on the www.asp.net site was dedicated to the discussion of the IBuySpy Portal application, and it soon became a hotbed for developers to discuss their enhancements, share source code enhancements, and debate IT politics. I became involved in this forum early on and gradually increased my community participation as my confidence in ASP.NET and the IBuySpy Portal application grew.

To appeal to the maximum number of community stakeholders, the IBuySpy Portal was available in a number of different source-code release packages. There were VB.NET and C#.NET language versions, each containing their own VS.NET and SDK variants. Although Microsoft was aggressively pushing the newly released C# language, I did not feel a compelling urge to abandon my familiar Visual Basic roots. In addition, my experience with classic ASP 3.0 allowed me to conclude that the new code-behind model in VS.NET was far superior to the inline model of the SDK. As luck would have it, I was able to get access to Visual Studio.NET through my employer. So as a result, I moved forward with the VB.NET/VS.NET version as my baseline framework. This decision would ultimately prove to be extremely important in terms of community acceptance, as I'll explain later.

When I first started experimenting with the IBuySpy Portal application, I had some specific objectives in mind. To support amateur sports organizations, I had collected a comprehensive set of end-user requirements based on actual client feedback. However, after evaluating the IBuySpy Portal functionality, it quickly became apparent that some significant enhancements were necessary if I hoped to achieve my goals. My early development efforts, although certainly not elegant or perfectly architected, proved that the IBuySpy Portal framework was highly adaptable for building custom applications and could be successfully used as the foundation for my amateur sports hosting application.

The most significant enhancement I made to the IBuySpy Portal application during these early stages was a feature that is now referred to as "multi-portal" or "site virtualization." Effectively this was a fundamental requirement for my amateur sports hosting model. Organizations wanted to have a self-maintained web site, but they also wanted to retain their individual identity. A number of vendors emerged with semi-self-maintained web applications, but nearly all of them forced the organization to adopt the vendor's identity (that is, www.vendor.com/clientname rather than www.clientname.com). Although this may seem like a trivial distinction for some, it has some major effects in terms of brand recognition, site discovery, search engine ranking, and so on. The IBuySpy Portal application already partitioned its data by portal (site), and it had a field in the Portals database table named PortalAlias that was a perfect candidate for mapping a specific domain name to a portal. It was as if the original creators (Microsoft and Vertigo) considered this use case during development but did not have enough time to complete the implementation, so they simply left the "hook" exposed for future development. I immediately saw the potential of this concept and implemented some logic that allowed the application to serve up custom content based on domain name. Essentially, when a web request was received by the application, it would parse the domain name from the URL and perform a lookup on the PortalAlias field to determine the content that should be displayed. This site virtualization capability would ultimately become the "killer" feature that would allow the application to achieve immediate popularity as an open source project.

Over the next 8 to 10 months, I continued to enhance and refactor the IBuySpy Portal application as I created my own custom implementation (now code-named SportsManager.Net). I added numerous features to improve the somewhat limited portal administration and content management aspects. At one point, I enlisted the help of another developer, John Lucarino, and together we steadily improved the framework using whatever spare time we were able to invest. Unfortunately, because all of this was going on outside of regular work hours, there was little time that could be focused on building a viable commercial venture. So at the end of 2002, it soon became apparent that we did not have enough financial backing or a business model to take the amateur sports venture to the next level. This brought the commercial nature of the endeavor under scrutiny. If the commercial intentions were not going to succeed, I at least wanted to feel that my efforts were not in vain. This forced me to evaluate alternative non-commercial uses of the application. Coincidentally, I had released the source code for a number of minor application enhancements to the www.asp.net community forum during the year and I began to hypothesize that if I abandoned the amateur sports venture altogether, it was still possible that my efforts could benefit the larger ASP.NET community.

The fundamental problem with the IBuySpy Portal community was the fact that there was no central authority in charge of managing its growth. Although Microsoft and Vertigo developed the initial code base, there was no public commitment to maintain or enhance the product in any way. Basically the product was a static implementation, frozen in time, an evolutionary dead-end. However, the IBuySpy Portal EULA was extremely liberal, which meant that developers were free to enhance, license, and redistribute the source code in an unrestricted manner. This led to many developers creating their own customized versions of the application, sometimes sharing discrete patches with the general community, but more often keeping their enhancements private, revealing only their public-facing web sites for community recognition (one of the most popular threads at this time was titled "Show me your Portal"). In hindsight, I really don't understand what each developer was hoping to achieve by keeping his enhancements private. Most probably thought there was a commercial opportunity in building a portal application with a richer feature set than their competitor. Or perhaps individuals were hoping to establish an expert reputation based on their public-facing efforts. Either way, the problem was that this mindset was really not conducive to building a community but rather to fragmenting it-a standard trap that tends to consume many things on the Microsoft platform. The concept of sharing source code in an unrestricted manner was really a foreign concept, which is obviously why nobody thought to step forward with an organized open source plan.

I have to admit I had a limited knowledge of the open-source philosophy at this point because all of my previous experience was in the Microsoft community-an area where "open source" was simply equated to the Linux operating system movement. However, there was chatter in the forums at various times regarding the organized sharing of source code, and there was obviously some interest in this area. The concept of incorporating the best enhancements into a rapidly evolving open-source application made a lot of sense because it benefited the entire community and created a wealth of opportunities for everyone. Coincidentally, a few open-source projects had recently emerged on the Microsoft platform to imitate some of the more successful open-source projects in the LAMP community. In evaluating my amateur sports application, I soon realized that nearly all of my enhancements were generic enough that they could be applied to nearly any web site-they were not sports-related whatsoever. I concluded that I should release my full application source code to the ASP.NET community as a new open source project. So, as a matter of fact, the initial decision to open source that would eventually become DotNetNuke happened more out of frustration of not achieving my commercial goals rather than predicated philan- thropic intentions.

IBuySpy Portal Forum

On December 24, 2002, I released the full open source application by creating a simple web site with a ZIP file for download. The lack of foresight of what this would become was extremely evident when you consider the casual nature of this original release. However, as luck would have it, I did do three things right. First, I thought I should leverage the "IBuySpy" brand in my own open source implementation so that it would be immediately obvious that the code base was a hybrid of the original IBuySpy Portal application, an application with widespread recognition in the Microsoft community. The name I chose was IBuySpy Workshop because it seemed to summarize the evolution of the original application-not to mention the fact that the IBSW abbreviation preferred by the community contained an abstract personal reference (SW are my initials). Ironically I did not even have the domain name resolution properly configured for www.ibuyspyworkshop.com when I released (the initial download links were based on an IP address, http://65.174.86.217/ibuyspyworkshop). The second thing I did right was to require people to register on my web site before they were able to download the source code. This allowed me to track the actual interest in the application at a more granular level than simply by the total number of downloads. Third, I publicized the availability of the application in the IBuySpy Portal Forum on www.asp.net (see Figure 1-3). This particular forum was extremely popular at this time; and as far as I know, nobody had ever released anything other than small code snippet enhancements for general consumption. The original post was made on Christmas Eve, December 24, 2002, which had excellent symbolism in terms of the application being a gift to the community.

(Continues...)

---

Excerpted from Professional DotNetNuke 4 by Shaun Walker Joe Brinkman Bruce Hopkins Scott McCulloch Chris Paterra Patrick J. Santry Scott Willhite Dan Caron Copyright © 2006 by John Wiley & Sons, Ltd. Excerpted by permission.
All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.

---