Комментарии 22
Собственно, это server-side валидация через ajax, а не frontend-валидация. Валидация на фронте — это проверка на стороне клиента без запроса на сервер, но там DRY-ем даже не пахнет.
С терминологией спорить не буду, всё так и есть. Я хотел подчеркнуть, что валидация осуществляется средствами js ( + server-side), но без отправки формы с перезагрузкой страницы. Пользователь сразу получает информацию о правильности заполнения полей, как будто это делает чистый js, но без дублирования логики валидации.
Мне кажется тут надо писать гем, который бы из модели генерировал front-end валидатор — тогда бы было все по-честному.
Это далеко не всегда возможно. Из простого — проверка уникальности. Из более сложного — всякие кастомные проверки, коллбэки и прочее. На фронте можно проверить максимум заполнение поля, длину и формат (интервал для чисел).
И этот gem уже вполне существует, о чём я писал ниже. Для rails3 — client_side_validations, для rails4 — rails4_client_side_validations.
Если говорить о «стандартной» валидации: проверка на существование, длину, тип, регулярка — все это можно перенести в JS.
Частные случаи можно либо дописывать в JS(на то они и частные), либо (наверное это будет ужасно) писать валидатор в принципе на JS и из руби выполнять JS.
Первый способ более правильный, но, увы, не вписывается в концепцию «единый валидатор». У меня самого такая проблема — двойная логика в RoR и Knockout. Я почему и говорю про генерацию JS валидаторов — я бы написал генератор JS кода на основе RoR моделей (все валидаторы, связи и прочее). Причем эта генерация нужна «единожды». Налету ее генерировать смысла нет.
Частные случаи можно либо дописывать в JS(на то они и частные), либо (наверное это будет ужасно) писать валидатор в принципе на JS и из руби выполнять JS.
Первый способ более правильный, но, увы, не вписывается в концепцию «единый валидатор». У меня самого такая проблема — двойная логика в RoR и Knockout. Я почему и говорю про генерацию JS валидаторов — я бы написал генератор JS кода на основе RoR моделей (все валидаторы, связи и прочее). Причем эта генерация нужна «единожды». Налету ее генерировать смысла нет.
Это, на мой взгляд, ненужные сложности. В большинстве случаев нам нужно не только проверить модель, но и сохранить ее в фоне, а тут совсем проблем нет, и все эти извращения с валидацией на фронте уходят сами собой.
Ну а валидация чисто на фронте при необходимости доступа к БД невозможна в принципе. А коль скоро мы все равно будем дергать сервер, то какого черта, ajax-валидация — наше все.
Ну а валидация чисто на фронте при необходимости доступа к БД невозможна в принципе. А коль скоро мы все равно будем дергать сервер, то какого черта, ajax-валидация — наше все.
а если к примеру нужна валидация не только полей, но и связей? понятно что ajax наше все и это упрощает. Но если мы берем Knockout, Angular, Backbone? у них своя логика и, зачастую, она может дублировать backend.
Например. У нас есть Item для продажи. Надо посчитать его стоимость. Формула стоимости (по причине кучи связей и условностей) большая. Эту стоимость надо в итоге считать и в backend (суммировать заказ) и, самое простое, в корзине.
По сути в мелких масштабах ничего страшного, но если фурмула усложняется и добавляются условия? В итоге у вас over 100 строк для подсчета на backend и столько же в front-end.
Понятно, что частный случай, Но на каждый клик ajax валидацию делать нельзя
Например. У нас есть Item для продажи. Надо посчитать его стоимость. Формула стоимости (по причине кучи связей и условностей) большая. Эту стоимость надо в итоге считать и в backend (суммировать заказ) и, самое простое, в корзине.
По сути в мелких масштабах ничего страшного, но если фурмула усложняется и добавляются условия? В итоге у вас over 100 строк для подсчета на backend и столько же в front-end.
Понятно, что частный случай, Но на каждый клик ajax валидацию делать нельзя
Частные случаи можно либо дописывать в JS(на то они и частные), либо (наверное это будет ужасно) писать валидатор в принципе на JS и из руби выполнять JS.Так недолго и до node.js докатиться =)
Без холивара, но в PHP Yii — это из коробки. Плюс можно включать/отключать фронтенд валидацию как для всей формы, так и для некоторых элементов(например, капчи).
Скорее всего не фронтенд-валидацию, а таки ajax-валидацию.
Кроме того, это «из коробки» судя по куче постов в блогах требует изменения каждого контроллера, где это необходимо, что не совсем DRY, мягко выражаясь. Если у вас есть актуальные статьи, которые это опровергают — пруф в студию.
Пока я видел что-то в стиле
Аналогичные вещи пишут в документации: www.yiiframework.com/doc/api/1.1/CActiveForm#enableAjaxValidation-detail.
Судя по фрагментам кода и подходам, Yii пытается копировать RoR, но синтаксис PHP не располагает. Что ещё ждать от вторичных имитаторов?
Кроме того, это «из коробки» судя по куче постов в блогах требует изменения каждого контроллера, где это необходимо, что не совсем DRY, мягко выражаясь. Если у вас есть актуальные статьи, которые это опровергают — пруф в студию.
Пока я видел что-то в стиле
осторожно, PHP
В контроллере:
Во вью:
knackforge.com/blog/vishnu/yii-how-enable-ajax-form-validation
if(isset($_POST['ajax'])) {
if ($_POST['ajax']=='form') {
echo CActiveForm::validate($model);
}
Yii::app()->end();
}
Во вью:
<?php
$form = $this->beginWidget('CActiveForm', array(
'id'=>'form', //form-id
'enableAjaxValidation'=>true,
'clientOptions'=>array(
'validateOnSubmit'=>true,
),
));
?>
knackforge.com/blog/vishnu/yii-how-enable-ajax-form-validation
Аналогичные вещи пишут в документации: www.yiiframework.com/doc/api/1.1/CActiveForm#enableAjaxValidation-detail.
Судя по фрагментам кода и подходам, Yii пытается копировать RoR, но синтаксис PHP не располагает. Что ещё ждать от вторичных имитаторов?
У меня не статьи — у меня код.
Нет. Там есть фронтенд без аякса, в том числе и для капчи. Тоесть можно включить аякс, но можно и только в браузере.
Что за быдлокод вы прислали? Там просто $model->save(). Если ошибка — оно не сохранит.
Я же сказал, без холивара, потому «Что ещё ждать от вторичных имитаторов?» просто проигнорую. Хотя удивлен что в таком фремворке как RoR нет таких базовых вещей.
Нет. Там есть фронтенд без аякса, в том числе и для капчи. Тоесть можно включить аякс, но можно и только в браузере.
Что за быдлокод вы прислали? Там просто $model->save(). Если ошибка — оно не сохранит.
Я же сказал, без холивара, потому «Что ещё ждать от вторичных имитаторов?» просто проигнорую. Хотя удивлен что в таком фремворке как RoR нет таких базовых вещей.
Код, который приведен в спойлере практически совпадает с быдлокодом, как вы выразились, из документации:
Я вижу наличие параметра
Что такое фронтенд-валидация для капчи — мне совсем не очевидно. Вы не указали, генерируете ли капчу самостоятельно или нет, что валидируете (например, соответствие множеству допустимых символов), что передаете на клиент для валидации капчи.
Из rails очень много лишнего повыкидывали в процессе его развития. При этом есть огромное количество библиотек. Из интересных для валидации видел html5_validations и rails4_client_side_validation (ранее просто client_side_validations).
Можно посмотреть, как это делается на rails: railscasts.com/episodes/263-client-side-validations?view=asciicast. Подход смешанный: некоторые проверки выполняются на клиенте и на сервере (но описываются в коде единожды), другие — с ajax-запросом, т. к., например, требуют обращения к db для выполнения (уникальность email/username).
public function actionCreate()
{
$model=new User;
if(isset($_POST['ajax']) && $_POST['ajax']==='user-form')
{
echo CActiveForm::validate($model);
Yii::app()->end();
}
......
}
Я вижу наличие параметра
enableClientValidation (который выключен в примере с SO, на который вы сослались ниже). Несмотря на скудную документацию, похоже, что оно должно работать в простейших случаях (как, например, gem client_side_validations для rails «из коробки»).Что такое фронтенд-валидация для капчи — мне совсем не очевидно. Вы не указали, генерируете ли капчу самостоятельно или нет, что валидируете (например, соответствие множеству допустимых символов), что передаете на клиент для валидации капчи.
Из rails очень много лишнего повыкидывали в процессе его развития. При этом есть огромное количество библиотек. Из интересных для валидации видел html5_validations и rails4_client_side_validation (ранее просто client_side_validations).
Можно посмотреть, как это делается на rails: railscasts.com/episodes/263-client-side-validations?view=asciicast. Подход смешанный: некоторые проверки выполняются на клиенте и на сервере (но описываются в коде единожды), другие — с ajax-запросом, т. к., например, требуют обращения к db для выполнения (уникальность email/username).
Вся суть в том, что я ни о чем не забочусь.
Ничего не передаю. Это все — забота фреймворка. Я, конечно, посмотрел как там сделано — передается хеш капчи.
Генерирую не самостоятельно, а просто во вью пишу «вывести капчу».
Я, кажется, потерял нить спора. Я говорю, что в php фреймворке yii фронтенд валидация из коробки. Правила описываются единожды, а фреймворк генерирует js код. Причем для этого controller не надо менять, если это не серверная валидация.
А вы говорите, что php отстой. Ну… я это знаю, потому давно уже не пэхэпэшник.
Ничего не передаю. Это все — забота фреймворка. Я, конечно, посмотрел как там сделано — передается хеш капчи.
Генерирую не самостоятельно, а просто во вью пишу «вывести капчу».
Я, кажется, потерял нить спора. Я говорю, что в php фреймворке yii фронтенд валидация из коробки. Правила описываются единожды, а фреймворк генерирует js код. Причем для этого controller не надо менять, если это не серверная валидация.
А вы говорите, что php отстой. Ну… я это знаю, потому давно уже не пэхэпэшник.
То, что описывается в этом посте — это ajax-валидация. Как способ, описываемый в посте, так и имеющийся в Yii требуют дополнительных телодвижений (костыли, описываемые в посте даже больших).
Валидация на клиенте, которая есть в Yii «из коробки» принципиально не отличается от той, что предоставляется gem'ом client_side_validations (т. е. клиентский код для стандартных валидаций генерируется фреймворком). Т. е. с тем же успехом можно сказать, что в Rails это «из коробки» (достаточно поставить gem, выполнить 1 команду и добавить 1 строчку в layout). Ajax-валидация с этим gem'ом проще чем в Yii, т. к. не требует вообще никаких дополнительных телодвижений.
Стоит сказать, что с PHP я сталкивался во времена 3 версии, что, в общем-то, было давно. Тогда это было более ужасно. И то, что там появляются нормальные фреймворки может улучшить средний уровень поделок в интернетах.
Валидация на клиенте, которая есть в Yii «из коробки» принципиально не отличается от той, что предоставляется gem'ом client_side_validations (т. е. клиентский код для стандартных валидаций генерируется фреймворком). Т. е. с тем же успехом можно сказать, что в Rails это «из коробки» (достаточно поставить gem, выполнить 1 команду и добавить 1 строчку в layout). Ajax-валидация с этим gem'ом проще чем в Yii, т. к. не требует вообще никаких дополнительных телодвижений.
Стоит сказать, что с PHP я сталкивался во времена 3 версии, что, в общем-то, было давно. Тогда это было более ужасно. И то, что там появляются нормальные фреймворки может улучшить средний уровень поделок в интернетах.
Я уже очень долго не пишу на php. Сейчас с рабочего компьютера нет доступа к старым проектам. Но там как-то так.
Наверное я не полностью откровенен.
Да, для аякс валидации нужно иметь метод на сервере, который бы обрабатывал эту самую валидацию. Не обязательно что-либо изменять, можно его создать отдельно. Но мы же говорим о клиентской валидиции без какого-либо общения с сервером. В таком случае контроллер изменяить не надо.
Да, для аякс валидации нужно иметь метод на сервере, который бы обрабатывал эту самую валидацию. Не обязательно что-либо изменять, можно его создать отдельно. Но мы же говорим о клиентской валидиции без какого-либо общения с сервером. В таком случае контроллер изменяить не надо.
и вот еще насчет валидаций: Прекратите использовать regexp для email!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Rails: ajax-валидация в стиле DRY