Концепция типов документов. Когда формы создаются без единой строчки кода

Автор: DileSoft
Источник: habrahabr

Что самое страшное в веб-программировании? Что есть бич сайтов и радость хакеров? Правильный ответ: проверка входных данных.

Входные данные — самая страшная вещь на свете. Возьмем, например, обычное текстовое поле ввода. Совершенно очевидно, что просто вывести его на страницу недостаточно. Надо еще:

1) Проверить, что в это поле хоть что-то ввели (если оно обязательное).
2) Проверить, что в поле не слишком мало символов.
3) Проверить, что в поле не слишком много символов.
4) Проверить, что в поле использованы только те символы, которые разрешены (например, для логинов).
5) Проверить, что данные в поле соответствуют шаблону (например, для емейлов).

И только после этого, наверное, можно наконец записать поле в БД. Что тоже может привести к ошибке — если, к примеру, БД отвалится.

И не стоит забывать, что о каждой из этих ошибок надо сообщить пользователю уникальным текстом.

И не стоит забывать, что эти проверки надо выполнять, и при добавлении, и при редактировании данных. Причем некоторые проверки при этом будут меняться (например, что мы редактируем объект с существующим ID), а некоторые — нет.

И не стоит забывать, что такие проверки надо делать для каждого поля.

И не стоит забывать, что типов полей много, а типов данных, которые вводятся в эти поля — еще больше.

Уфф. Чем дальше, тем страшнее. А можно ли избежать всей этой мороки? Можно. Если использовать концепцию типов документов.

Насколько мне известно, данную концепцию сейчас используют как минимум две фирмы. Первая — «Инфодизайн». Вторая — «Солинг», где я в последнее время работал и в которой познакомился с этой концепцией.

Что же эта за концепция такая? Первый ее тезис такой — любой объект, который хранится у нас на сайте, это не строчка в БД, а документ. В документ входит строчка в таблице БД, связанные с ней данные в других таблицах, связанные файлы на сервере (например, картинки от аватар пользователя) и код, который всё это обрабатывает.

Далее. Документ состоит из полей документа. Поле — это неделимый элемент данных. Например, 6 HTML-полей ввода для даты и времени создания документа, плюс код, который проверяет, что каждое из 6 заполнено правильно, плюс несколько ячеек в базе данных, где это дата-время хранится на сервере — это одно поле.

Логично, что у каждого поля документа есть тип. В предыдущем абзаце было описано поле типа «дата и время». Есть и другие типы — «строка», «число», «галка», «один из списка значений», «пароль» и т. д. Типов полей может быть великое множество — например, существует тип «таблица», умеющий подгружать данные из Excel-таблиц, тип «картинка», умеющий подгружать на сервер картинки (и заодно пережимать их в нужный размер), тип «Каптча», который ничего не пишет в БД, но выдает ошибку, если каптча не угадана и так далее.

Впрочем, с «великим множеством» я, пожалуй, переборщил. Реально требуется полтора десятка типов полей, чтобы сконструировать форму для практически любой задачи.

Это была теория. Перейдем к практике.

Итак, нам надо создать сложную форму. Например, форму данных в профиле. Возьмем для примера созданный нами сайт peopleid.ru с обширнейшим профилем (более 25 полей!):

    

Что мы сделали, чтобы создать этот профиль? Мы не написали код ни для одного из конкретно этих полей ввода. У нас уже были готовые типы полей документа. Поэтому мы создали один файл:



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

Посмотрим повнимательнее на файл описания документов (правильнее сказать, файл типа документа).

(Извините за пробелы в тегах — хабрадвижок глючит).

Итак, в теге < doctype >  описывается название документа и в какой таблице он хранится. Также там может быть атрибут "changetime_field", который указывает поле в таблице, в которое пишется дата последнего обновления документа. Это удобно для кэширования.

Тег < field > — это описание поля типа документа. Атрибут "name" используется в названии HTML-поля ввода и поля (или полей) в БД. "type" — тип поля. Есть еще "primary_key", указывающий, что данное поле есть ID.

Внутри описания поля могут быть свойства. Например, свойство < property name="min_length" >3< /property > указывает, что в данное текстовом поле нельзя записать меньше 3 трех символов. Если пользователь попытается это сделать, сгенерированный код это заметит и выдаст пользователю соответствующую ошибку. Свойства зависят от типа поля — например, в поле типа «картинка» можно указать, в каких форматах пользователь может подгружать картинки. Или в какие пропорции картинку следует пережать.

Помимо этого, для поля можно указать оси. Например < axis name="avatar"/ >. Что это значит? Это значит, что при использовании документа мы можем работать не со всеми полями, а только с теми, которые обозначены одной осью. Это очень удобно в этом профиле, поскольку позволяет разбить его редактирование на 5 вкладок. А еще это удобно для разделения полномочий, когда пользователям разрешено редактировать один набор данных, а администраторам — другой. Или при добавлении документа на сайт можно отобразить минимальный набор полей, а при редактировании — полный.

Особо интересны поля типа «массив» ("array"). Это поля, который содержат множества документов другого типа. Для них в качестве свойства указывается тип документов и они позволяют нам, например, привязать к одному пользователю множество ссылок на блоги. (В документе типа "ссылка" три поля — ID, название блога и URL блога).

Всё это, повторяюсь, пишется в одном файле на простом языке. Теоретически можно даже создать красивый графический интерфейс для создания типов документов. А теперь представьте себе, если бы мы писали всё это вручную! Страшно. Очень.

А так всё было очень просто. По сути, фреймворк (движок для создания сайтов произвольного типа), созданный с использованием концепции типов документов, позволяет писать относительно простые сайты вообще без использования кода. Достаточно лишь создать страницы и привязать к ним типы документов.

Я уж не говорю о том, сколько ошибок при этом удается избежать. Повторяя первый абзац этой статьи, ошибки при проверке входных данных — самые страшные.

Скажу больше — сайты с использованием концепции типов документов даже визуально выглядят лучше. Надежность, спрятанная внутри, чувствуется даже снаружи.

Мне очень понравилось работать над созданием и использованием фреймворка с типами документов. И я хочу надеяться, что в будущем таких фреймворков будет больше.