Комментарии 5
Идея прекрасная, но реализация пугает, одно <?=$js_main?> чего стоит.
Это бы в виде нормальной библиотеки оформить, тогда использовать приятнее будет в проектах.
Это бы в виде нормальной библиотеки оформить, тогда использовать приятнее будет в проектах.
Т.е. основная мысль — генерация клиентской валидации на сервере? Весьма интересно, надо обдумать.
Позволю себе несколько замечаний/предложений:
1. Зачем передавать в правилах текст сообщений? Проще их хранить в свойстве объекта Validate.
2. Наверное лучше заменить в объявлении свойств private на protected — так можно будет расширять класс.
3. Прилагаемая в примере форма не поддерживает редактирование сохраненных данных — поля заполняются только данными из $_POST. Сразу возникает и следующий вопрос — при редактировании лучше проверять только измененные свойства (экономим время).
4. В идеале сообщения об ошибках должны показываться рядом с соответствующими контролами.
5. Генерацию js можно попробовать реализовать через шаблоны и плейсхолдеры — должно быть более читаемо.
Позволю себе несколько замечаний/предложений:
1. Зачем передавать в правилах текст сообщений? Проще их хранить в свойстве объекта Validate.
2. Наверное лучше заменить в объявлении свойств private на protected — так можно будет расширять класс.
3. Прилагаемая в примере форма не поддерживает редактирование сохраненных данных — поля заполняются только данными из $_POST. Сразу возникает и следующий вопрос — при редактировании лучше проверять только измененные свойства (экономим время).
4. В идеале сообщения об ошибках должны показываться рядом с соответствующими контролами.
5. Генерацию js можно попробовать реализовать через шаблоны и плейсхолдеры — должно быть более читаемо.
Мне встречалась валидация по такому принципу в одном php-шном фреймворке. Это действительно удобно. Конечно есть свои исключения, просто потому что не всё возможно проверить на клиенте, но тем не менее, программисты были избавлены от рутинной работы и не было дублирование логики на 2х языках, а значит легче изменить валидацию.
Вообще не самая лучшая идея.
Давно известно, что системы генерирующие формуляры проверки на клиенте страдают несколькими проблемами:
1. сложность смены поведения валидатора на уровне клиента. Например, алерты не устраивают
2. сложность подключения собственного JS внутрь сгенерированного
3. ну и стандартные проблемы — строковые (мультиязычность)
поэтому многие команды, успешно забивают на эти вопросы и разрабатывают для каждой платформы отдельный валидатор :(
Давно известно, что системы генерирующие формуляры проверки на клиенте страдают несколькими проблемами:
1. сложность смены поведения валидатора на уровне клиента. Например, алерты не устраивают
2. сложность подключения собственного JS внутрь сгенерированного
3. ну и стандартные проблемы — строковые (мультиязычность)
поэтому многие команды, успешно забивают на эти вопросы и разрабатывают для каждой платформы отдельный валидатор :(
В ответ на ваши замечания по пунктам:
1. и 2. в примере видно, что способ интерпретации правил генератором не задаются, а вся реализация заключена в Javascript классе Validate, что позволяет настроить процесс валидации по желанию
3. Не совсем понял о чем вы, валидатор будет высвечивать только те сообщения, которые вы туда передали, а зависимости от того, на каком языке эти сообщения, не вижу. Если вы говорите о проблеме валидации непосредственно строк как входных данных, то тут при использовании UTF-8 особых заморочек нет.
1. и 2. в примере видно, что способ интерпретации правил генератором не задаются, а вся реализация заключена в Javascript классе Validate, что позволяет настроить процесс валидации по желанию
3. Не совсем понял о чем вы, валидатор будет высвечивать только те сообщения, которые вы туда передали, а зависимости от того, на каком языке эти сообщения, не вижу. Если вы говорите о проблеме валидации непосредственно строк как входных данных, то тут при использовании UTF-8 особых заморочек нет.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Полноценная валидация данных