The DotNetNuke Property Editors - Part 3, Using the Fields Collection

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)

   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

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.