Post on 11-Apr-2015
transcript
DotNetNuke Module Definitions
Charles Nurse
Version 1.0.1
Last Updated: June 20, 2006
Category: Modules
DotNetNuke Module Definitions
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.
DotNetNuke Module Definitions
Copyright © 2003-2005 Perpetual Motion Interactive Systems, Inc. All Rights Reserved.
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.
DotNetNuke Module Definitions
Copyright © 2003-2005 Perpetual Motion Interactive Systems, Inc. All Rights Reserved.
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
DotNetNuke Module Definitions
Copyright © 2003-2005 Perpetual Motion Interactive Systems, Inc. All Rights Reserved.
2
DotNetNuke Module Definitions
Copyright © 2003-2005 Perpetual Motion Interactive Systems, Inc. All Rights Reserved.
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
DotNetNuke Module Definitions
Copyright © 2003-2005 Perpetual Motion Interactive Systems, Inc. All Rights Reserved.
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
DotNetNuke Module Definitions
Copyright © 2003-2005 Perpetual Motion Interactive Systems, Inc. All Rights Reserved.
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
DotNetNuke Module Definitions
Copyright © 2003-2005 Perpetual Motion Interactive Systems, Inc. All Rights Reserved.
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
DotNetNuke Module Definitions
Copyright © 2003-2005 Perpetual Motion Interactive Systems, Inc. All Rights Reserved.
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
DotNetNuke Module Definitions
Copyright © 2003-2005 Perpetual Motion Interactive Systems, Inc. All Rights Reserved.
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 <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.
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,
8
DotNetNuke Module Definitions
Copyright © 2003-2005 Perpetual Motion Interactive Systems, Inc. All Rights Reserved.
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
DotNetNuke Module Definitions
Copyright © 2003-2005 Perpetual Motion Interactive Systems, Inc. All Rights Reserved.
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
DotNetNuke Module Definitions
Copyright © 2003-2005 Perpetual Motion Interactive Systems, Inc. All Rights Reserved.
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
DotNetNuke Module Definitions
Copyright © 2003-2005 Perpetual Motion Interactive Systems, Inc. All Rights Reserved.
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
DotNetNuke Module Definitions
Copyright © 2003-2005 Perpetual Motion Interactive Systems, Inc. All Rights Reserved.
Dim strRoot As String = Request.MapPath("~/DesktopModules/" & txtFolderName.Text) & "\"
as this is where the files are located.
13
DotNetNuke Module Definitions
Copyright © 2003-2005 Perpetual Motion Interactive Systems, Inc. All Rights Reserved.
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
14
DotNetNuke Module Definitions
Copyright © 2003-2005 Perpetual Motion Interactive Systems, Inc. All Rights Reserved.
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
DotNetNuke Module Definitions
Copyright © 2003-2005 Perpetual Motion Interactive Systems, Inc. All Rights Reserved.
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
DotNetNuke Module Definitions
Copyright © 2003-2005 Perpetual Motion Interactive Systems, Inc. All Rights Reserved.
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.
17
DotNetNuke Module Definitions
Copyright © 2003-2005 Perpetual Motion Interactive Systems, Inc. All Rights Reserved.
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.
18
DotNetNuke Module Definitions
Copyright © 2003-2005 Perpetual Motion Interactive Systems, Inc. All Rights Reserved.
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
19
DotNetNuke Module Definitions
Copyright © 2003-2005 Perpetual Motion Interactive Systems, Inc. All Rights Reserved.
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
DotNetNuke Module Definitions
Copyright © 2003-2005 Perpetual Motion Interactive Systems, Inc. All Rights Reserved.
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
DotNetNuke Module Definitions
Copyright © 2003-2005 Perpetual Motion Interactive Systems, Inc. All Rights Reserved.
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
DotNetNuke Module Definitions
Copyright © 2003-2005 Perpetual Motion Interactive Systems, Inc. All Rights Reserved.
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
23
DotNetNuke Module Definitions
Copyright © 2003-2005 Perpetual Motion Interactive Systems, Inc. All Rights Reserved.
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
DotNetNuke Module Definitions
Copyright © 2003-2005 Perpetual Motion Interactive Systems, Inc. All Rights Reserved.
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
DotNetNuke Module Definitions
Copyright © 2003-2005 Perpetual Motion Interactive Systems, Inc. All Rights Reserved.
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
marketing@dotnetnuke.com. 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
DotNetNuke Module Definitions
Copyright © 2003-2005 Perpetual Motion Interactive Systems, Inc. All Rights Reserved.
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