Проблема с обработкой форм заключается в том, что она по определению нарушает MVC. Это проблема, известная как «сквозное пересечение», и в прошлом она изучалась наукой. Документ Веб-разработка на основе домена с помощью WebJinn, например, интересно почитать по теме.
В качестве примера подумайте об отношении форм к различным уровням MVC:
Модель:
- Формы копируют информационную структуру вашей модели предметной области (DM). Если вы изменяете эту структуру (например, добавляя поля в структуру данных или добавляя параметры в процедуру), вы также должны адаптировать формы для ввода этой информации.
- Им нужна информация о типе от вашего DM, чтобы преобразовать входные данные в требуемые там типы.
- Им необходимо знать ограничения, указанные в вашем DM, чтобы подтвердить ввод.
- В идеале они считывают и записывают данные непосредственно из/в ваш DM (например, читая/записывая поля структуры данных или вызывая процедуру в DM с отправленными значениями в качестве параметров).
Контроллер:
- Формы получают отправленные данные и отправляют их в DM.
- Они изменяют ход программы в зависимости от того, успешно они проходят проверку или нет.
Просмотр:
- Формы отображаются как сложная структура HTML-тегов и атрибутов, которая зависит от всего вышеперечисленного (должно ли поле быть обязательным? должны ли отображаться ошибки? как упорядочить поля? какие варианты выбрать в раскрывающемся списке? и т. д.)
Следовательно, невозможно написать механизм абстракции формы, который не затрагивал бы все эти уровни. Решение, наоборот, состоит в том, чтобы структурировать саму библиотеку форм в соответствии с MVC, на разные уровни и подкомпоненты, которые выполняют SRP. Если вы посмотрите на компонент формы Symfony2, он делает это очень хорошо. ;)
Так почему же это такой «огромный страшный зверь»? Первая проблема связана с абстракцией. Например, подумайте о простом раскрывающемся списке. Если мы хотим повторно использовать код раскрывающегося списка, нам нужно как-то его абстрагировать. Теперь проверьте список выше, даже этот простой ввод затрагивает все три уровня приложения MVC. Как можно абстрагироваться от чего-то, что должно быть разделено на три разные части?
Вторая проблема — разнообразие функций. Библиотеки форм никогда не решают всех проблем, с которыми разработчики сталкиваются в своей повседневной жизни. Таким образом, все эти уровни и механизмы абстракции должны быть расширяемыми, чтобы вы могли заставить их вести себя именно так, как вы хотите.
Будучи расширяемым, компонент Form уже решает сотни крошечных проблем, о которых вам больше не нужно даже думать. Как вводить даты, как выбирать один или несколько вариантов из списка с использованием различных пользовательских интерфейсов (раскрывающиеся списки, флажки, переключатели и т. д.), как снова защищать формы от недостатков безопасности и многое другое — это темы, на которые я мог бы написать эссе. о.
Вы видите, что библиотеки форм оказываются довольно сложными. Лучшее, что мы можем сделать при написании таких «огромных страшных зверей», — сделать их API как можно более простым для начинающих, максимально гибким для более продвинутых пользователей и написать обширную документацию по использованию его полной мощности. Последний пункт определенно все еще отсутствует (пожалуйста, помогите!), но мы постоянно работаем на все вышеперечисленное.
Свести сложную задачу к простой, к сожалению, невозможно.
А как насчет других библиотек форм, которые намного проще? По моему скромному мнению, они даже не пытаются решить большинство проблем, которые компонент Symfony2 Form уже решает за вас. :)
Обновление от 24 января 2014 г. Для всех, кто хочет узнать больше (намного больше), вот документ, который я опубликовал на эту тему.
person
Bernhard Schussek
schedule
19.04.2013
