With exciting new offerings on the immediate horizon like Silverlight ( aka. WPF/E ), it is sometimes easy to forget some of the recent software releases which are now in full scale production rollout. During the alpha and beta stages of new product releases there is intense marketing focus and active community participation by the early adopters group as the product evolves from one version to the next. However once a product reaches final release form, the spotlight often immediately shifts to the next innovative technology category. This shift often happens before the released product has "crossed the chasm", the stage where the early majority consumer group contemplates mainstream adoption within their enterprise. And it’s often not the strength of the product but the support of the community which dictates whether a product is going to achieve long term industry success.
The official release of ASP.NET AJAX in January 2007, marked the culmination of over a year and a half of intense product development efforts by the ASP.NET team. This out-of-band release was a real milestone for Microsoft as it proved that exceptional results could be achieved by actively engaging the community in between major platform releases. This agile model allowed Microsoft to keep up with market demand and satisfy the needs of consumers, without compromising quality or features. However, the true success of this effort is largely contingent upon how many developers and organizations worldwide choose to embrace ASP.NET AJAX within their production environments now that it has been officially released.
DotNetNuke® is an open source web application framework and content management system ideal for creating, deploying and managing interactive web, intranet and extranet sites. Since Dec 24, 2002 it has attracted more than 420,000 registered users and tallied more than 3 million downloads. With metrics like these it is no surprise that DotNetNuke has the potential to influence the ASP.NET developer community in terms of technology adoption.
In the latter part of 2006, DotNetNuke recognized that the Asynchronous JavaScript with XML( AJAX ) programming model was becoming pervasive on all web platforms and it was fast becoming the most commonly requested enhancement for DotNetNuke by the community. Many third party developers creating extensions for DotNetNuke had already began experimenting with various AJAX libraries, often with poor results related to client-side conflicts. This led to the conclusion that DotNetNuke should provide official endorsement and integration of a specific AJAX library which could provide the full set of features while eliminating potential incompatibilities. Research was done into a number of full-featured AJAX libraries, both open source and proprietary, using a wide variety of criteria. Ultimately, ASP.NET AJAX was chosen because of its breadth in terms of feature set ( both server-side and client-side ) and its tight integration with the Microsoft development environment. However, there were also some challenges identified which needed to be addressed in order to move forward.
DotNetNuke is primarily used in shared hosting environments; an environment where the user usually does not have Administrator privileges to install new components on the server. Since ASP.NET AJAX has a support model which requires that it be installed into the GAC of the hosting server, it meant that DotNetNuke could not rely on the fact that ASP.NET AJAX was always available at run-time. This presented a unique challenge for the developers of DotNetNuke. And rather than forcing a new infrastructure requirement on users of the platform, they opted to add ASP.NET AJAX integration dynamically at run-time so that the application could continue to function with or without the optional dependency.
Based on its ASP.NET heritage, DotNetNuke was still using a Legacy setting for xhtmlConformance in its config file. In the migration to ASP.NET 2.0 this had never been updated because of the potential to cause compatibility issues in third party extensions for the platform. With the integration of ASP.NET AJAX, there was now a requirement to remove the Legacy setting. DotNetNuke Corporation felt that the future benefits gained from ASP.NET AJAX and from more standards compliant HTML output far outweighed the potential compatibility issues.
One of the fundamental goals of ASP.NET AJAX was simplicity for developers. The declarative syntax for ASP.NET AJAX makes it very easy for web developers to add AJAX functionality to their web applications. As a web application framework which provides value on top of ASP.NET, DotNetNuke generally aims for an even higher level of abstraction. As a result, one of the goals of the DotNetNuke integration was to make it trivial for both developers and administrators to enjoy the benefits of ASP.NET AJAX - without having to understand anything about the underlying implementation.
DotNetNuke has a portal engine which allows modules to be injected into a page at run-time. Each module is wrapped in a "container" which provides visual design characteristics as well as common portal functionality to interact with the module content. With the integration of ASP.NET AJAX, DotNetNuke is now capable of injecting an UpdatePanel wrapper around the module content. The UpdatePanel provides partial rendering capabilities for more efficient and responsive application usability. And since DotNetNuke manages the UpdatePanel configuration internally, module developers do not need to add any special declarative ASP.NET AJAX logic to their modules.
So let’s look at an example...
For the purpose of this demonstration we will use Visual Web Developer 2005 Express ( VWD2005 ). We will assume you already have the official release version of ASP.NET AJAX installed on your system. The next thing you need to do is download the DotNetNuke Starter Kit ( http://downloads.dotnetnuke.com ) and install it using the standard starter kit methodology.
Create a New Web Site and select the DotNetNuke Web Application Framework project template from the My Templates section. For simplicity, we will use the default File System location. Once the files are all unpacked, read the Quick Install instructions to complete the installation ( press Ctrl-F5 and select the Auto Installation option when the Wizard is displayed in your web browser ). Once the installation is complete, you will have a fully functional DotNetNuke web site on your local machine.
DotNetNuke provides the ability to build modules in a variety of different ways depending on your needs. You have the option to build Dynamic Modules ( conforming to the Web Site Project model ), Compiled Modules ( conforming to the Web Application Project model ), or WebControl Modules ( conforming to the WebControl model ). For the purpose of this demo ( and since we are using Visual Web Developer 2005 Express ) we are going to build a Dynamic Module. Returning to VWD2005, you will want to click the Refresh icon at the top of the Solution Explorer in order to synchronize the development environment with the web site. Find the DesktopModules folder and right-click to create a new subfolder. Enter the name 'Multiply'.
Highlight the folder created and right-click to Add New Item.
From the resulting dialog box select Web User Control from the installed templates, enter 'Multiply.ascx' as the filename, select Place code in a Seperate File, and click Add.
You have now created the main user control for your module. Double-click the Multiply.ascx file. Replace the source code with the following code snippet.
<%@ Control Language="VB" AutoEventWireup="false" CodeFile="Multiply.ascx.vb" Inherits="DesktopModules_Multiply_Multiply" %>
<asp:DropDownList ID="DropDownList1" runat="server" AutoPostBack="true"></asp:DropDownList>
X
<asp:DropDownList ID="DropDownList2" runat="server" AutoPostBack="true"></asp:DropDownList>
=
<asp:Label ID="Label1" runat="server"></asp:Label>
Basically we have declared two DropDownList boxes which are going to contain integers. The integers will be multiplied together and the product will be displayed in the Label control. We have set AutoPostBack to True so that the page performs a postback whenever a new selection is made. The use of AutoPostBack on ASP.NET web controls in the traditional model can lead to a poor user experience as it requires a full server round trip so that that the entire page can be refreshed. ASP.NET AJAX changes this paradigm so that only the affected region of the page is refreshed, providing a much more seamless and responsive user interface.
Now expand the Multiply.ascx file node and double-click the Multiply.ascx.vb file. Replace the source code with the following code snippet.
Imports DotNetNuke
Partial Class DesktopModules_Multiply_Multiply
Inherits Entities.Modules.PortalModuleBase
Protected Sub Page_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load
If Not Page.IsPostBack Then
For Counter As Integer = 0 To 99
DropDownList1.Items.Add(Counter.ToString)
DropDownList2.Items.Add(Counter.ToString)
Next
End If
End Sub
Protected Sub DropDownList_SelectedIndexChanged(ByVal sender As Object, ByVal e As System.EventArgs) Handles DropDownList1.SelectedIndexChanged, DropDownList2.SelectedIndexChanged
Label1.Text = (Integer.Parse(DropDownList1.SelectedValue) * Integer.Parse(DropDownList2.SelectedValue)).ToString
End Sub
End Class
The code simply populates the DropDownLists with integers and displays the product of the multiplication problem when the values in the DropDownLists are changed. We are now finished the creation of the Dynamic Module. The next step involves registering the module within the DotNetNuke site. In your web browser, select the Login link and sign in to the site using the Host account.
As an added security precaution, you will likely be asked to change your password as part of this process ( since the installation created the Host account with a default password ). Select the Module Definitions option from the Host navigation menu.
On the Module Definitions screen, hover your mouse pointer over the triangular icon in the upper left corner of the container to display the module actions menu. Select the Create New Module option.
Enter the Module Name, Folder Name, Friendly Name, and Description and select Create.
Now scroll to the bottom of the page, enter the New Definition name and select Add Definition.
Now scroll down yet again, and select Add Control. On the Edit Module Control screen, select the DesktopModules/Multiply/Multiply.ascx user control file we created earlier from the Source dropdown list. Select the Supports Partial Rendering checkbox and click Update.
The Supports Partial Rendering is an important new enhancement to DotNetNuke, as it allows the developer of the module to specify whether or not the module supports partial rendering within an UpdatePanel. Although the UpdatePanel is very good at refreshing only part of a page, there are instances where the UpdatePanel can cause issues with module processing. Some examples are file upload or download streaming, and scenarios where a module is using some of its own client-side JavaScript behaviors. It is up to the developer to test whether or not their control supports partial rendering or not.
Now that the module is registered within DotNetNuke, we want to add an instance of the module to a page. Click on the Home page link in the navigation menu. At the top of the page a Control Panel is displayed and you can use the expand icon on the right-hand side to display the full list of Administrator options.
In the middle portion of the Control Panel, choose the Multiply module from the list of installed Modules, enter a Title for the container, select Top as the Insert position, and Center for the Alignment. Now click the Add option to add an instance of the module to the current page.
You will now be able to test the module by selecting items from the two dropdown lists and verify that the product result updates automatically after each selection. You will notice that the entire page is not refreshed, only the portion within the Multiply module container.
So this is a very trivial example but it demonstrates a number of key points. First, you will notice that there is no ASP.NET AJAX specific markup required in the source code for the module. This makes it extremely simple for module developers to develop AJAX solutions, without having to understand the implementation details. It also means that the module will function in environments where ASP.NET AJAX is available as well as environments where it is not available. Second, the portal administrator has ability to granularly control whether they want AJAX behavior to be enabled for a module. This is accomplished by adjusting the Supports Partial Rendering value in the Module Definitions area.
So its great to be able to create an AJAX enabled module, but what if you wanted to share the module with other developers or even potential customers? DotNetNuke has a robust extensibility model which includes full packaging and distribution support. Packaging the module is as simple as navigating to the Module Definitions area in the Host menu and selecting the Multiply module from the list of installed modules. In the Edit Module Definitions screen, select the Create Module Package option from the module actions popup menu.
The Create Module Package option provides a module developer with a simple mechanism to package their module for distribution. Enter the File Name ( a file name conforming to DotNetNuke standards will be displayed by default ), select the Create Manifest File checkbox, and select the Create option.
The system will display the Module Package Log and instruct you on the location of the module package created ( in the /Install/Module/ folder of the website ). For those of you who are familiar with DotNetNuke module development, the Create Manifest File? option generates a validated DotNetNuke module manifest file in the following form ( notice the inclusion of the new "supportspartialrendering" node ):
<dotnetnuke version="3.0" type="Module">
<folders>
<folder>
<name>Multiply</name>
<friendlyname>Multiply</friendlyname>
<foldername>Multiply</foldername>
<modulename>Multiply</modulename>
<description>Multiply</description>
<version>01.00.00</version>
<businesscontrollerclass></businesscontrollerclass>
<modules>
<module>
<friendlyname>Multiply</friendlyname>
<cachetime>0</cachetime>
<controls>
<control>
<src>DesktopModules/Multiply/Multiply.ascx</src>
<type>View</type>
<supportspartialrendering>true</supportspartialrendering>
</control>
</controls>
</module>
</modules>
<files>
<file>
<name>Multiply.ascx</name>
</file>
<file>
<name>Multiply.ascx.vb</name>
</file>
</files>
</folder>
</folders>
</dotnetnuke>
The single ZIP file which is produced by the Module Packager can be distributed to other users of DotNetNuke, for immediate run-time installation through the Install New Module option in the Module Definitions area.
If you think your module has business value for other DotNetNuke users, you could even publish it as a commercial module. Commercial modules represent a rapidly evolving segment of the DotNetNuke ecosystem, with an estimated $2.0 million of transactions occurring in 2006. Commercial modules listed on the DotNetNuke Marketplace are visible to all users of the DotNetNuke application, through the new Solutions Explorer feature located in the Host menu.
The Solutions Explorer was built using the client-side features of the ASP.NET AJAX library and provides direct consumer marketing for vendors who are building commercial modules for the DotNetNuke platform. With integrated features such as these, the business ecosystem for DotNetNuke is expected to grow exponentially in the future as more consumers become aware of its robust extensibility model.
Lastly, it is important to note that UpdatePanel support is not the only ASP.NET AJAX integration offered with DotNetNuke 4.5. If developers want to take advantage of more advanced AJAX behaviors, DotNetNuke has a simple AJAX API which developers can use to enhance their offerings. Since run-time environment support is a key challenge with ASP.NET AJAX, there is the ability to specify a Dependency in the Module Definitions area for a module. The Dependency can be used to indicate that a module requires a specific run-time component such as ASP.NET AJAX ( System.Web.UI.ScriptManager ) in order to be installed successfully. In addition, the DotNetNuke framework needs notification from modules in terms of whether or not they require ASP.NET AJAX. The point here is that the DotNetNuke framework takes care of injecting the ScriptManager into the page and, since AJAX is an optional feature, it needs to know if any modules on a page are actually leveraging AJAX. To accomplish this goal, modules using AJAX need to call the DotNetNuke.Framework.AJAX.RegisterScriptManager() method within their initialization event.
There are a variety of enhancements already in the pipeline to improve the ASP.NET AJAX support in DotNetNuke in future releases. However, the integration offered in DotNetNuke 4.5 offers a great foundation for ASP.NET developers who wish to take advantage of ASP.NET AJAX today.