Есть одна типичная проблема, характерная для 98% веб-проектов, для которой, поразительно, нету полноценного решения

Есть одна типичная проблема, характерная для 98% веб-проектов, для которой, поразительно, нету полноценного решения. Рассказываю идею на миллион долларов :)

Проектирование нередко рассматривается в контексте преобразований данных из одной структуры в другую. Такие преобразования называют отображениями или представлениями. В результате появляется возможность построения сложных систем путем модульного комбинирования простых преобразований. Но к сожалению популярные языки программирования слабо поддерживают такие преобразования, что лишает их соответствующего потенциала, а ФП пока остаётся больше экзотикой.

Итак, архетипическая проблема: связь между сервером и пользовательской формой на клиенте. Концептуально, это просто вопрос отображения внутренней структуры данных на структуру экранной формы — а затем обратное отображение пользовательского ввода на внутреннюю структуру сервера. Ну например на бэке есть класс Employee с полями id, ФИО и год рождения, и мы хотим вводить/менять ФИО и год через форму GUI.

Челлендж заключается в том, что и определение данных в модели сервера, и макет формы могут меняться. Структура данных будет меняться в связи с изменением требований. Макет формы будет подстраиваться под добавление новой функциональности и удобство использования "презентации". Вот эти изменения и ставят перед нами дилемму.

Если мы создаём форму на основе данных — рендерим её на сервере, то легко приспособиться к изменениям в данных на бэке, но трудно организовать изменения в форме.

С другой стороны, мы можем разорвать связь между данными и формой, сохранив их как независимые артефакты, и таким образом будет легко настроить форму. Да, но теперь изменение данных на сервере потребует ручной правки формы. Фронтендеры могут сильно озлиться :)

Последний вариант — это стандартный подход (например, MVC), рассматривающий экранную форму как независимо поддерживаемый артефакт (представление). Чтобы справиться с изменениями данных в реалтайме, в форме реализуется некое "связывание", которое втягивает поля данных и отсылает введённые пользователем значения обратно. Некоторые UI-фреймворки предлагают т.н. двунаправленное связывание между моделями и представлениями. Для этого, например, используются всяческие темплейты с интерпретируемым кодом вроде эскейп-последовательностей, rich-клиенты на JS, которые подтягивают значения с сервера в нужные места и в нужное время.

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

Засада в том, что такую модификацию клиента практически нереально автоматизировать, если на нём активно используется JavaScript. Конечно хотелось бы некоего рефакторинга, который автоматически вносил бы соответствующие изменения в форму. Однако такие рефакторинги должны быть достаточно легко "вычислимыми" и надёжными. Удачи в этом, поскольку связывание и "экранирование" в таких случаях возможно выразить только на языках, полных по Тьюрингу )))

=

Язык форм в идеале должен быть каким-то ограниченным DSL, узким языком специального назначения, по Алану Кэю. Именно такой подход используется например в разработке, управляемой моделями (Model-Driven Development, MDD), где модели, специфичные для конкретной области, определяются декларативно (Не путайте это с ORM, в котором мы описываем модели "декларативно" как классы). MDD подразумевает т.н. "круговой инжиниринг", который заключается в отображения изменений в одной модели на другие (и на представления) с сохранением их согласованности. MDD основан прежде всего на концепции соответствующих преобразований, которые отображают изменения между независимыми артефактами.

Увы, но MDD тоже быстро ломается на совсем простых и типичных ситуациях. Вот например что я хочу от языка форм:

- сопровождение иерархии контейнеров на форме для управления отображением полей. Например, разделение формы на две панели, расположенные рядом друг с другом с соответствующим выравниванием.

- изменение порядка следования полей внутри контейнера: например, перемещение поля почты в правую панель, созданную как говорилось чуть выше, и перемещение поля id сразу после поля почты

- переименование меток полей, например, "id" в "user_id".

Такие возможности должны быть доступны всегда, на протяжении всей эволюции моделей: добавление новых полей (которые должны появляться внутри формы, сохраняя заданный порядок относительно других полей, которые не были явно перемещены) и переименование полей (которое не должно иметь никакого эффекта, кроме замены соответствующих меток).

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

=

Засада в том, что подобные подходы, сами по себе вполне обычные и естественные, вносят хаос в те шаблонные способы, которыми мы обычно выражаем структуры данных в популярных языках. Но почему? почему бы не создать нечто подобное, достаточно простое? Ведь с этой проблемой сталкивается 98% веб-проектов.

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

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

Мы получим очень приятный результат: вместо того, чтобы строить систему как набор артефактов с тонкими внутренними взаимозависимостями, которые необходимо поддерживать вручную, мы можем создать по отдельности и затем соединить вместе набор модульных преобразований. Причём артефакт определения данных может быть персистентным: удобнее даже будет хранить историю изменений (рассматриваемых как преобразования), начиная с пустого. Мы выигрываем, потому что преобразования модульные, в отличие от структур, которые они порождают.

=

Понимаю, что всё написанное выше неформально, и какого-то прямо чёткого способа решения не видно. Этой теме для курсантов в СильныхИдеях скоро будет посвящён большой материал (думательная машинка по модульному мышлению), но в любом случае, предлагаю вам отдельно поэкспериментировать с этим на практике, сделать например для своих проектов соответствующую библиотечку или мини-фреймворк. Поизучайте MDD, что там сейчас происходит, на гитхабе по Model-Driven Development выдаются сотни репов, наверняка конкретно о вышеупомянутой проблеме хоть кто-то задумывался :)

Хотя преимущественно выдаётся что-то подобное =>

"DTT is an object-oriented Java framework that enables developers to automatically create database tables based on domain models... DTT is an object-oriented Java framework that enables developers to automatically create database tables based on domain models..."

этакая ещё более непрозрачная версия ORM, ну....

Посмотрите фреймворк Mateu, вроде неплохое, активно развивается.

Источник: vk.com

Комментарии: