Databases Reference
In-Depth Information
web application project. Figure 10.4 shows an example of the Customer edit page gener-
ated with the new field template; Listing 10.11 shows its markup.
FIGURE 10.4 Web page with a custom State field template.
LISTING 10.11 State_Edit Field Template (Markup)
<%@ Control Language=”C#” CodeBehind=”State_Edit.ascx.cs”
Inherits=”WebApplication.DynamicData.FieldTemplates.StateEditField” %>
<asp:DropDownList ID=”dropDownList” runat=”server” />
<asp:RequiredFieldValidator runat=”server” ID=”requiredFieldValidator”
ControlToValidate=”dropDownList” Enabled=”false” />
<asp:DynamicValidator runat=”server” ID=”dynamicValidator”
ControlToValidate=”dropDownList” />
Although this custom field template is built specifically for the Region column, it is still
important to follow the pattern used by the generic field templates and create the
RequiredFieldValidator and DynamicValidator controls to validate values selected by
the users in the DropDownList . You want to keep the business logic out of custom
templates as much as possible. On one hand, this makes implementation of the user
interface easier—simply place the appropriate validators in template markup and let
Dynamic Data take care of the rest. On the other hand, consolidating the business logic
in the data model with data annotations and custom code implemented in your entity
classes helps to keep it maintainable and testable.
As you would expect, most of the heavy lifting in the State_Edit field template is done
in its code-behind, which is shown in Listing 10.12.
LISTING 10.12 State_Edit Field Template (Code-Behind)
using System;
using System.Collections.Specialized;
using System.Web.DynamicData;
Search WWH ::




Custom Search