Создание динамического пользовательского интерфейса ASP.NET, управляемого данными - Использование правил валидации для специализированных клиентских атрибутов

ОГЛАВЛЕНИЕ

Использование правил валидации для специализированных клиентских атрибутов

Таблица DynamicAttributesForClients содержит запись для каждого специализированного клиентского атрибута, указанного в системе. Каждый специализированный клиентский атрибут должен, как минимум, выражать то, с каким пользователем ассоциирован клиентский атрибут, тип данных (String, Date и т.д.) и название специализированного клиентского атрибута. Таблица DynamicAttributesForClients содержит колонки для данных полей, а также колонку SortOrder, которая дает пользователю возможность указать порядок отображения специализированных атрибутов во время работы с ними в ~/Customers/ClientCustomAttributes.aspx.

Указывая специализированные клиентские атрибуты, пользователь (юридическая компания) наверняка захочет добавить правила валидации. К примеру, когда компания, специализирующаяся на личном ущербе, указывает атрибут с названием Date Injured (Дата нанесения ущерба) типа Date , то наверняка понадобится указать то, что данное значение является обязательным и должно быть равно или больше текущей даты. Данные правила валидации могут быть указаны посредством дополнительной колонки в таблице DynamicAttributesForClients , и затем реализованы в качестве динамически-добавленных веб-элементов валидации ~/Customers/ClientCustomAttributes.aspx. Чтобы продемонстрировать это мы добавим данную функциональность в приложение, созданное в третьей части, поэтому пользователи смогут в качестве опции отметить атрибут как обязательный.

Давайте начнем с того, что добавим новую колонку к таблице DynamicAttributesForClients названную Required и имеющую тип данных bit , который не позволяет значения NULL и имеет условное значение, равное 0. Далее откройте страницу ~/Customers/DefineClientAttributes.aspx в Visual Studio. Если помните, данная страница используется пользователем для того, чтобы указывать специализированные клиентские атрибуты. Обновите страницу таким образом, чтобы она включала в себя новую колонку Required. Следующее изображение демонстрирует страницу после того, как были обновлены элементы управления DetailsView, GridView и SqlDataSource. Как вы видите, я отметил специализированные атрибуты Birthdate (Дата рождения) , Married (Брак) и Reason for Law Suit (Причина иска) как обязательные, при этом атрибуты Employed (Нанят) и Number of Years at Current Job (Количество лет на данной позиции) как опциональные.

Обратите внимание на то, что из данного интерфейса я могу отметить отмеить атрибуты типа Boolean как обязательные (к примеру, Married). Тем не менее, поскольку наш пользовательский интерфейс использует CheckBox для атрибутов типа Boolean , то принцип "обязательности" не имеет особого смысла. У вас не может быть "обязательного" CheckBox для элементов типа Boolean, которые сами по себе уже представлены элементом Checkbox. Поэтому, вы наверняка захотите улучшить пользовательский интерфейс в ~/Customers/DefineClientAttributes.aspx таким образом, чтобы GridView прятал элемент CheckBox для атрибутов типа Boolean. Но это я оставлю на усмотрение читателя.

Последним шагом тут будет обновление кода, который генерирует динамический пользовательский интерфейс, управляемый данными, таким образом, чтобы он включал в себя веб-элементы управления валидацией, необходимые для данных специализированных атрибутов. Вспомните, что веб-элементы управления, которые динамически добавляются к странице ~/Customers/ClientCustomAttributes.aspx, добавляются в методе CreateCustomAttributeUI. Данный метод добавляет элемент TextBox с множеством строк для специализированных атрибутов типа String, элемент CheckBox - для атрибутов типа Boolean и т.д. Нам необходимо обновить данный метод таким образом, чтобы он добавлял RequiredFieldValidator в иерархию элементов управления для каждого обязательного специализированного атрибута.

Добавление RequiredFieldValidator к необходимым специализированным атрибутам - несложная процедура. Начните с расширения метода CreateCustomAttributeUI таким образом, чтобы он принимал новый входной параметр типа Boolean, названный AttributeRequired. (Вам понадобится обновить код в обработчике события Page_Init таким образом, чтобы он получал значения колонки Required наряду с другими колонками из таблицы DynamicAttributesForClients, а также передавал данное значение в метод CreateCustomAttributeUI посредством метода AddCustomAttribute.) Следующий кусок кода добавляет RequiredFieldValidator:

'Добавление RequiredFieldValidator при необходимости
If AttributeRequired Then
   ctrls.Add(CreateRequiredFieldValidator(DynamicAttributeId, "Required field."))
End If 

Данный метод вызывает метод CreateRequiredFieldValidator (предоставленный ниже) и присоединяет его к набору элемента управления, добавляемого к иерархии элементов управления страницы. Метод CreateRequiredFieldValidator создает новый экземпляр RequiredFieldValidator, устанавливает соответствующие свойства и возвращает объект элемента управления валидацией.

Private Function CreateRequiredFieldValidator(ByVal DynamicAttributeId As Guid, ByVal ErrorMessage As String) As RequiredFieldValidator
   Dim rfv As New RequiredFieldValidator
   rfv.ID = "ReqVal_" & GetID(DynamicAttributeId)
   rfv.ControlToValidate = GetID(DynamicAttributeId)
   rfv.Display = ValidatorDisplay.Dynamic
   rfv.ErrorMessage = ErrorMessage

   Return rfv
End Function 

Обратите внимание на то, что RequiredFieldValidator не может быть добавлен к CheckBox. Поэтому, мы не хотим добавлять RequiredFieldValidator в случае, когда мы имеем дело с элементом типа Boolean. Если вы загрузите пример, доступный в конце статьи, и исследуете код метода CreateCustomAttributeUI то вы найдете там код If AttributeRequired Then..., который встречается в каждом блоке Case для всех типов данных, кроме Boolean.

Следующее изображение демонстрирует в действии элемент управления RequiredFieldValidator. Заметьте, если пользователь опустит поля Birthdate или Reason for Law Suit , то будет выведено предупреждение и форма не будет выслана.


Данный принцип определения и реализации обязательного правила валидации может быть применен для создания других правил.