Dot Net Nuke Module Definitions Enhancement

DotNetNuke Module Definitions

Charles Nurse

Version 1.0.1 Last Updated: June 20, 2006 Category: Modules

DotNetNuke Module Definitions

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.

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

DotNetNuke Module Definitions

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.

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

DotNetNuke Module Definitions

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

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

1 DotNetNuke Module Definitions

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

2 DotNetNuke Module Definitions

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

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

3 DotNetNuke Module Definitions

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.

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

4 DotNetNuke Module Definitions

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:
") 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.

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

5 DotNetNuke Module Definitions

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 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 node was added.

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

6 DotNetNuke Module Definitions

From 3.0.11 if both nodes are defined the node is used to define the folder name and the is used to define the FriendlyName field. If the optional node is not present then the 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 and 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 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

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

7 DotNetNuke Module Definitions

Uninstaller both throw exceptions as the resulting paths DesktopModules/Text/HTML and DesktopModules/XML/XSL do not exist.

Overview of Proposed Solution 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 node in the Installer manifest. FolderName will map to a new optional node in the Installer manifest. However, in the absence of this new node then will map to the 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.

Detailed Implications of Proposed Solution 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,

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

8 DotNetNuke Module Definitions

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:

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

9 DotNetNuke Module Definitions

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 : <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

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

10 DotNetNuke Module Definitions

This allows the FolderName to be set to the optionally provided element or to the element if the 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

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

11 DotNetNuke Module Definitions

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.

You must enter a Module Name" controltovalidate="txtModuleName" runat="server" />

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:

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

12 DotNetNuke Module Definitions

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

as this is where the files are located.

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

13 DotNetNuke Module Definitions

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.

Detailed Implications of Proposed Solution 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

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

14 DotNetNuke Module Definitions

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 GO

procedure {databaseOwner}{objectQualifier}GetDesktopModuleByName

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:

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

15 DotNetNuke Module Definitions

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

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

16 DotNetNuke Module Definitions

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.

Detailed Implications of Proposed Solution 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.

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

17 DotNetNuke Module Definitions

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: New Properties and corresponding Private fields would need to be added, eg 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.

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

18 DotNetNuke Module Definitions

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: New Properties and corresponding Private fields would need to be added, eg

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

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

19 DotNetNuke Module Definitions

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:

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

20 DotNetNuke Module Definitions

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

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

21 DotNetNuke Module Definitions

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.

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

22 DotNetNuke Module Definitions

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).

Overview of Proposed Solution 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.

Detailed Implications of Proposed Solution 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

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

23 DotNetNuke Module Definitions

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.

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

24 DotNetNuke Module Definitions

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.

  

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

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

25 DotNetNuke Module Definitions

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.

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

26 DotNetNuke Module Definitions

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

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