Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
MVC: обработка исключения в контроллере
|
|||
|---|---|---|---|
|
#18+
hVosttcodearticles.ru1. Мы не получим ошибку The required anti-forgery form field "__RequestVerificationToken" is not present; 2. $(".email").text() не играет роли, я тебе уже 10 раз об этом писал. $.post постит форму, а не $(".email").text() 3. JSON.stringify(model) и не должна мапиться в модель, мапиться в модель будет вся форма. Тоже писал об этом. Это обычный огрызок кода, который нужно выкинуть. Но так или иначе он 100% работает 4. Ну так и пусть идет валидация всего класса. Пусть пользователь всё вводит, а потом мы отвалидируем. Если ты хочешь более гибкого решения, чтобы не зависеть от остальной валидации, то сделай вторую модель IValidatableObject и реализуй в ней проверку на email. И дергай её аяксом. Это всё уже дополнительная логика, которая не обсуждалась изначально. И тем не менее, эта логика отлично ложится в IValidatableObject 5. Я тебе еще раз повторяю, не нужно ничего парсить. Выше я пример дал, валидаторы штатно отработают. Если нужна гибкая динамика, выше я дал пример, как рендерить словарь ошибок в валидаторе формы через аякс. Опять же, штатные валидаторы рулят. на счёт пунктов 2-4, скайана прав. придётся признать. Что признать? Нечего там признаваться, я прокомментировал каждый пункт. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2014, 14:54 |
|
||
|
MVC: обработка исключения в контроллере
|
|||
|---|---|---|---|
|
#18+
hVosttниправильно мешать атрибуты с IValidatableObject, ваще. Глупости. IValidatableObject отлично вписывается сюда. hVosttЕсть же атрибут [Remote], чем он вам не угодил, не пойму??? Почему не угодил? Хороший вариант. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2014, 14:55 |
|
||
|
MVC: обработка исключения в контроллере
|
|||
|---|---|---|---|
|
#18+
А вообще в WildApricot валидация выглядит так: Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. Код: c# 1. 2. 3. 4. Причём ValidationModel конвертируется в ValidationJsonModel и работает на клиенте, а не только на сервере. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2014, 15:06 |
|
||
|
MVC: обработка исключения в контроллере
|
|||
|---|---|---|---|
|
#18+
codearticles.ruЧто признать? Нечего там признаваться, я прокомментировал каждый пункт. То что ты привёл 16687324 -- это не работает, я показал где и почему, и это только по минимумому. самое очевидное так сказать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2014, 15:07 |
|
||
|
MVC: обработка исключения в контроллере
|
|||
|---|---|---|---|
|
#18+
codearticles.ruГлупости. IValidatableObject отлично вписывается сюда. нельзя! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2014, 15:08 |
|
||
|
MVC: обработка исключения в контроллере
|
|||
|---|---|---|---|
|
#18+
hVosttcodearticles.ruЧто признать? Нечего там признаваться, я прокомментировал каждый пункт. То что ты привёл 16687324 -- это не работает, я показал где и почему, и это только по минимумому. самое очевидное так сказать. То, что я привел, 100% работает. Вот солюшен . hVosttcodearticles.ruГлупости. IValidatableObject отлично вписывается сюда. нельзя! Можно и нужно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2014, 15:11 |
|
||
|
MVC: обработка исключения в контроллере
|
|||
|---|---|---|---|
|
#18+
hVostt, ты же знаешь, что МСУ будет вести себя как последнее трепло и тролль, но не признается, что облажался. Давай не будем его кормить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2014, 15:13 |
|
||
|
MVC: обработка исключения в контроллере
|
|||
|---|---|---|---|
|
#18+
Все мы знаем о насущной тупости скианы, которому нужно всё по 200 раз разжевывать. И даже на 201 раз у него в голове мало что отложится, чтобы понять, что он обычное днище. Давайте все скажем спасибо скиане за его очередную тупость. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2014, 15:22 |
|
||
|
MVC: обработка исключения в контроллере
|
|||
|---|---|---|---|
|
#18+
hVostt, объясню, почему IValidatableObject таки лучше, чем Remote. Remote - это чисто mvc-шная залипушка, а IValidatableObject - это DataAnnotations из FW. IValidatableObject и IDataErrorInfo будут работать даже под водой. Это универсальное решение. Но я не против Remote, это тоже хороший способ быстро решить задачу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2014, 15:40 |
|
||
|
MVC: обработка исключения в контроллере
|
|||
|---|---|---|---|
|
#18+
codearticles.ru, по тому, как сильно ты хамишь, можно понять степень твоей защитной реакции на то, как ты облажался. Попробуй как-нибудь перебороть свои комплексы и признать ошибки. А то может и в патологию выродится. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2014, 15:47 |
|
||
|
MVC: обработка исключения в контроллере
|
|||
|---|---|---|---|
|
#18+
codearticles.ruhVostt, объясню, почему IValidatableObject таки лучше, чем Remote. Remote - это чисто mvc-шная залипушка, а IValidatableObject - это DataAnnotations из FW. IValidatableObject и IDataErrorInfo будут работать даже под водой. Это универсальное решение. Но я не против Remote, это тоже хороший способ быстро решить задачу. так а кто ж мешает сделать свой атрибут типа Remote? атрибуты явно лучше, чем реализация классом IValidatableObject, так как атрибуты могут применяться множество раз, на разных моделях. реализовывать IValidatableObject -- это крайний случай, которого всеми силами следует избегать, обычно он требуется когда валидация сложная и комплексная, учитывает значения всех или значительной части полей модели. такое требуется крайне редко. и это уж точно не подходит для проверки имени пользователя на валидность. ну просто можно свой атрибут реализовать, если Remote не устраивает. у меня таких разных кастомных атрибутов обычно набирается много, часть из них уже крепко сидит в шаред библиотеке, которая используется в нескольких проектах. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2014, 15:55 |
|
||
|
MVC: обработка исключения в контроллере
|
|||
|---|---|---|---|
|
#18+
hVostt, а вот у нас для одной и той же модели можно применять разную модель валидации (набор правил). Причём правила могут быть как простые, так и комплексные. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2014, 16:00 |
|
||
|
MVC: обработка исключения в контроллере
|
|||
|---|---|---|---|
|
#18+
hVosttcodearticles.ruhVostt, объясню, почему IValidatableObject таки лучше, чем Remote. Remote - это чисто mvc-шная залипушка, а IValidatableObject - это DataAnnotations из FW. IValidatableObject и IDataErrorInfo будут работать даже под водой. Это универсальное решение. Но я не против Remote, это тоже хороший способ быстро решить задачу. так а кто ж мешает сделать свой атрибут типа Remote? атрибуты явно лучше, чем реализация классом IValidatableObject, так как атрибуты могут применяться множество раз, на разных моделях. реализовывать IValidatableObject -- это крайний случай, которого всеми силами следует избегать, обычно он требуется когда валидация сложная и комплексная, учитывает значения всех или значительной части полей модели. такое требуется крайне редко. и это уж точно не подходит для проверки имени пользователя на валидность. ну просто можно свой атрибут реализовать, если Remote не устраивает. у меня таких разных кастомных атрибутов обычно набирается много, часть из них уже крепко сидит в шаред библиотеке, которая используется в нескольких проектах. Так в том-то и дело, что не нужны никакие дополнительные атрибуты. Всё отлично ложится в ValidatableObject и IDataErrorInfo, причем самым гибким образом. Да и зачем писать что-то типа Remote, если уже есть Remote. Попахивает идиотизмом. IValidatableObject и IDataErrorInfo это мощный инструмент, подходит на все 100% случаев жизни. Типа проверки на дубликат учетной записи. А кастомные атрибуты и прочая мишура идет в лес. Зачем писать велосипед, когда всё уже есть? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2014, 16:02 |
|
||
|
MVC: обработка исключения в контроллере
|
|||
|---|---|---|---|
|
#18+
skyANAhVostt, а вот у нас для одной и той же модели можно применять разную модель валидации (набор правил). Причём правила могут быть как простые, так и комплексные. Я про это писал выше. Делается n конкретный IValidatableObject моделей и каждая может валидироваться по-отдельности, так и всё вместе. Причем в mvc есть готовый инструмент для форсирования валидации TryValidateModel. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2014, 16:06 |
|
||
|
MVC: обработка исключения в контроллере
|
|||
|---|---|---|---|
|
#18+
codearticles.ruskyANAhVostt, а вот у нас для одной и той же модели можно применять разную модель валидации (набор правил). Причём правила могут быть как простые, так и комплексные. Я про это писал выше. Делается n конкретный IValidatableObject моделей и каждая может валидироваться по-отдельности, так и всё вместе. Причем в mvc есть готовый инструмент для форсирования валидации TryValidateModel.Мимо. У нас всего два класса, а не N: ViewModel и ValidationModel. Но при этом в разных местах можно применать разные наборы правил (ValidationRules), причём каких угодно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2014, 16:14 |
|
||
|
MVC: обработка исключения в контроллере
|
|||
|---|---|---|---|
|
#18+
codearticles.ruТак в том-то и дело, что не нужны никакие дополнительные атрибуты. Всё отлично ложится в ValidatableObject и IDataErrorInfo, причем самым гибким образом. Да и зачем писать что-то типа Remote, если уже есть Remote. Попахивает идиотизмом. IValidatableObject и IDataErrorInfo это мощный инструмент, подходит на все 100% случаев жизни. Типа проверки на дубликат учетной записи. А кастомные атрибуты и прочая мишура идет в лес. Зачем писать велосипед, когда всё уже есть? затем, что аспекты гибче наследования. атрибуты можно навесить в любых комбинациях на кучу моделей. а одна реализация IValidatableObject так и будет всего лишь одной реализацией для всего лишь одной модели. недостатки такого подхода объяснять? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2014, 16:19 |
|
||
|
MVC: обработка исключения в контроллере
|
|||
|---|---|---|---|
|
#18+
skyANAhVostt, а вот у нас для одной и той же модели можно применять разную модель валидации (набор правил). Причём правила могут быть как простые, так и комплексные. ну мы несколько отличаем простую и бизнес-валидацию. для бизнеса у нас есть провайдер, который встраивается в механизм валидации MVC / WebAPI через инъекцию, а там накачивается через атрибуты или конфигурацию. даже флюент мы не пишем, как у вас, это уж слишком ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2014, 16:21 |
|
||
|
MVC: обработка исключения в контроллере
|
|||
|---|---|---|---|
|
#18+
skyANA, Код: c# 1. 2. 3. 4. 5. 6. 7. выглядит как-то громоздко на мой взгляд и не использует существующую инфраструктуру валидации. Не вижу особых преимуществ перед: [MaxLength] ValidSimbolsMask] InvalidSubstringsMask] интересно, почему вы сделали такой выбор ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2014, 16:28 |
|
||
|
MVC: обработка исключения в контроллере
|
|||
|---|---|---|---|
|
#18+
skyANAcodearticles.ruпропущено... Я про это писал выше. Делается n конкретный IValidatableObject моделей и каждая может валидироваться по-отдельности, так и всё вместе. Причем в mvc есть готовый инструмент для форсирования валидации TryValidateModel.Мимо. У нас всего два класса, а не N: ViewModel и ValidationModel. Но при этом в разных местах можно применать разные наборы правил (ValidationRules), причём каких угодно. Прямо. У нас может быть сколько угодно классов. Никто никаких ограничений не накладывает. UserValidationModel, UserEmailValidationModel, UserAccessValidationModel и т.п. И все эти валидационные модели централизованно пляшут от IValidatableObject. hVosttcodearticles.ruТак в том-то и дело, что не нужны никакие дополнительные атрибуты. Всё отлично ложится в ValidatableObject и IDataErrorInfo, причем самым гибким образом. Да и зачем писать что-то типа Remote, если уже есть Remote. Попахивает идиотизмом. IValidatableObject и IDataErrorInfo это мощный инструмент, подходит на все 100% случаев жизни. Типа проверки на дубликат учетной записи. А кастомные атрибуты и прочая мишура идет в лес. Зачем писать велосипед, когда всё уже есть? затем, что аспекты гибче наследования. атрибуты можно навесить в любых комбинациях на кучу моделей. а одна реализация IValidatableObject так и будет всего лишь одной реализацией для всего лишь одной модели. недостатки такого подхода объяснять? Что может быть гибче прямого кодирования в реализации аннотаций? Причем, у нас не обязательно одна IValidatableObject, их может быть 10. И работать они могут по одной, две, три или сразу все вместе. В зависимости от потребностей. Декомпозируй как хочешь. Никаких левых атрибутов. Всё штатно и прозрачно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2014, 16:33 |
|
||
|
MVC: обработка исключения в контроллере
|
|||
|---|---|---|---|
|
#18+
И самое главное, о чем все как-то забыли. Никакой логики исключений для валидации модели! За исключение - кастрация без суда и следствия. Дада. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2014, 16:34 |
|
||
|
MVC: обработка исключения в контроллере
|
|||
|---|---|---|---|
|
#18+
codearticles.ruДекомпозируй как хочешь. Как ты собираешься декомпозировать, если они прибиты к своим моделям? Вот есть атрибут [Required], давай выбросим и напишем IValidatableObject для этих целей. Покажешь пример? А то что-то не догоняю, может ты и прав, на помойку эти атрибуты. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2014, 16:35 |
|
||
|
MVC: обработка исключения в контроллере
|
|||
|---|---|---|---|
|
#18+
codearticles.ruЗа исключение - кастрация без суда и следствия. Дада. Вот здеся согласен полностью на все 100%. Ещё бы рук лешить для верности. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2014, 16:36 |
|
||
|
MVC: обработка исключения в контроллере
|
|||
|---|---|---|---|
|
#18+
hVosttcodearticles.ruДекомпозируй как хочешь. Как ты собираешься декомпозировать, если они прибиты к своим моделям? Вот есть атрибут [Required], давай выбросим и напишем IValidatableObject для этих целей. Покажешь пример? А то что-то не догоняю, может ты и прав, на помойку эти атрибуты. Ну вот скиана захотел реализовать отдельно проверку на существование учетки. Ему не нравится, что нужно сначала заполнить все поля, а потом нажимать кнопку сохранить. И только тогда начинается валидация всей модели. Ему хочется, чтобы валидация на дубликатов учетки шло сразу и не зависимо от обязательности ввода пароля. Поэтому имеем две модельки Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. Причем, вторую модель RegisterEmailViewModel мы можем валидировать как через ModelState (удобно для случаев аяксов), так и через TryValidateModel в контроллере при посте всей формы. Идею понял? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2014, 16:56 |
|
||
|
MVC: обработка исключения в контроллере
|
|||
|---|---|---|---|
|
#18+
Вообще-то это hVostt изначально хотел на лету подсказывать пользователю, что логин занят и предлагать свободные варианты. А Алексей задал вопрос как этот запрос реализовать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2014, 17:01 |
|
||
|
|

start [/forum/topic.php?fid=18&msg=38773265&tid=1356943]: |
0ms |
get settings: |
11ms |
get forum list: |
18ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
51ms |
get topic data: |
15ms |
get forum data: |
4ms |
get page messages: |
83ms |
get tp. blocked users: |
2ms |
| others: | 275ms |
| total: | 467ms |

| 0 / 0 |
