Dot Net Nuke Module Definitions Enhancement

DotNetNuke Module Definitions

Charles Nurse

Version 1.0.1

Last Updated: June 20, 2006

Category: Modules


Copyright © 2003-2005 Perpetual Motion Interactive Systems, Inc. All Rights Reserved.

Information in this document, including URL and other Internet Web site references, is

subject to change without notice. The entire risk of the use or the results of the use of

this document remains with the user.

The example companies, organizations, products, domain names, e-mail addresses,

logos, people, places, and events depicted herein are fictitious. No association with any

real company, organization, product, domain name, email address, logo, person,

places, or events is intended or should be inferred.

Complying with all applicable copyright laws is the responsibility of the user. Without

limiting the rights under copyright, no part of this document may be reproduced,

stored in or introduced into a retrieval system, or transmitted in any form or by any

means (electronic, mechanical, photocopying, recording, or otherwise), or for any

purpose, without the express written permission of Perpetual Motion Interactive

Systems, Inc. Perpetual Motion Interactive Systems may have patents, patent

applications, trademarks, copyrights, or other intellectual property rights covering

subject matter in this document. Except as expressly provided in any written license

agreement from Perpetual Motion, the furnishing of this document does not give you

any license to these patents, trademarks, copyrights, or other intellectual property.

Copyright © 2005, Perpetual Motion Interactive Systems, Inc. All Rights Reserved.

DotNetNuke® and the DotNetNuke logo are either registered trademarks or

trademarks of Perpetual Motion Interactive Systems, Inc. in the United States and/or

other countries.

The names of actual companies and products mentioned herein may be the trademarks

of their respective owners.



Abstract

In order to clarify the intellectual property license granted with contributions of software from any person or entity (the "Contributor"), Perpetual Motion Interactive Systems Inc. must have a Contributor License Agreement on file that has been signed by the Contributor.



Contents

Desktop Modules/Private Assemblies Enhancements.........2

Introduction .................................................................................................................... 2

Proposed Changes ........................................................................................................... 2

Separation of Core Desktop Modules.............................................................................. 3

Decoupling of Friendly Name, Module Name and Folder Name ................................... 5

GetDesktopModuleByName method .............................................................................13

Additional Fields to indicate what the Module supports...............................................16

Default CacheTime Property......................................................................................... 22

Additional Information..................................................... 25

Appendix A: Document History ........................................26

1



2



Desktop Modules/Private Assemblies Enhancements

Introduction

This document describes a proposed set of enhancements to DotNetNuke’s Desktop.

These enhancements are intended to make it easier to modify the friendly or display

name of the module as well as provide performance improvements in determining what

functionality the module supports.

Proposed Changes

� Separation of Core Desktop Modules

� Decoupling of Friendly Name, Module Name and Folder Name

� GetDesktopModuleByName method

� Additional Fields to indicate what the Module supports

� Default CacheTime Property

3



Separation of Core Desktop Modules

Background

From the IBuySpy era until version 3.0 of DotNetNuke, the “core” desktop modules have

been an integral part of the core application. During the development of version 3.0, the

modules were somewhat decoupled from the core, in that the code was separated into

separate projects.

In version 3.1, in response to feedback from hosters, the modules will be completely

separated from the core and provided as separate Private Assemblies (PAs), that hosters

can choose to install (or not install) for their customers.

Overview of Proposed Solution

The core Desktop Modules will be completely separated from the core. As mentioned

above the Visual Basic code has already been separated into independent Visual Studio

Projects.

Separation of the core Desktop Modules requires:

� Development of Install and Uninstall Scripts

� Creation of the Manifest file (.dnn)

� Creation of the Private Assembly (PA) package (.zip)

V3 introduced a tool that helped this process – the Private Assembly Packager. Red Gate

SQL Compare was used to generate the Install and Uninstall scripts and once these were

generated, the packager was used to create the Manifest and PA package.

4



Detailed Implications of Proposed Solution

DotNetNuke Installation:

Currently the Desktop Modules are installed during the DotNetNuke installation

process. The installation template identifies the modules to install (using a similar xml

structure to the dnn files used by the PA Installer).

However, with the complete separation of the core desktop modules, this approach can

no longer be used as it relies on the files already being in the correct place.

At the end of the v3 installation, after the Portal(s) have been created, additional

resources, including modules can be installed by placing the resource files in the

appropriate subfolder under the /Install folder. In this way, for instance the Forums and

Gallery modules can be installed by placing the PA zip files in the /Install/Module folder.

As we move forward, with the module separation, this step must be moved to happen

prior to the portal installation, so that the required modules are already present when

the portal template is parsed.

At first glance this can be accomplished by moving the install code:

'Install resources if present HtmlUtils.WriteFeedback(HttpContext.Current.Response, 0, “Installing Optional Resources:<br>") Dim objResourceInstaller As New ResourceInstaller objResourceInstaller.Install(True, 2)

…to run before the portal(s) are installed.

However, there is a problem with this. As the PA Installer is designed to run through the

UI, it includes a number of localized strings. These localized strings are instantiated in

the ResourceInstallerBase class. All the localization methods require the

“PortalSettings”, and as we haven’t created any portals yet, we don’t have a valid

PortalSettings object.

5



The solution to this problem is to modify the GetLocalizedString method in the

ResourceInstallerBase class to:

Private Function GetLocalizedString(ByVal key As String) As String Dim objPortalSettings As PortalSettings = CType(HttpContext.Current.Items("PortalSettings"), PortalSettings) If objPortalSettings Is Nothing Then Return key Else Return Localization.GetString(key, objPortalSettings) End If End Function

This first checks for the existence of the PortalSettings in the HttpContext and only

localizes the strings if the PortalSettings exists.

Decoupling of Friendly Name, Module Name and

Folder Name

Background

During the decoupling process it became clear that the “FriendlyName” field was serving

multiple purposes.

� It is being used as the “name” of the module, for instance in

GetModuleByName(name)

� It is being used as the “display name” in the module combos in the Control Panel.

� It is being used as the folder name (where the core files, especially the uninstall

script files are stored). Note that the ModuleControl source files can be anywhere,

as the path is explicitly defined for each ModuleControl. This allows for controls to

be shared between modules.

There also is some inconsistency in the use of the friendly name. For instance, prior to

v3 (3.0.11), the <name> node in the manifest (dnn) file was used to define the

FriendlyName field in the DesktopModules table (as well as the folder name), but in

3.0.11 (to support the new Forums/Blogs module) a new optional <friendlyname> node

was added.

6



From 3.0.11 if both nodes are defined the <name> node is used to define the folder name

and the <friendlyname> is used to define the FriendlyName field. If the optional

<friendlyname> node is not present then the <name> node serves both purposes.

There are 5 original core modules where the FriendlyName in the DesktopModules table

does not correspond to the folder where the module is “installed”.

� Image (folder = Images)

� Text/HTML (folder = HTML)

� News Feeds (RSS) (folder = News)

� User Defined Table (folder = UserDefinedTable

� XML/XSL (folder=XML)

For all 5 of these modules the “Private Assembly Packager” and the “Uninstaller” do not

work as expected. This is because both of these functions have no way of determining

the location of the module (ie. the folder name). One could look at the Source parameter

of the Controls and for these modules this would provide the correct folder, but as

mentioned before, in theory the ModuleControls could exist anywhere. There is no

requirement that they are physically located in the modules “folder”.

Both of these functions assume the folder name is the module’s FriendlyName.

For the Packager this means that the <name> and <friendlyname> nodes are both set to

the FriendlyName. When the resulting package (eg Image) is installed on a different

system the Installer tries to install the PA into the “Image” folder, rather than the

“Images” folder, and the ControlSrc properties for the ModuleControls (which point to

Images) are incorrect. The manifest can be manually modified, by changing the <name>

node to the correct folder (or by changing the ControlSrc property for the controls), but

this not an ideal solution.

There is a similar issue with the “Uninstaller” triggered by clicking on the “Delete” link in

the Module Definitions UI. The “Delete” code assumes that the uninstall script file is in

the folder defined by the FriendlyName, and if it can’t find it (as is the case in this

scenario) it doesn’t run the uninstall script and the database objects are not removed.

An additional problem is found with the Text/HTML and XML/XSL modules. In these

cases the FriendlyName contains path-delimiter characters, and the Packager and

7



Uninstaller both throw exceptions as the resulting paths DesktopModules/Text/HTML

and DesktopModules/XML/XSL do not exist.


The proposed solution to this “problem” is to add two new fields to the DesktopModules

table and the associated business class. These fields will be called FolderName and

ModuleName.

ModuleName will map to the <name> node in the Installer manifest. FolderName will

map to a new optional <foldername> node in the Installer manifest. However, in the

absence of this new node then <foldername> will map to the <name> node.

The Uninstall script file will be saved to the folder specified by the FolderName

field/property, the “Uninstaller” will look in this folder for the script, and the packager

will look in this folder for the “Project file”, which in turn is used to generate the files list.

This solution only affects those areas where the FriendlyName is being “used” as the

folder name. All other “uses” of the FriendlyName field/property are unaffected by this

proposal.


DesktopModules Table:

New Fields called FolderName and ModuleName would need to be defined. eg

[FolderName] nvarchar(50) NULL, [ModuleName] nvarchar(50) NULL

In addition, for the existing modules these fields would need to be set in the Upgrade

script to the “FriendlyName”, except for the 5 core modules, where they would need to be

set to the actual folder where the files are stored: eg

ALTER TABLE {databaseOwner}{objectQualifier}DesktopModules ADD [FolderName] nvarchar(50) NULL,

8



ADD [ModuleName] nvarchar(50) NULL GO UPDATE {databaseOwner}{objectQualifier}DesktopModules SET [FolderName] = FriendlyName, [ModuleName] = FriendlyName GO ALTER TABLE {databaseOwner}{objectQualifier}DesktopModules ALTER COLUMN [FolderName] nvarchar(50) NOT NULL ALTER COLUMN [ModuleName] nvarchar(50) NOT NULL GO UPDATE {databaseOwner}{objectQualifier}DesktopModules SET [FolderName] = 'XML', [ModuleName] = 'XML' WHERE [FriendlyName] = 'XML/XSL' GO

Etc…

DesktopModuleInfo class:

New Properties and corresponding Private fields would need to be added, eg

Public Property FolderName() As String Get Return _FolderName End Get Set(ByVal Value As String) _FolderName = Value End Set End Property Public Property ModuleName () As String Get Return _ModuleName End Get Set(ByVal Value As String) _ModuleName = Value End Set End Property

DesktopModuleController/DataProvider classes:

9



The AddDesktopModule and UpdateDesktopModule methods of both the

DesktopModuleController class and the DataProvider class, as well as the relevant MS

SQL stored procedures would have to be updated to save the FolderName property to the

DesktopModules [FolderName] field, and the ModuleName property to the

DesktopModules [ModuleName] field.

PA Installer:

There are a number of implications to the PA Installer from these changes. In the v3

schema definition, a new optional element is required for the <foldername>:

<xs:element name="foldername" type="xs:string" minOccurs="0" />

In the PaFolder class a new property FolderName and corresponding private field is

required:

Public Property FolderName() As String Get Return _FolderName End Get Set(ByVal Value As String) _FolderName = Value End Set End Property

In the Adapter classes the following needs to be added to the

GetFolderAttributesFromNode method of the PaDnnAdapter_V2 class:

Folder.FolderName = Folder.Name

And to the same method in the PaDnnAdapter_V3 class:

Dim foldernameElement As XmlElement = DirectCast(FolderElement.SelectSingleNode("foldername"), XmlElement) If Not foldernameElement Is Nothing Then folder.FolderName = foldernameElement.InnerText.Trim End If

10



This allows the FolderName to be set to the optionally provided <foldername> element

or to the <name> element if the <foldername> is not present.

Finally in the GetDesktopModuleSettings method of the PaDnnInstaller_V3 class the

following two lines need to be added to set the FolderName and ModuleName properties

of the DesktopModuleInfo object.

objDesktopModule.FolderName = Folder.FolderName objDesktopModule.ModuleName = Folder.Name

PA Packager:

The only implication to the PA Packager is that the _Name private member would need

to be mapped to the ModuleName instead of the FriendlyName, and the FolderName

would need to be output.

Old: _Name = objDesktopModule.FriendlyName nodeFolder.AppendChild(XmlUtils.CreateElement(xmlManifest, "name", _Name)) nodeFolder.AppendChild(XmlUtils.CreateElement(xmlManifest, "friendlyname", _Name)) New: _Name = objDesktopModule.ModuleName nodeFolder.AppendChild(XmlUtils.CreateElement(xmlManifest, "name", _Name)) nodeFolder.AppendChild(XmlUtils.CreateElement(xmlManifest, "foldername", objDesktopModule.FolderName)) nodeFolder.AppendChild(XmlUtils.CreateElement(xmlManifest, "friendlyname", objDesktopModule.FriendlyName))

Currently the PA Packager tries to determine where the files are located from the folder

where the first control is stored. With the addition of the FolderName property, we can

now use this to identify where the files are located.

_Folder = Common.Globals.ApplicationMapPath & "\DesktopModules\" & objDesktopModule.FolderName

11



Edit Module Definition UI:

The Edit Module Definition UI currently will need to add support for adding and

displaying the FolderName and ModuleName. As with the original implementation of

Friendly Name these should be readonly except when adding a new definition.

<tr> <td class="SubHead" width="150"> <dnn:label id="plModuleName" text="Module Name:" controlname="txtModuleName" runat="server" /> </td> <td> <asp:textbox id="txtModuleName" cssclass="NormalTextBox" width="390" columns="30" maxlength="150" runat="server" enabled="False" />

<asp:requiredfieldvalidator id="valModuleName" display="Dynamic" resourcekey=" valModuleName.ErrorMessage" errormessage="<br>You must enter a Module Name" controltovalidate="txtModuleName" runat="server" /> </td> </tr> <tr> <td class="SubHead" width="150"> <dnn:label id="plFolderName" text="Folder Name:" controlname="txtFolderName" runat="server" /> </td> <td> <asp:textbox id="txtFolderName" cssclass="NormalTextBox" width="390" columns="30" maxlength="150" runat="server" enabled="False" /> </td> </tr>

There would need to be some additions to the code behind to support these extra fields

as well.

As the FriendlyName is being used as a display name (that could be modified by the

user), the readonly nature of the txtFriendlyName textbox should be removed. Also, the

validation for the FriendlyName should be removed (as this will be defaulted to the

ModuleName) in the absence of a provided value.

In the Delete Event in the EditModuleDefinition.ascx.vb UserControl, the logic currently

uses the FriendlyName (txtFriendlyName.Text) to identify the Folder, where the files are

located. This logic would now need to check the “Folder Name” instead:

12



Dim strRoot As String = Request.MapPath("~/DesktopModules/" & txtFolderName.Text) & "\"

as this is where the files are located.

13



GetDesktopModuleByName method

Background

This method is part of the DesktopModuleController class. It is used to retrieve a

DesktopModule based on the friendly name provided, and it has a corresponding

method in DataProvider and SQLDataProvider, as well as a corresponding stored

procedure.

Overview of Proposed Change

It is proposed that at the Data Access Layer level this method be renamed

GetDesktopModuleByFriendlyName, and that the Business Layer method be modified to

call this renamed method, as well as deprecate the method in favour of two new

methods:

� GetDesktopModuleByFriendlyName (does the same as the deprecated method)

� GetDesktopModuleByModuleName (uses the module name – the preferred method

given that this value is the “key”).

There are nine locations in the code where this method is used. The proposed changes

will allow some or all of these calls to be replaced by the more appropriate call

GetDesktopModuleByModuleName. However, the proposed changes do not require

these to be changed, as all we have done so far is to modify the implementation slightly.

Further analysis will need to be done to evaluate the implications of replacing the calls to

the GetDesktopModuleByName method.


DataProvider class:

The new methods need to be added to the DataProvider class.

Public MustOverride Function GetDesktopModuleByFriendlyName(ByVal FriendlyName As String) As IDataReader Public MustOverride Function GetDesktopModuleByModuleName(ByVal ModuleName As String) As IDataReader

14



SQLDataProvider class:

The new methods need to be added to the SQLDataProvider class.

Public Overrides Function GetDesktopModuleByFriendlyName(ByVal FriendlyName As String) As IDataReader Return CType(SqlHelper.ExecuteReader(ConnectionString, DatabaseOwner & ObjectQualifier & "GetDesktopModuleByFriendlyName", FriendlyName), IDataReader) End Function Public Overrides Function GetDesktopModuleByModuleName(ByVal ModuleName As String) As IDataReader Return CType(SqlHelper.ExecuteReader(ConnectionString, DatabaseOwner & ObjectQualifier & "GetDesktopModuleByModuleName", ModuleName), IDataReader) End Function

In addition the existing method must be modified to call the stored procedure –

GetDesktopModuleByFriendlyName.

Stored Procedures:

The existing stored procedure GetDesktopModuleByName is dropped and the new

stored procedures are created:

DROP procedure {databaseOwner}{objectQualifier}GetDesktopModuleByName GO CREATE procedure {databaseOwner}{objectQualifier}GetDesktopModuleByFriendlyName @FriendlyName nvarchar(128) as select * from {objectQualifier}DesktopModules where FriendlyName = @FriendlyName GO CREATE procedure {databaseOwner}{objectQualifier}GetDesktopModuleByModuleName @ModuleName nvarchar(128) as select * from {objectQualifier}DesktopModules where ModuleName = @ModuleName GO

DesktopModuleController class:

15



The two methods are added to the DesktopModuleController class:

Public Function GetDesktopModuleByFriendlyName(ByVal FriendlyName As String) As DesktopModuleInfo Return CType(CBO.FillObject(DataProvider.Instance().GetDesktopModuleByFriendlyName(FriendlyName), GetType(DesktopModuleInfo)), DesktopModuleInfo) End Function Public Function GetDesktopModuleByModuleName(ByVal ModuleName As String) As DesktopModuleInfo Return CType(CBO.FillObject(DataProvider.Instance().GetDesktopModuleByModuleName(ModuleName), GetType(DesktopModuleInfo)), DesktopModuleInfo) End Function

16



Additional Fields to indicate what the Module supports

Background

In DotNetNuke v3 there are a number of Interfaces that the Modules can optionally

support. Often the core needs to know if a particular module supports an Interface.

Currently, this is done by instantiating the module and then testing whether it supports

the interface by reflection. Typically reflection is an expensive operation.

Proposed Solution

The proposed solution to this is to provide “flag” fields in the DesktopModuleInfo class

and corresponding database table, which indicate whether a module supports an

Interface. Many of the requests in the core can then determine the support for an

Interface by checking the appropriate property, and potentially avoid an expensive

reflection call.

Note: the reflection will still be necessary, should the core determine that the Module’s

interface needs to be called. This just improves performance when the reflection is being

made for information only, for example in the building of the Action menu in Skin.vb. It

also allows for the removal of the “stub” methods in the View control, which are only

present to inform the “core” that the module supports the Interface.


DesktopModules Table:

New Fields would need to be defined. eg

[IsPortable] [bit] NOT NULL DEFAULT (0) [IsSearchable] [bit] NOT NULL DEFAULT (0)

In addition existing Module’s values would need to be set in the Upgrade script.

17



ALTER TABLE {databaseOwner}{objectQualifier}DesktopModules ADD IsActionable bit NOT NULL CONSTRAINT DF_{objectQualifier}DesktopModules_IsActionable DEFAULT 0 GO UPDATE {databaseOwner}{objectQualifier}DesktopModules SET [IsActionable] = 1 WHERE [FriendlyName] = 'Text/HTML' GO

Etc…

DesktopModuleInfo class:


Public Property IsPortable () As String Get Return _IsPortable End Get Set(ByVal Value As String) _IsPortable = Value End Set End Property

Etc…

DesktopModuleController/DataProvider classes:

The AddDesktopModule and UpdateDesktopModule methods of both the

DesktopModuleController class and the DataProvider class, as well as the relevant MS

SQL stored procedures would have to be updated to save these new properties to the

DesktopModules Table.

PA Installer:

We could implement the IsPortable/IsSearchable properties as fields in the .dnn file.

However, a more elegant approach is to instantiate the ModuleController and then use

reflection to determine what the module supports.

18



In the GetDesktopModuleSettings method of the PaDnnInstaller_V3 class add the

following:

objDesktopModule.IsSearchable = False objDesktopModule.IsPortable = False Dim objController As Object = Framework.Reflection.CreateObject(objDesktopModule.BusinessControllerClass, objDesktopModule.BusinessControllerClass) If TypeOf objController Is ISearchable Then objDesktopModule.IsSearchable = True End If If TypeOf objController Is IPortable Then objDesktopModule.IsPortable = True End If

ModuleInfo class:


Public Property IsPortable () As String Get Return _IsPortable End Get Set(ByVal Value As String) _IsPortable = Value End Set End Property

Etc…

Also the private fields would have to be initialized in Initialize():

_IsPortable = False _IsSearchable = False

19



And in Clone():

objModuleInfo.IsPortable = Me.IsPortable objModuleInfo.IsSearchable = Me.IsSearchable

ModuleController class:

The FillModuleInfo() method would need to be updated to “fill” the new ModuleInfo

properties.

Try objModuleInfo.IsPortable = Convert.ToBoolean(Null.SetNull(dr("IsPortable"), objModuleInfo.IsPortable)) Catch End Try Try objModuleInfo.IsSearchable = Convert.ToBoolean(Null.SetNull(dr("IsSearchable"), objModuleInfo.IsSearchable)) Catch End Try

Skin Class:

The skin class uses reflection on the PortalModuleBase object, to determine whether to

add Module Actions to the Action menu (Export/Import if IsPortable) and (Syndicate if

IsSearchable).

In order to remove the stub methods from the PortalModuleBase control, we will need to

modify the code as follows.

Old:

If TypeOf objPortalModuleBase Is IPortable Then … End If If TypeOf objPortalModuleBase Is ISearchable Then … End If

New:

20



If objModule.IsPortable Then … End If If objModule.IsSearchable Then … End If

DesktopModules View Controls:

Currently the View Controls of the DesktopModules have to implement

IPortable/ISearchable, providing stub methods to indicate to the core that the control

implements the Interface, even though the actual implementation occurs in the

Controller class.

With this change we can now remove these Implementations.

IPortable calls

In a number of locations the Controller Class is instantiated and then checked to see if

the Module supports the IPortable Interface. We can improve the efficiency by checking

the IsPortable property. These occur in

ImportModule method of Import Class ExportModule method of Export Class AddContent method of Template Class ParsePanes method of PortalController Class

Old:

If objModule.BusinessControllerClass <> "" Then

New:

If objModule.BusinessControllerClass <> "" And objModule.IsPortable Then

ISearchable calls

21



In the ModuleIndexer the GetModuleList method makes a call to the Database to get the

SearchModules – those Modules that support Search. The Stored Procedure used by this

call gets a list of Modules that support Search by determining if the

BusinessControllerClass is not Null. This is a necessary requirement, but some Modules

may have this defined for other reasons, so the stored procedure will return more

modules than it should. Because of this the method needs to check that the resulting

module supports the ISearchable interface.

This could be made more efficient by adding the line:

and DM.IsSearchable = 1

to the WHERE clause of the Stored Procedure.

22



Default CacheTime Property

Background

The ModuleInfo class has a CacheTime property, that is used to determine caching for

the Module. This Cache Time has to be set for each instance of a module. It is proposed

that a default Cache Time be implemented for the Module Definition (configurable by

the host).


An additional field DefaultCacheTime will be added to the ModuleDefinition table, and

to the ModuleDefinitionInfo class. When a module is added to the page the

DefaultCacheTime value will be copied to the CacheTime property of the TabModuleInfo

instance.


ModuleDefinitions Table:

The field DefaultCacheTime would need to be defined. eg

[DefaultCacheTime] [int] NOT NULL DEFAULT (0)

In addition existing DefaultCacheTime values would need to be set in the Upgrade script.

ALTER TABLE {databaseOwner}{objectQualifier}ModuleDefinitions ADD DefaultCacheTime int NOT NULL CONSTRAINT DF_{objectQualifier}ModuleDefinitions_DefaultCacheTime DEFAULT 0 GO

23



ModuleDefinitionInfo class:

New Properties and corresponding Private fields would need to be added, eg Public Property DefaultCacheTime() As Integer Get Return _DefaultCacheTime End Get Set(ByVal Value As Integer) _DefaultCacheTime = Value End Set End Property

ModuleDefinitionController/DataProvider classes:

The AddModuleDefinition method of both the ModuleDefinitionController class and the

DataProvider class, as well as the relevant MS SQL stored procedure would have to be

updated to save this new property to the ModuleDefinitions Table.

In addition a new UpdateModuleDefinition would need to be added in order to update

the DefaultCacheTime property, as there is no method/Stored Procedure to do this.

CREATE procedure {databaseOwner}{objectQualifier}UpdateModuleDefinition @DesktopModuleId int, @FriendlyName nvarchar(128), @DefaultCacheTime int as update {objectQualifier}ModuleDefinitions SET FriendlyName = @FriendlyName, DefaultCacheTime = @DefaultCacheTime WHERE DesktopModuleId = @DesktopModuleId GO

PA Installer/Packager:

It is not intended for the Module Developer to set this property – it is provided to allow

the Host user to set a default value for their sites, so there is no implication for the

Installer and Packager.

24



Edit Module Definition UI:

The Edit Module Definition UI currently will need to add support for setting the

DefaultCacheTime property. It will also need to add the ability to Update the currently

selected definition.

<tr> <td class="SubHead" width="150" valign="top"><dnn:label id="plCacheTime" text="Default Cache Time:" controlname="txtCacheTime" runat="server" /></td> <td> <asp:textbox id="txtCacheTime" cssclass="NormalTextBox" width="290px" columns="30" maxlength="128" runat="server" /> <asp:linkbutton id="cmdUpdateDefinition" resourcekey="cmdUpdateDefinition" text="Update Definition" runat="server" class="CommandButton" borderstyle="none" /> </td> </tr>

In the Code–behind there will need to be a new Event Handler to manage the Update of

the CacheTime, as well as code to load the CacheTime field.

Adding a Module to a Page:

When a module is added to a Page, using one of the existing Control Panel controls, the

Module’s CacheTime property is set to 0. With this enhancement the property needs to

be set to the DefaultCacheTime: eg in the AddModule_Click Event Handler of the

IconBar class, or the cmdAdd_Click Event Handler of the Classic class.

Old: objModule.CacheTime = 0 New: objModule.CacheTime = objModuleDefinition.DefaultCacheTime

25



Additional Information

The DotNetNuke Portal Application Framework is constantly being revised and

improved. To ensure that you have the most recent version of the software and this

document, please visit the DotNetNuke website at:

http://www.dotnetnuke.com

The following additional websites provide helpful information about technologies and

concepts related to DotNetNuke:

DotNetNuke Community Forums

http://www.dotnetnuke.com/tabid/795/Default.aspx

Microsoft® ASP.Net

http://www.asp.net

Open Source

http://www.opensource.org/

W3C Cascading Style Sheets, level 1

http://www.w3.org/TR/CSS1

Errors and Omissions

If you discover any errors or omissions in this document, please email

[email protected]. Please provide the title of the document, the page number

of the error and the corrected content along with any additional information that will

help us in correcting the error.

26



Appendix A: Document History

Version Last Update Author(s) Changes

1.0.0 2005 Charles Nurse • Document created

1.0.1 Aug 16, 2005 Shaun Walker • Applied new template

Dot Net Nuke Module Definitions Enhancement

Documents

Transcript of Dot Net Nuke Module Definitions Enhancement