Databases Reference
In-Depth Information
section, you could have used the following method to handle the
Load
event of the
Address
control in this custom Customer entity template:
protected void Address_Load(object source, EventArgs e)
{
var addressControl = (DynamicControl)source;
var template = (FieldTemplateUserControl)addressControl.
FieldTemplate
;
var addressTextBox = (TextBox)template.
DataControl
;
addressTextBox.Columns = 65;
}
Given an instance of the
DynamicControl
, you can access the field template it creates via
its
FieldTemplate
property. Unfortunately, this property is of type
Control
, so you must
downcast the value it returns to the
FieldTemplateUserControl
class to access the
DataControl
property, which returns the actual
TextBox
that displays the address. Having
located the actual data control, you can programmatically configure any of its properties,
such as the
Columns
property used in this example.
The declarative and programmatic approaches of configuring field templates have differ-
ent tradeoffs. The declarative approach requires you to modify each field template to
expose the properties you need to configure in entity templates. However, when the prop-
erties are defined, their use in template markup is more concise. Unfortunately, neither
Visual Studio nor ASP.NET runtime warns you if you mistype or try setting a non-existent
field template property as a custom attribute of
DynamicControl
. Custom attributes that
do not match field template properties are silently ignored.
The programmatic approach requires no changes to the field templates but more code for
each customization. It also has negative impact on the page size by unnecessarily increas-
ing the size of field template's
ViewState
. Finally, by accessing the data control directly
instead of a specific property exposed by the field template, you might be breaking its
internal assumptions, which can have unexpected side effects when the implementation
of the field template changes.
Suppose you have a requirement to allow users entering Customer information to select
State values from a drop-down list. In the sample data model, State values are stored as
strings in the Region column of the Customers table. Based on this information, Dynamic
Data chooses the
Text_Edit
field template for this column and displays a simple
TextBox
control, which is not what you need. Although the
ForeignKey_Edit
field template looks
promising, as it creates a
DropDownList
control, it requires a foreign key column referenc-
ing a lookup table, which you do not have in the data model.
When functionality of the available built-in field templates is not sufficient, you can
create a
custom
field template to meet your requirements. In the sample project, a custom
field template called
State_Edit
was added to the
DynamicData\FieldTemplates
of the