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

[Adelf]

Вероятно я просто не могу понять твои мысли.
Я понял так, что ты приводишь технику Data binding как аргумент в пользу связи доменного объекта и формы. Я не прав?

 

[grigori]

@Adelf, нет, это не аргумент, просто комментарий к одной из мыслей Вурдалака.
Для меня форма - это просто элемент интерфейса. Если надо сделать валидацию на клиенте - можно сделать модель на клиенте для валидации данных, безотносительно формы.

 

[Adelf]

а то, что тебе C# тебе генерит JS - это уже твой выбор

Ничего там не генерит. WPF - это не веб-платформа. Это десктоп.

 

[grigori]

понимаешь ли, это то же самое ты не определяешь протокол взаимодействия кода отрисовки и кода обработки, отдаешь на откуп фреймворка. А в Иксах этот протокол есть, и десктопы могут ездить по сети.

 

[Вурдалак]

к сожалению, ты опять начинаешь вести разговор несвязанными фразами, и общаться становится сложно

Если тебе что-то непонятно — спроси. Отвечать теми же бессвязными фразами не нужно.

 

[grigori]

@Вурдалак, скорее всего мы в итоге понимаем примерно одно и то же, просто я называю понятия терминами из RFC, а не подразумеваю под "формой" некий код, связанный с обработкой данных, которые пришли в запросе после сабмита формы, и который контролирует соблюдение негласного протокола, заданного структурой формы. Я задаю протокол декларативно статьей в wiki.

 

[fixxxer]

примеры популярного сейчас "data binding" - это Angular, Knockout, React, Ember, в них связываются данные не между сервером и клиентом, а внутри клиента

Да, так. А какое тогда сюда отношение имеют те модели, которые в domain model на сервере? В чем аналогия? Я не понял.

 

[Vano]

Я тут даже боюсь вмешиватся(щас заплюют))) , но мне кажется, допустим на моём примере (в ларавеле), валидацию стоит делать два раза - один раз это "формы пользователя" перед запуском экшна контроллера(просто чтобы пришли все нужные данные в нужном формате), а второй раз уже гдето в сервисе, перед началом реализации бизнес-логики (даже с тем же авторедиректом и флеш ошибками). Ну давайте плевайте))

 

[Vano]

Почему я так подумал? перед сервисом но после Экшна? то-шо экшн может записывать действия пользователя допустим(защита от перебора паролей и тд).

 

[Adelf]

@Vano, ты правильно мыслишь. Только ошибки бизнес логики должны просто генерить эксепшены. Которые потом уже можно превращать в авторедиректы и флеш ошибки.

 

[hell0w0rd]

авторедиректы и флеш ошибки

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

 

[Adelf]

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

В реальном мире никто не мешает ошибку NotUniqueUsername превращать в ошибку конкретного поля и обрамлять красненькой рамочкой.

А "авторедиректы и флеш ошибки" - это я просто процитировал Vano

 

[Вурдалак]

вот странный результат. Почему ошибка в конкретном месте превращается в глобальную ошибку? Например прислал юзер при регистрации неуникальный username.

Тебе ничто не мешает валидировать присланную команду RegisterUser { "username": "Foo", ... }, указав, что username неуникален, тогда до выполнения команды даже не дойдёт.

Но мне кажется, считать, что сервер должен заботиться о каждом поле клиента — это не уважать клиент.
Клиент тоже должен быть по возможности самодостаточным и не тупым.
По возможности он должен посылать осмысленные команды, а не «поля для регистрации».
И он должен понимать, что ему отвечает сервер.
Не такой ли свободы хотел client-side?

 

[Adelf]

@Вурдалак, клиент в руках врага. Он не получит нужного доверия.

 

[Вурдалак]

@Вурдалак, клиент в руках врага. Он не получит нужного доверия.

Я не уверен, что понял тебя.

 

[Adelf]

Но мне кажется, считать, что сервер должен заботиться о каждом поле клиента — это не уважать клиент.

Если клиент - это js в браузере, то тут дело не в уважении, а в доверии к этим данным.

 

[Вурдалак]

Если клиент - это js в браузере, то тут дело не в уважении, а в доверии к этим данным.

Видимо ты меня неверно понял.
Возвращаясь к примеру с <select name="status">, клиент может выполнить (или сохранить в какой-то пул команд) команду ApproveUser { userId: 42 }, вместо того, чтобы отправлять status=2.
Когда ты оперируешь с командами, то тебе приходится более осознанно воспринимать ответы сервера, а не тупо маппить полученный ответ { поле => ошибка } на форму.

К примеру: если форма регистрации содержит помимо всего прочего флаг «Хочу подписаться на рассылку», клиент на самом деле может сгенерировать две команды:

• RegisterUser
• Subscribe

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

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

 

[Adelf]

Ну дошло да. Понятно было, что ты такую чушь не предложишь ) Однако, в данном случае все равно придется валидировать параметры команд.

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

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

Ну как антипод того, что ты присылал про Magic push button.

 

[hell0w0rd]

Тебе ничто не мешает валидировать присланную команду RegisterUser { "username": "Foo", ... }, указав, что username неуникален, тогда до выполнения команды даже не дойдёт.

не факт что не мешает. Это слишком суровое требование, не все внешние системы могут иметь локи, чтобы совершить такую проверку.

Клиент тоже должен быть по возможности самодостаточным и не тупым.

Ну ты же понимаешь о чем я говорю) Клиент может 25 раз все проверить, а на этапе выполнения запроса что-то пойдет не так.

 

[Вурдалак]

не факт что не мешает. Это слишком суровое требование, не все внешние системы могут иметь локи, чтобы совершить такую проверку.

Валидация может быть на стороне сервера. Что-то вроде: https://github.com/leopro/trip-planner/blob/master/src/Leopro/TripPlanner/PresentationBundle/Controller/ApiController.php#L26
Эта валидация нужна будет лишь с той целью, чтобы можно было ответить скопом на ошибки в нескольких полях.
Она нужна для удобства.

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