Table of Contents
| Ch. 1 | An inside look at the evolution of DotNetNuke | 1 |
| Ch. 2 | Installing DotNetNuke | 29 |
| Ch. 3 | Portal overview | 55 |
| Ch. 4 | Portal administration | 65 |
| Ch. 5 | Host administration | 113 |
| Ch. 6 | Modules | 151 |
| Ch. 7 | DotNetNuke architecture | 187 |
| Ch. 8 | Core DotNetNuke APIs | 207 |
| Ch. 9 | Beginning module development | 259 |
| Ch. 10 | Developing modules : the database layer | 273 |
| Ch. 11 | Developing modules : business logic layer | 289 |
| Ch. 12 | Developing modules : the presentation layer | 299 |
| Ch. 13 | Skinning DotNetNuke | 331 |
| Ch. 14 | Distribution | 353 |
Read a Sample Chapter
Professional DotNetNuke ASP.NET Portals
By Shaun Walker John Wiley & Sons
ISBN: 0-7645-9563-6
Chapter One
An Inside Look at the Evolution of DotNetNuke
As much as I would like people to believe that DotNetNuke was intentionally created as a premier open source project for the Microsoft platform, it is unfortunately not the case. As is true with many open source projects, the software was created with commercial intentions in mind, and only when it was discovered that its true purpose would not be realized was it reconsidered as an open source project.
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 had primarily hired resources with Java skills - leaving myself 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 in order 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 had 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, while 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 had built a number Source Projects, which 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 very liberal End User License Agreement (EULA) that 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 very 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, a middle pane, and a 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, 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 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 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 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.
In order 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 will explain later.
When I first started experimenting with the IBuySpy Portal application I had some very specific objectives in mind. In order 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 very 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 had emerged with semi-self-maintained web applications but nearly all of them forced the organization to adopt the vendor's identity (that is, vendor.com/clientname rather than 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, which was a perfect candidate for mapping a specific domain name to a portal. It was as if the original creators (Microsoft/Vertigo) had considered this use case during development but had not had enough time to complete the implementation, so they had 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 codenamed 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, since all of this was going on outside of regular work hours, there was very little time to focus 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 very 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 had not been 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 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 had 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 their 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 very limited knowledge of the open source philosophy at this point since all of my previous experience had been in the Microsoft community - an area where "open source" was simply equated to the Linux operating system movement. However, there had been chatter in the Forums at various times regarding the organized sharing of source code, and there was obviously some interest in this area. 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 I mentioned earlier, the initial decision to open source what would eventually become DotNetNuke happened more out of frustration of not achieving my commercial goals rather than predicated philanthropic 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 ibuyspyworkshop.com when I released (the initial download links were based on an IP address, 65.174.86.217/ibuyspyworkshop). The second thing I did right was 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 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.
IBuySpy Workshop
The public release of the IBuySpy Workshop (see Figure 1-4) created such a surge in Forum activity that it was all I could do to keep up with the feedback, especially since this all occurred during the Christmas holidays. I had a family vacation booked for the first two weeks of January, and I left for Mexico on January 2, 2003 (one week after the initial IBuySpy Workshop release). At the time, the timing of this family vacation seemed very poor as the groundswell of interest in the IBuySpy Workshop seemed like it could really use my dedicated focus. However in hindsight, the timing could not have been better, because it proved that the community could support itself - a critical element in any open source project. When I returned home from vacation I was amazed at the massive response the release had achieved. The IBuySpy Portal Forum became dominated with posts about the IBuySpy Workshop and my Inbox was full of messages thanking me for my efforts and requesting me for support and enhancements. This certainly validated my decision to release the application as an open source project, but also emphasized the fact that I had started a locomotive down the tracks and it was going to take some significant engineering to keep it on the rails.
Over the coming months I frantically attempted to incorporate all community suggestions into the application while at the same time keep up with the plethora of community support questions. Because I was working a day job that prevented effort on the open source project, most of my evenings were consumed with work on the IBuySpy Workshop, which definitely caused some strain on my marriage and family life. Four hours of sleep per night is not conducive to a healthy lifestyle but, like I said, the train was rolling and I had a feeling the project was destined for bigger things.
(Continues...)
Excerpted from Professional DotNetNuke ASP.NET Portals by Shaun Walker 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.
loading...