Building Custom Forms - ASP.NET Dynamic Data - page 312

LISTING 10.2 Continued
<label>State:</label>
<asp:DynamicControl runat=”server” DataField=”Region”
OnInit=”DynamicControl_Init” />
<label>Zip:</label>
<asp:DynamicControl runat=”server” DataField=”PostalCode”
OnInit=”DynamicControl_Init” />
</fieldset>
Notice how instead of specifying the Mode property for each DynamicControl in the
markup, a method called DynamicControl_Init is used to handle the Init events of all
DynamicControl instances. Listing 10.3 shows the code-behind where this method is
defined. The DynamicControl_Init method relies on its first argument, sender , to deter-
mine which DynamicControl instance needs to be initialized. It then sets the Mode prop-
erty of this control with the value of the Mode property of the entity template itself.
LISTING 10.3 Multimode Customer Entity Template (Code-Behind)
using System;
using System.Web.DynamicData;
namespace WebApplication.DynamicData.EntityTemplates
{
public partial class CustomerEntityTemplate : EntityTemplateUserControl
{
protected void InitDynamicControl(object sender, EventArgs e)
{
var dynamicControl = (DynamicControl)sender;
dynamicControl.Mode = this.Mode;
}
}
}
The new multimode Customers entity template is slightly more complex than the old, Edit
mode entity template that did not require any logic in the code-behind. However, this
approach eliminates the duplication of markup that existed with two separate mode-
specific templates, making creation and maintenance of custom entity templates much
more attractive. There is just one problem—it does not work, not right away.
Dynamic Templates
Unfortunately, the algorithm illustrated in Figure 5.4 that Dynamic Data uses to look up
entity templates chose the dynamic Edit mode template, Default_Edit.ascx , even though
a custom multimode entity template might exist for the Customer entity. It turns out that
the dynamic entity templates suffer from the same code duplication problem as the initial