This blog was originally posted on my dotnetnuke.com Blog. It has been updated and edited.

Michael Washington in a blog about updating his DotNetNuke sites made reference to the fact that you no longer need to manually modify your web.config settings prior to upgrading a site.

Why is this?  The answer is a new class that was introduced into the core (in DotNetNuke version 4.6.0) called XmlMerge.  This class is designed to allow developers to create xml files that can be used to "update" one or more of the core "config" files, and is especially useful for upgrades and component installations.

We have had the ability for some time to provide file-cleanup files - these files are named xx.xx.xx.txt and contain a list of folders and files to delete when upgrading to version xx.xx.xx.  This allows us to remove unnecessary files from production sites.  Starting in version 4.6.0 we added the ability to add a "xx.xx.xx.config" file which contained the changes required to "upgrade" a core config file.

Rather than try and explain - lets look at an example. The 4.6.0.config file:

Listing 1: 04.06.00.config file
   1:  <configuration>
   2:    <nodes configfile="web.config">
   3:      <node path="/configuration/system.web/httpModules" action="update" key="name" 
                 collision="overwrite">
   4:        <add name="Compression" type="DotNetNuke.HttpModules.Compression.CompressionModule, 
DotNetNuke.HttpModules"
/>
   5:        <add name="RequestFilter" type="DotNetNuke.HttpModules.RequestFilter.RequestFilterModule, 
DotNetNuke.HttpModules"
/>
   6:        <add name="UrlRewrite" type="DotNetNuke.HttpModules.UrlRewriteModule, 
DotNetNuke.HttpModules"
/>
   7:        <add name="Exception" type="DotNetNuke.HttpModules.Exceptions.ExceptionModule, 
DotNetNuke.HttpModules"
/>
   8:        <add name="UsersOnline" type="DotNetNuke.HttpModules.UsersOnline.UsersOnlineModule, 
DotNetNuke.HttpModules"
/>
   9:        <add name="DNNMembership" type="DotNetNuke.HttpModules.Membership.MembershipModule, 
DotNetNuke.HttpModules"
/>
  10:        <add name="Personalization" 
type="DotNetNuke.HttpModules.Personalization.PersonalizationModule,
DotNetNuke.HttpModules"
/>
  11:      </node>
  12:      <node path="/configuration/dotnetnuke/friendlyUrl/providers" action="update" key="name" 
collision="overwrite">
  13:        <add name="DNNFriendlyUrl"
  14:             type="DotNetNuke.Services.Url.FriendlyUrl.DNNFriendlyUrlProvider, 
DotNetNuke.HttpModules"
  15:             includePageName="true"
  16:             regexMatch="[^a-zA-Z0-9 _-]" />
  17:      </node>
  18:    </nodes>
  19:  </configuration>

In version 4.6 - the HttpModules were all merged into a single assembly - the web.config file therefore needed to be updated to reflect this.  In this config file - there are two "node" elements which are the building blocks of the XmlMerge file.  The attributes tell the XmlMerge class how to deal with the content inside the node. 

So for the first node we have:

  • path="/configuration/system.web/httpModules" - this is an Xpath path that identifies the node being modified in the target file - in this case the "httpModules" element in the system.web element of the configuration
  • action="update" - this is the action - in this case the existing element is being "updated".  Other values for action are add, insertbefore, insertafter, remove, removeattribute, updateattribute.
  • key="name"  - this is the key to use - in this case "name" - the XmlMerge class will identify the child nodes to change by matching the name attribute "Compression", "Exception etc.
  • collision="overwrite" - this is the behaviour to use if the child node exists - in this case the old entry will be overwritten by the new one

The target file is "web.config" as identified by the configfile attribute on the outer nodes element.  

Note - in this scenario if the end user has added additional HttpModules these are unaffected by the "merge" - only the named child nodes are replaced.

During the install/upgrade, the DotNetNuke core installer calls the UpdateConfig method for each version (see Listing 2).  This method checks that the file exists, creates an instance of the XmlMerge class and calls the UpdateConfig() method.  Finally the StreamReader is closed to release the file systems lock on the file.

Listing 2: UpdateConfig method
   1:  Private Shared Function UpdateConfig(ByVal strVersion As String) As String
   2:      Dim strExceptions As String = ""
   3:   
   4:      Try
   5:          Dim strConfigFile As String = DotNetNuke.Common.HostMapPath & strVersion & ".config"
   6:   
   7:          If File.Exists(strConfigFile) Then
   8:              'Create XmlMerge instance from config file source
   9:              Dim stream As StreamReader = File.OpenText(strConfigFile)
  10:              Dim merge As XmlMerge = New XmlMerge(stream, strVersion, "Core Upgrade")
  11:   
  12:              'Process merge
  13:              merge.UpdateConfigs()
  14:   
  15:              'Close stream
  16:              stream.Close()
  17:          End If
  18:   
  19:      Catch ex As Exception
  20:          strExceptions += "Error: " & ex.Message & vbCrLf
  21:      End Try
  22:   
  23:      Return strExceptions
  24:  End Function

In addition to using this in the core Installer/Upgrader - the new "Universal Extension Installer" that will be included in DotNetNuke 5.0 supports this ability too.  Again - as an example lets look at a fragment of a manifest from the new installer (see Listing 3).

Listing 3: BroadcastPollingCachingProvider Manifest
   1:  <component type="Config">
   2:    <config>
   3:      <configFile>web.config</configFile>
   4:      <install>
   5:        <configuration>
   6:          <nodes>
   7:            <node path="/configuration/dotnetnuke/caching/providers" action="update" key="name" 
   8:                  collision="overwrite">
   9:              <add name="BroadcastPollingCachingProvider"
  10:                   type="DotNetNuke.Services.Cache.BroadcastPollingCachingProvider.BPCachingProvider, 
  11:                         DotNetNuke.Caching.BroadcastPollingCachingProvider"
  12:                   providerPath="~\Providers\CachingProviders\BroadcastPollingCachingProvider\" />
  13:            </node>
  14:          </nodes>
  15:        </configuration>
  16:      </install>
  17:      <uninstall>
  18:        <configuration>
  19:          <nodes>
  20:            <node path="/configuration/dotnetnuke/caching/providers/add[@name=
  21:                                                 'BroadcastPollingCachingProvider']" 
  22:                  action="remove" />
  23:          </nodes>
  24:        </configuration>
  25:      </uninstall>
  26:    </config>
  27:  </component>

In this example (part of the manifest for installing the BroadcastPollingCachingProvider) you can see that the manifest defines a "config" element - which tells the Installer that we are "updating" a config file - in this case web.config.  It has two separate sections that correspond to the same basic structure as the XmlMerge file above, one for installing the provider - with a similar set of attributes, and one for uninstalling, which shows how you would remove a section of the config file.

A full description of the XmlMerge API is beyond the scope of this blog post, but if you want to start learning how to use this in your own modules/extensions - I would suggest that you look for the "XmlMerge.vb" file in the DotNetNuke project source - the main entry points are the "UpdateConfig" methods.


Posted in: DotNetNuke  Tags:

This article is based on material originally published on DNN Developer Zone (www.dnndevzone.com).  This version has been edited slightly.

Introduction

Version 4.3 of the DotNetNuke Web Application Framework introduced a suite of Property Editors. These Property Editors dynamically inject the appropriate Edit Control depending on the Data Type to be edited. There are 5 types of editor and 47 class or enum files that make up the Property Editor suite of controls. Previous articles in this series introduced the Property Editors. This article introduces the 14 EditControls included with the core distribution. Future articles in this series will describe how to create your own EditControl.

The Abstract EditControl

Figure 1: The Abstract EditControl Base Class
EditControl  

Figure 1 shows the definition of the abstract base class EditControl. Every EditControl used by the Property Editors is derived from this base class.

Lets take a look at this abstract class. There are 9 Properties in this class and one abstract Property (StringValue).

  • CustomAttributes - An array of Attributes that can be used by the derived classes to add customisation (for instance the DNNListEditControl uses the Attributes collection to determine which list to display).
  • EditMode - Determines whether the control is in Edit or View mode.
  • LocalResourceFile - This property is used by the EditControl to reference the current LocalResourceFile.
  • Name - The name of the property being edited.
  • OldValue - the old value of the property.
  • Required - whether the property is required (used by drop-down lists to determine whether to add a < None Specified > option).
  • StringValue - the Value expressed as a String , each derived class must override this property.
  • SystemType - the underlying System.Type of the value of this control.
  • Value - the value of the property.

The abstract class also defines a number of protected methods. Three methods control the rendering process.

  • Render - the Render method is called by the .NET Framework at Render time and this method calls RenderEditMode or RenderViewMode to render the control, based on the value of the EditMode property.
  • RenderViewMode - this method renders the control when the EditMode is set to View, as is the case in "View Profile" .
  • RenderEditMode - this method renders the control when the EditMode is set to Edit, as is the case when editing a Profile. This method is shown in Listing 1 below.

 

 

 

Listing 1: The RenderEditMode method
   1:  Protected Overridable Sub RenderEditMode(ByVal writer As HtmlTextWriter)
   2:      Dim propValue As String = CType(Me.Value, String)
   3:      ControlStyle.AddAttributesToRender(writer)
   4:      writer.AddAttribute(HtmlTextWriterAttribute.Type, "text")
   5:      writer.AddAttribute(HtmlTextWriterAttribute.Value, propValue)
   6:      writer.AddAttribute(HtmlTextWriterAttribute.Name, Me.UniqueID)
   7:      writer.RenderBeginTag(HtmlTextWriterTag.Input)
   8:      writer.RenderEndTag()
   9:  End Sub

These methods provide a default implementation that is called if the derived class does not provide its own rendering methods. Later in this article we will show how a derived EditControl overrides these methods. In the abstract base class a text box is rendered (an XHTML <input /> tag), the value is set to the value of the property, and the name is set to the UniqueID of the control. This last value is very important, as it is used by the .NET Framework to identify the control on PostBack.

IPostBackDataHandler Interface

If you look at Figure 1 you will see that the EditControl class implements the IPostBackDataHandler Interface. This interface provides two methods that are called automatically by the .NET Framework LoadPostData (see Listing 2) and RaisePostDataChangedEvent (see Listing 3)

Listing 2: LoadPostData method
   1:  Public Overridable Function LoadPostData(ByVal postDataKey As String, _ 
ByVal
postCollection As NameValueCollection) As Boolean
   2:      Dim dataChanged As Boolean = False
   3:      Dim presentValue As String = CStr(Value)
   4:      Dim postedValue As String = postCollection(postDataKey)
   5:      If Not presentValue.Equals(postedValue) Then
   6:          Value = postedValue
   7:          dataChanged = True
   8:      End If
   9:      Return dataChanged
  10:  End Function

The LoadPostData method is called by the .NET Framework for any Control that implements IPostBackDataHandler. It is called just after the View State is loaded (LoadViewState) and just before the Load phase of the Control Life Cycle. The postCollection represents all the name/value pairs returned to the Server by the PostBack, and the postDataKey is the key for the current control. (Remember above when I said the UniqueID was rendered to the Name attribute of the <input/> tag). The LoadPostData method returns a boolean that lets the Framework know whether the data was changed since it was rendered.

Listing 3: The RaisePostDataChangedEvent method
   1:  Public Sub RaisePostDataChangedEvent()
   2:      'Raise the DataChanged Event
   3:      OnDataChanged(System.EventArgs.Empty)
   4:  End Sub

Once the Load phase is complete, the .NET Framework then calls the RaisePostDataChangedEvent for every control that had previously reported that their data had changed. This allows the control to raise an event indicating its value has changed, In our case the RaisePostDataChangedEvent method calls the abstract OnDataChanged method. An abstract must be implemented in the derived class, and when the RaisePostDataChangedEvent calls the OnDataChanged method it actually calls the derived classes version, so the derived class can determine what to do next.

The base class also provides the ValueChanged event and associated OnValueChanged method (see Listing 4)

Listing 4: The Value Changed Event and the OnValueChanged Method
   1:  Public Event ValueChanged As PropertyChangedEventHandler
   2:   
   3:  Protected Overridable Sub OnValueChanged(ByVal e As PropertyEditorEventArgs)
   4:      RaiseEvent ValueChanged(Me, e)
   5:  End Sub
A derived class can use these events to indicated to the Editors that their values have been changed, passing the relevant information in a custom PropertyEditorEventArgs object.
Figure 2: PropertyEditorEventArgs Class
PropertyEditorEventArgs

EditControls included with DotNetNuke 4.3

As mentioned in the Introduction 14 EditControls are included with DotNetNuke (1 abstract base class and 13 derived classes). Figure 3 shows how 9 of the controls derive from the abstract base class. In general the controls can be divided into 4 groups:

  • Text controls - which derive from the TextEditControl
  • Integer controls - which derive from the IntegerEditControl
  • True False controls - either True/False (using radio buttons) or a check Edit Control
  • Lists - derived from DNNListEditControl
Figure 3: Some of the EditControls included in DotNetNuke v4.3.
 EditControls

The TrueFalseEditControl

As an example of a derived EditControl let's look at the TrueFalseEditControl. This control can be used to edit a boolean value using two radio buttons (True and False). As can be seen in Figure 4, this control has three properties and 2 methods.

Figure 4: The TrueFalseEditControl
 TrueFalseEditControl

The StringValue property is abstract in the base class so every derived class must implement this property.

The BooleanValue and OldBooleanValue properties are ReadOnly typed versions of the base classes Value and OldValue properties. They are not neccessary but are provided as helper properites that can be used in the methods of the class and any classes derived from it.

Listing 5: The three properties of the TrueFalseEditControl
   1:  Protected ReadOnly Property BooleanValue() As Boolean
   2:      Get
   3:          Dim boolValue As Boolean = Null.NullBoolean
   4:          Try
   5:              'Try and cast the value to an Boolean
   6:              boolValue = CType(Value, Boolean)
   7:          Catch ex As Exception
   8:          End Try
   9:          Return boolValue
  10:      End Get
  11:  End Property
  12:   
  13:  Protected ReadOnly Property OldBooleanValue() As Boolean
  14:      Get
  15:          Dim boolValue As Boolean = Null.NullBoolean
  16:          Try
  17:              'Try and cast the value to an Boolean
  18:              boolValue = CType(OldValue, Boolean)
  19:          Catch ex As Exception
  20:          End Try
  21:          Return boolValue
  22:      End Get
  23:  End Property
  24:   
  25:  Protected Overrides Property StringValue() As String
  26:      Get
  27:          Return BooleanValue.ToString
  28:      End Get
  29:      Set(ByVal Value As String)
  30:          Dim setValue As Boolean = Boolean.Parse(Value)
  31:          Me.Value = setValue
  32:      End Set
  33:  End Property

The TrueFalseEditControl overrides the RenderEditMode method of the base class as we are using two radio buttons (rather than a text box) to edit the data. This method is shown in Listing 6.

Listing 6: The RenderEditMode method of the TrueFalseEditControl
   1:  Protected Overrides Sub RenderEditMode(ByVal writer As HtmlTextWriter)
   2:      writer.AddAttribute(HtmlTextWriterAttribute.Type, "radio")
   3:      If (BooleanValue) Then
   4:          writer.AddAttribute(HtmlTextWriterAttribute.Checked, "checked")
   5:      End If
   6:      writer.AddAttribute(HtmlTextWriterAttribute.Value, "True")
   7:      writer.AddAttribute(HtmlTextWriterAttribute.Name, Me.UniqueID)
   8:      writer.RenderBeginTag(HtmlTextWriterTag.Input)
   9:      writer.RenderEndTag()
  10:   
  11:      ControlStyle.AddAttributesToRender(writer)
  12:      writer.RenderBeginTag(HtmlTextWriterTag.Span)
  13:      writer.Write("True")
  14:      writer.RenderEndTag()
  15:   
  16:      writer.AddAttribute(HtmlTextWriterAttribute.Type, "radio")
  17:      If (Not BooleanValue) Then
  18:          writer.AddAttribute(HtmlTextWriterAttribute.Checked, "checked")
  19:      End If
  20:      writer.AddAttribute(HtmlTextWriterAttribute.Value, "False")
  21:      writer.AddAttribute(HtmlTextWriterAttribute.Name, Me.UniqueID)
  22:      writer.RenderBeginTag(HtmlTextWriterTag.Input)
  23:      writer.RenderEndTag()
  24:   
  25:      ControlStyle.AddAttributesToRender(writer)
  26:      writer.RenderBeginTag(HtmlTextWriterTag.Span)
  27:      writer.Write("False")
  28:      writer.RenderEndTag()
  29:  End Sub

This is a much more complicated method than the one in the base class (compare with Listing 1), as it needs to render two radio buttons, and make one of them selected (or "checked") depending on the vale of the BooleanValue property. It is important to note also that the name attribute for both buttons is given the same value, the UniqueID property of the EditControl, so that the .NET Framework can correctly identify the control.

As mentioned above the RaisePostDataChangedEvent method of the base class calls the abstract OnDataChanged method, so the TrueFalseEditControl has to provide an implementation of this method. This is shown in Listing 7.

Listing 7: The OnDataChanged method of the TrueFalseEditControl
   1:  Protected Overrides Sub OnDataChanged(ByVal e As EventArgs)
   2:      Dim args As New PropertyEditorEventArgs(Name)
   3:      args.Value = BooleanValue
   4:      args.OldValue = OldBooleanValue
   5:      args.StringValue = StringValue
   6:      MyBase.OnValueChanged(args)
   7:  End Sub

The OnDataChanged method creates a new PropertyEditorEventArgs object, and sets its Value, OldValue and StringValue properties - the Name property is created in the constructor, and the controls Name value is passed as a parameter of the constructor.

This PropertyEditorEventArgs object is then passed to the base classes OnValueChanged method, which raises the ValueChanged event.

As can be seen from this discussion, there really isn't very much to the derived EditControls. In future articles in this series we will show how to develop new Edit Controls, and how to register them in your DotNetNuke installation.


Introduction

Version 4.3 of the DotNetNuke Web Application Framework introduced a suite of Property Editors. These Property Editors dynamically inject the appropriate Edit Control depending on the Data Type to be edited. There are 5 types of editor and 53 class or enum files that make up the Property Editor suite of controls.

This third article in a series of articles I am writing on this topic, discusses the Fields collection and the FieldEditorControl.

Controlling the Behavior of the Editor with the Fields Collection

In Part 2 of this series I described how you can control the behavior of the Editor with Attributes.  There are two issues with this approach:

  1. The behavior is hard-coded.  In a Web Application Project it requires the developer to recompile the project if changes are made to the attributes.
  2. It mixes the design with the model, and does not allow projects to be split up with developers writing the code and designers creating the design.

There is another approach we can use to control the behavior, and this is to use the Fields collection of the PropertyEditorControl.  As mentioned in the first article in this series, the PropertyEditorControl is built from a collection of FieldEditorControl objects. 

If the AutoGenerate property of the PropertyEditorControl is set to true - the control constructs a FieldEditorControl from each property of the object where the Browsable attribute is true.  This is the procedure used in the previous article.  However, if the AutoGenerate property is set to false, then the Fields collection must be explicitly specified.  This is analogous to the ASP.NET DataGrid which has a Columns collection, which is auto-generated if the AutoGenerate property is set to true, but which requires the designer to add columns explicitly when the AutoGenerate attribute is set to false..

Lets look at the same example from the DotNetNuke Profile Definition Editor to see how we would redefine the editor to use this approach (Listing 1)

Listing 1 - The PropertyEditorControl Declaration using AutoGenerate=false
   1:  <dnn:propertyeditorcontrol id="Properties" runat="Server"
   2:      AutoGenerate="false"
   3:      SortMode="SortOrderAttribute"
   4:      ErrorStyle-cssclass="NormalRed"
   5:      labelstyle-cssclass="SubHead" 
   6:      helpstyle-cssclass="Help" 
   7:      editcontrolstyle-cssclass="NormalTextBox" 
   8:      labelwidth="180px" 
   9:      editcontrolwidth="170px" 
  10:      width="350px">
  11:      <Fields>
  12:          <dnn:FieldEditorControl ID="ctl1" runat="server" DataField="PropertyName" 
  13:              Required="true" EditMode="View" />
  14:          <dnn:FieldEditorControl ID="ctl2" runat="server" DataField="DataType" 
  15:              Required="true" EditMode="View"
  16:              EditorTypeName="DotNetNuke.UI.WebControls.DNNListEditControl, DotNetNuke" />
  17:          <dnn:FieldEditorControl ID="ctl3" runat="server" DataField="PropertyCategory" 
  18:              Required="true" />
  19:          <dnn:FieldEditorControl ID="ctl4" runat="server" DataField="Length" />
  20:          <dnn:FieldEditorControl ID="ctl5" runat="server" DataField="DefaultValue" />
  21:          <dnn:FieldEditorControl ID="ctl6" runat="server" DataField="ValidationExpression" />
  22:          <dnn:FieldEditorControl ID="ctl7" runat="server" DataField="Required" />
  23:          <dnn:FieldEditorControl ID="ctl8" runat="server" DataField="Visible" />
  24:          <dnn:FieldEditorControl ID="ctl9" runat="server" DataField="ViewOrder" 
  25:              Required="true" />
  26:      </Fields>
  27:  </dnn:propertyeditorcontrol>

The mark-up in Listing 1 is longer than in the previous article, but in compensation there are no longer any attributes in the ProfilePropertyDefinition class.

The resulting Edit page is essentially the same.

Figure 1: The Profile Property Edit Page
AddProfileProperty2

The only major difference is that the editor for the Data Type is not correct.  This is because the FieldEditorControl does not expose the Attributes collection and there is no way to configure the list so the drop-down combo's Text and Value properties are correct.  This can be done through code in the code-behind but it does demonstrate one limitation of this approach.

Manipulating the Fields and the child Edit Controls in the code file will be the topic of a future article in this series.


Posted in: DotNetNuke  Tags:

 Search Blog

 Calendar

«  February 2012  »
MoTuWeThFrSaSu
303112345
6789101112
13141516171819
20212223242526
2728291234
567891011
View posts in large calendar

 Tags

Disclaimer
The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.

© Copyright 2012 Thoughts from the Wet Coast