ASP.NET. Заметки ненатуралиста

[dil]

Покопался немножко в ASP.NET. Совсем чуть-чуть. Что я могу сказать.. Идея отделить веб-представление от кода - замечательная. Потому что куски html, перемешанные с серверным кодом на jscript/vb/php/ещё чём-нибудь - это ужасно, за это надо сразу расстреливать через повешение с пожизненным лишением права программировать.

Идея замечательная.. Но всё, что вы делаете руками реализация местами убивает напрочь.

Приделываете вы, скажем, к форме валидатор какого-нибудь поля. На нём английским по белому написано runat="server". И можете по наивности подумать, что обрабатываться он будет на сервере. Агащазблин, размечтались. То есть, на сервере он тоже будет, и это правильно.

Но - в дополнение к этому он _иногда_ может обрабатываться и на клиенте. Клиентским джавскриптом, который встраивается высокоинтеллектуальным движком ASP.NET в отдаваемую клиенту html-страницу. Если движок сочтет, что клиентский браузер достаточно умён для обработки этого джаваскрипта. А если недостаточно - то форма будет каждый раз отправляться на сервер и проверяться там.

Не, вообще говоря, предварительная проверка на клиенте - это правильно, чтоб лишний раз не гонять форму туда-обратно. Но. В результате валидация формы работает то так, то эдак.

Например, приделали вы к одному управляющему элементу CustomValidator, который работает только на сервере, а к трём другим стандартные, который работают и на сервере, и на клиенте. Ошибки от последних трёх элементов вы получите сразу, а от первого - ТОЛЬКО после правильного заполнения остальных трёх. Потому что пока вы их правильно не заполните, форма на сервер вообще не отправится, и обработчик CustomValidator'а не запустится.

Это если высокоинтеллектуальный ASP.NET решит, что ваш браузер достаточно умён. А если нет, то форма сразу отправится на сервер и там сработают сразу все четыре валидатора.
Этот искусственный интеллект движка можно отключить, однако ж по умолчанию он включён.

Далее. Обработчик CustomValidator'а не вызывается, если в поле ничего не ввести. Ну действительно, фигня какая, раз не заполнили - значит, это ненужное поле какое-то, чего его проверять-то..
И это не баг, это вполне документированная фича такая.

Конечно, существует обходной манёвр - не указывать валидатору, какое поле он валидирует. Тогда его обработчик вызывается всегда, а уже внутри там можно явно вынимать данные из нужных управляющих элементов.

Или можно приделать к полю дополнительный валидатор - RequiredFieldValidator. Который, кстати, проверяет поле вовсе не на непустоту, а на отличие от первоначального значения.
Оно работает, но по-моему, при наличии специально написанного программистом CustomValidator'а такой способ сильно отдаёт ненатурализмом.

В общем, хотели, как лучше..

Comments

[zarr.livejournal.com]

> при наличии специально написанного программистом CustomValidator'а такой способ сильно отдаёт ненатурализмом.

Очень даже наоборот. Все-таки кастомвалидатор не для того, чтобы вручную туда все проверки записать, а для того, чтобы занести туда те, которые в штатные проверки не влазят. Пример использования в мсдне, как раз показывает, как для одного контрола используется реквайред и регэксп валидаторы.

[dil.livejournal.com]

у меня сложилось ощущение, что это сделано исключительно для совместимости со стандартными валидаторами. они занимаются своими узкоспециальными и заранее определёнными проверками, вот в этих узкоспециальных случаях их обработчики и вызываются.

а кастомный валидатор - он общего назначения, используется, когда функциональности стандартных не хватает, и чтО он проверяет - известно только его автору.
поэтому с моей точки зрения было бы логично его обработчик вызывать всегда, а дальше программист пусть сам думает, что и как делать.

[dil.livejournal.com]

то есть, asp.net _вынуждает_ программиста использовать стандартные валидаторы в дополнение к кастомному, вместо того, чтобы реализовать все проверки в одном месте удобным для программиста способом.

[zarr.livejournal.com]

Это больше философские вопросы.
1. Если поле является обязательным и оно не заполнено, то какие еще проверки предполагаются?
2. Реализовать проверки в одном месте это хорошо. Но стандартизация - надежнее. То есть, по мне лучше, когда за проверку обязательности отвечает один и тот же код, а не пятьсот кусочков разбросанных по проекту.

Ну и повторюсь, если рассматривать кастомный валидатор как дополнение - то все правильно, если как замену - то да, возникают вопросы.

[dil.livejournal.com]

с точки зрения чистой философии проверять свойство объекта (обязательность поля) по наличию отдельной от этого объекта сущности (валидатора), на которую сам объект не ссылается - нелогично :)

вот, я понял, чтО мне не нравится в этой истории.
1) некоторые равнее других (RequiredFieldValidator вызывается всегда, если он есть, а остальные не всегда). а в документации это нигде не подчеркивается
2) система содержит жесткую логику _условного_ вызова валидаторов (все остальные валидаторы вызываются только если поле поменялось) и не позволяет программисту её изменить.
раз уж программист лишён возможности определить условия и порядок вызова валидаторов, то их надо вызывать всегда. ну хотя бы кастомные

конечно, существующая схема тоже имеет право на существование, но вот если б всё это было ещё явно описано, а не обнаруживалось путём наступания на грабли, было бы совсем здорово

[zarr.livejournal.com]

> с точки зрения чистой философии проверять свойство объекта (обязательность поля) по наличию отдельной от этого объекта сущности (валидатора), на которую сам объект не ссылается - нелогично :)

Согласен. Не знаю с чем связано, но мне думается, что не в последнюю очередь с самой убогостью веба.

> вот если б всё это было ещё явно описано

Опять же консенсус. :)

[blacklion.livejournal.com]

2. Реализовать проверки в одном месте это хорошо. Но стандартизация - надежнее. То есть, по мне лучше, когда за проверку обязательности отвечает один и тот же код, а не пятьсот кусочков разбросанных по проекту.
+1. Мне тоже какжется естественным навешивать цепочки валидаторов, каждый для своей узкой задачи. UNIX-way :)

[dil.livejournal.com]

я бы не возражал, если бы существовала возможность управлять вызовом этих валидаторов и порядком вызовов

[blacklion.livejournal.com]

Да, это упущение…