![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
Покопался немножко в ASP.NET. Совсем чуть-чуть. Что я могу сказать.. Идея отделить веб-представление от кода - замечательная. Потому что куски html, перемешанные с серверным кодом на jscript/vb/php/ещё чём-нибудь - это ужасно, за это надо сразу расстреливать через повешение с пожизненным лишением права программировать.
Идея замечательная.. Новсё, что вы делаете руками реализация местами убивает напрочь.
Приделываете вы, скажем, к форме валидатор какого-нибудь поля. На нём английским по белому написано runat="server". И можете по наивности подумать, что обрабатываться он будет на сервере. Агащазблин, размечтались. То есть, на сервере он тоже будет, и это правильно.
Но - в дополнение к этому он _иногда_ может обрабатываться и на клиенте. Клиентским джавскриптом, который встраивается высокоинтеллектуальным движком ASP.NET в отдаваемую клиенту html-страницу. Если движок сочтет, что клиентский браузер достаточно умён для обработки этого джаваскрипта. А если недостаточно - то форма будет каждый раз отправляться на сервер и проверяться там.
Не, вообще говоря, предварительная проверка на клиенте - это правильно, чтоб лишний раз не гонять форму туда-обратно. Но. В результате валидация формы работает то так, то эдак.
Например, приделали вы к одному управляющему элементу CustomValidator, который работает только на сервере, а к трём другим стандартные, который работают и на сервере, и на клиенте. Ошибки от последних трёх элементов вы получите сразу, а от первого - ТОЛЬКО после правильного заполнения остальных трёх. Потому что пока вы их правильно не заполните, форма на сервер вообще не отправится, и обработчик CustomValidator'а не запустится.
Это если высокоинтеллектуальный ASP.NET решит, что ваш браузер достаточно умён. А если нет, то форма сразу отправится на сервер и там сработают сразу все четыре валидатора.
Этот искусственный интеллект движка можно отключить, однако ж по умолчанию он включён.
Далее. Обработчик CustomValidator'а не вызывается, если в поле ничего не ввести. Ну действительно, фигня какая, раз не заполнили - значит, это ненужное поле какое-то, чего его проверять-то..
И это не баг, это вполне документированная фича такая.
Конечно, существует обходной манёвр - не указывать валидатору, какое поле он валидирует. Тогда его обработчик вызывается всегда, а уже внутри там можно явно вынимать данные из нужных управляющих элементов.
Или можно приделать к полю дополнительный валидатор - RequiredFieldValidator. Который, кстати, проверяет поле вовсе не на непустоту, а на отличие от первоначального значения.
Оно работает, но по-моему, при наличии специально написанного программистом CustomValidator'а такой способ сильно отдаёт ненатурализмом.
В общем, хотели, как лучше..
Идея замечательная.. Но
Приделываете вы, скажем, к форме валидатор какого-нибудь поля. На нём английским по белому написано runat="server". И можете по наивности подумать, что обрабатываться он будет на сервере. Агащазблин, размечтались. То есть, на сервере он тоже будет, и это правильно.
Но - в дополнение к этому он _иногда_ может обрабатываться и на клиенте. Клиентским джавскриптом, который встраивается высокоинтеллектуальным движком ASP.NET в отдаваемую клиенту html-страницу. Если движок сочтет, что клиентский браузер достаточно умён для обработки этого джаваскрипта. А если недостаточно - то форма будет каждый раз отправляться на сервер и проверяться там.
Не, вообще говоря, предварительная проверка на клиенте - это правильно, чтоб лишний раз не гонять форму туда-обратно. Но. В результате валидация формы работает то так, то эдак.
Например, приделали вы к одному управляющему элементу CustomValidator, который работает только на сервере, а к трём другим стандартные, который работают и на сервере, и на клиенте. Ошибки от последних трёх элементов вы получите сразу, а от первого - ТОЛЬКО после правильного заполнения остальных трёх. Потому что пока вы их правильно не заполните, форма на сервер вообще не отправится, и обработчик CustomValidator'а не запустится.
Это если высокоинтеллектуальный ASP.NET решит, что ваш браузер достаточно умён. А если нет, то форма сразу отправится на сервер и там сработают сразу все четыре валидатора.
Этот искусственный интеллект движка можно отключить, однако ж по умолчанию он включён.
Далее. Обработчик CustomValidator'а не вызывается, если в поле ничего не ввести. Ну действительно, фигня какая, раз не заполнили - значит, это ненужное поле какое-то, чего его проверять-то..
И это не баг, это вполне документированная фича такая.
Конечно, существует обходной манёвр - не указывать валидатору, какое поле он валидирует. Тогда его обработчик вызывается всегда, а уже внутри там можно явно вынимать данные из нужных управляющих элементов.
Или можно приделать к полю дополнительный валидатор - RequiredFieldValidator. Который, кстати, проверяет поле вовсе не на непустоту, а на отличие от первоначального значения.
Оно работает, но по-моему, при наличии специально написанного программистом CustomValidator'а такой способ сильно отдаёт ненатурализмом.
В общем, хотели, как лучше..
Tags:
no subject
Согласен. Не знаю с чем связано, но мне думается, что не в последнюю очередь с самой убогостью веба.
> вот если б всё это было ещё явно описано
Опять же консенсус. :)