Меню
Что нового?

Laravel А что greater than нету?

  • Автор темы Автор темы Vano
  • Дата начала Дата начала
Вероятно я просто не могу понять твои мысли.
Я понял так, что ты приводишь технику Data binding как аргумент в пользу связи доменного объекта и формы. Я не прав?
 
@Adelf, нет, это не аргумент, просто комментарий к одной из мыслей Вурдалака.
Для меня форма - это просто элемент интерфейса. Если надо сделать валидацию на клиенте - можно сделать модель на клиенте для валидации данных, безотносительно формы.
 
Последнее редактирование:
понимаешь ли, это то же самое ;) ты не определяешь протокол взаимодействия кода отрисовки и кода обработки, отдаешь на откуп фреймворка. А в Иксах этот протокол есть, и десктопы могут ездить по сети.
 
Последнее редактирование:
@Вурдалак, скорее всего мы в итоге понимаем примерно одно и то же, просто я называю понятия терминами из RFC, а не подразумеваю под "формой" некий код, связанный с обработкой данных, которые пришли в запросе после сабмита формы, и который контролирует соблюдение негласного протокола, заданного структурой формы. Я задаю протокол декларативно статьей в wiki.
 
grigori написал(а):
примеры популярного сейчас "data binding" - это Angular, Knockout, React, Ember, в них связываются данные не между сервером и клиентом, а внутри клиента
Нажмите для раскрытия...

Да, так. А какое тогда сюда отношение имеют те модели, которые в domain model на сервере? В чем аналогия? Я не понял.
 
Я тут даже боюсь вмешиватся(щас заплюют))) , но мне кажется, допустим на моём примере (в ларавеле), валидацию стоит делать два раза - один раз это "формы пользователя" перед запуском экшна контроллера(просто чтобы пришли все нужные данные в нужном формате), а второй раз уже гдето в сервисе, перед началом реализации бизнес-логики (даже с тем же авторедиректом и флеш ошибками). Ну давайте плевайте))
 
Почему я так подумал? перед сервисом но после Экшна? то-шо экшн может записывать действия пользователя допустим(защита от перебора паролей и тд).
 
@Vano, ты правильно мыслишь. Только ошибки бизнес логики должны просто генерить эксепшены. Которые потом уже можно превращать в авторедиректы и флеш ошибки.
 
  • Like
Реакции: AmdY
Adelf написал(а):
авторедиректы и флеш ошибки
Нажмите для раскрытия...
вот странный результат. Почему ошибка в конкретном месте превращается в глобальную ошибку? Например прислал юзер при регистрации неуникальный username.
Странно, что вы делите на валидацию и бизнес логику. В реальном мире это не так, клиенту что на этапе валидации, что на этапе ошибки при вставке в базу надо выдать, что не какая-то абстрактная ошибка, а именно вот это поле не валидно.
 
hell0w0rd написал(а):
В реальном мире это не так, клиенту что на этапе валидации, что на этапе ошибки при вставке в базу надо выдать, что не какая-то абстрактная ошибка, а именно вот это поле не валидно.
Нажмите для раскрытия...
В реальном мире никто не мешает ошибку NotUniqueUsername превращать в ошибку конкретного поля и обрамлять красненькой рамочкой.

А "авторедиректы и флеш ошибки" - это я просто процитировал Vano :)
 
Последнее редактирование:
hell0w0rd написал(а):
вот странный результат. Почему ошибка в конкретном месте превращается в глобальную ошибку? Например прислал юзер при регистрации неуникальный username.
Нажмите для раскрытия...
Тебе ничто не мешает валидировать присланную команду RegisterUser { "username": "Foo", ... }, указав, что username неуникален, тогда до выполнения команды даже не дойдёт.

Но мне кажется, считать, что сервер должен заботиться о каждом поле клиента — это не уважать клиент.
Клиент тоже должен быть по возможности самодостаточным и не тупым.
По возможности он должен посылать осмысленные команды, а не «поля для регистрации».
И он должен понимать, что ему отвечает сервер.
Не такой ли свободы хотел client-side?
 
Последнее редактирование:
Adelf написал(а):
Если клиент - это js в браузере, то тут дело не в уважении, а в доверии к этим данным.
Нажмите для раскрытия...
Видимо ты меня неверно понял.
Возвращаясь к примеру с <select name="status">, клиент может выполнить (или сохранить в какой-то пул команд) команду ApproveUser { userId: 42 }, вместо того, чтобы отправлять status=2.
Когда ты оперируешь с командами, то тебе приходится более осознанно воспринимать ответы сервера, а не тупо маппить полученный ответ { поле => ошибка } на форму.

К примеру: если форма регистрации содержит помимо всего прочего флаг «Хочу подписаться на рассылку», клиент на самом деле может сгенерировать две команды:
  • RegisterUser
  • Subscribe
Это лишь предпочтение клиента разместить в форме регистрации ещё и галочку с подпиской, бизнес-логика самой регистрации этого может и не требовать.
Если клиент не может самостоятельно разбить нужные ему действия юзера на команды, то он расписывается в собственной беспомощности. И сервер вынужден помогать клиенту.

Client-side стремится к независимости. Серверный «рендеринг» уходит в прошлое. Формы строятся на клиенте. Почему бы тогда клиенту не взять на себя ответственность за передачу действий пользователей в явном виде, чтобы иметь право называться самостоятельным.
 
Последнее редактирование:
Ну дошло да. Понятно было, что ты такую чушь не предложишь ) Однако, в данном случае все равно придется валидировать параметры команд.

А со статусами... я давно уже осознал, что когда каждой бизнес-операции своя кнопка(не стоит воспринимать буквально) - интерфейс становится в разы интуитивнее. И код проще.
Не селектом изменять статус заказа, а каждому статусу - свои кнопки изменения статуса.
У меня так в админке девконфа.
Статус заказа - заявка.
Кнопки - Отменить. Провести(и тут уже опции, оплачен он(у нас там вручную оплаты проставляют)... или гарантийное письмо послали, что оплатят позже).

У проведенного заказа - остается кнопка Отменить.. и там немного другая логика отмены.

Ну как антипод того, что ты присылал про Magic push button.
 
Вурдалак написал(а):
Тебе ничто не мешает валидировать присланную команду RegisterUser { "username": "Foo", ... }, указав, что username неуникален, тогда до выполнения команды даже не дойдёт.
Нажмите для раскрытия...
не факт что не мешает. Это слишком суровое требование, не все внешние системы могут иметь локи, чтобы совершить такую проверку.
Вурдалак написал(а):
Клиент тоже должен быть по возможности самодостаточным и не тупым.
Нажмите для раскрытия...
Ну ты же понимаешь о чем я говорю) Клиент может 25 раз все проверить, а на этапе выполнения запроса что-то пойдет не так.
 
hell0w0rd написал(а):
не факт что не мешает. Это слишком суровое требование, не все внешние системы могут иметь локи, чтобы совершить такую проверку.
Нажмите для раскрытия...
Валидация может быть на стороне сервера. Что-то вроде: https://github.com/leopro/trip-plan...tationBundle/Controller/ApiController.php#L26
Эта валидация нужна будет лишь с той целью, чтобы можно было ответить скопом на ошибки в нескольких полях.
Она нужна для удобства.

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