The DotNetNuke Property Editors - Part 2, Controlling the Behavior with Attributes

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 53 class or enum files that make up the Property Editor suite of controls.

This second article in a series of articles I am writing on this topic, discusses the use of Attributes to control the behavior of the control.

Controlling the Behavior of the Editor with Attributes

In the first article in this series, I described how the editor is loaded and how the data in the editor is retrieved when the Update button is clicked.  But how does the editor know to use a particular control to edit the data for a property and how does it know what properties are required (as identified by the red arrows).  

Using the example from the previous article, the Profile Property Definition Editor shows many of the fields as text boxes, but a drop down combo box (HTML select) is used for the Data Type and checkboxes are used for the Required and Visible properties.  In addition, even the text boxes are not all the same length.

Figure 1: The Profile Property Definition Editor

This behavior is controlled by Attributes. In .NET Attributes can be used to "decorate" a Property providing an extensible set of additional information (or metadata) about a property.  The Property Editor provides a set of custom Attributes that can be used to control the behavior of the PropertyEditorControl (see Figure 2).

Figure 2: PropertyEditor Attributes

For example the IsReadOnlyAttribute can be used to make sure that the property is not editable, while the RequiredAttribute is used to identify a property that must have its value set.

Listing 1 shows the DataType property decorated with 5 Attributes (Note - you can drop the Attribute from the name when applying attributes eg. List = ListAttribute, Editor = EditorAttribute).

   1:  <Editor("DotNetNuke.UI.WebControls.DNNListEditControl, DotNetNuke", _

   2:          GetType(DotNetNuke.UI.WebControls.EditControl)), _

   3:   List("DataType", "", ListBoundField.Id, ListBoundField.Value), _

   4:   IsReadOnly(True), Required(True), SortOrder(1)> _

   5:   <XmlIgnore()> Public Property DataType() As Integer

   6:      Get

   7:          Return _DataType

   8:      End Get

   9:      Set(ByVal Value As Integer)

  10:          If _DataType <> Value Then _IsDirty = True

  11:          _DataType = Value

  12:      End Set

  13:  End Property

• Editor - allows you to control the EditControl used to edit the field.  If not defined the PropertyEditor uses the default (TextBox) 
• List -as the Edit Control defined is a List, this attribute provides the details on how to get the options List.
• IsReadOnly - if the field has a value, ie. it is being edited rather than created, then this property is readonly
• Required - the user must provide a value - this will trigger validation as well as display the red arrow icon
• SortOrder - the order of the property in the display (0-order) - the DataType will displayed as the 2nd row in the control.

The other attributes provided, that were not used in this example are:

• Browsable - this is provided by the .NET Framework, and is used in the Property Editor to control whether a property is displayed (the default is true)
• ControlStyle - allows you to define the style to use for displaying the EditControl
• LabelMode - allows you to control the position of the label
• MaxLength - allows you to control the maximum length of a text box
• RegularExpressionValidator - allows you to control the validation of a text box field (for instance this could be used to ensure that the data entered was a valid email address)

All attributes attached to the property are passed to the EditControl during data-binding, so if you develop a custom EditControl for your own custom Info class you can also create and use your own attribute, to control the behavior of the EditControl.

One of the issues with using Attributes on the property, as hints to the Control on how to display its content is that it hard-codes the design and mixes it with the data model.  In the next article I will describe an alternative method to control the behavior of the control, one that separates the Design from the Structure.