Помню, как более 10 лет назад, я бился с тем, как быстро создать интерфейс для ввода данных в базу данных и отображения их через браузер. На то время, еще был популярен Google Web Toolkit и было несколько открытых библиотек виджетов к нему, по функционалу догоняющие и иногда превосходящие десктопные Swing компоненты. Сейчас на меня юные фронтэндеры посмотрят как на динозавра, как можно писать фронтэнд на Java и тем более как до такого тогда докатился Google, который перевел позже Android разработчиков на Kotlin, а GWT отдала сообществу на поддержку. Всему виной были тяжбы с Oracle за Java API на мобилках и из-за копипасты с Apache Harmony.
На тот момент казалось что еще чуть-чуть и приблизится сингулярность для веб фронтэнда "кровавого энтерпрайза"
Могу выделить проект SmartGWT (фактически это GWT обертка для smartclient javascript библиотеки) и Sencha GXT, полностью написанный на GWT. Тогда обе библиотеки были доступны без оплаты(за исключением их более навороченных корпоративных версий). Были же времена, ээх! Археология она такая...
Про сериализацию и передачу данных между фронтом и бэком можно было не думать, GWT делал магию, как и с биндингом моделей на компоненты.
На рабочем проекте мы с коллегами сделали админку на SmartGWT, а на работе в издательстве "За Рулем" и позже в авиакомпании я использовал GXT. Достаточно сложные интерфейсы разрабатывались и тестировались на одном языке. К слову первые версии IDE Eclipse Che тоже были на основе GWT, а это почти как IntelliJ Idea в браузере!
По возвращении к этой задаче, я ожидал обнаружить революцию в сфере создания веб-интерфейсов. Ведь с появлением low code и no code платформ, а также активным развитием open source сообществ, популярностью JavaScript на github, казалось, что задача генерации интерфейса из БД или объектной модели станет гораздо проще. Однако, реальность оказалась несколько иной. На бэкэнде, базах данных и в big data ситуация гораздо лучше с возможностями бесплатных и открытых проектов, когда не надо покупать лицензии или платить за дополнительные компоненты, можно без СМС и платных подписок запустить хоть Ingenuity на Марс.
Наиболее примечательным оказалось отсутствие open source решений, которое бы предоставляло мне всю необходимую гибкость и контроль. Большинство существующих инструментов предоставляли готовые шаблоны и компоненты для создания интерфейса, но в случае отступления от Hello World сценария, виден недостаток возможностей для расширения или функционала который был из коробки в GXT.
Когда просто проверяешь свою идею, то самое важное - это скорость изменений и простота реализации функционала. Не надо следовать лучшим практикам разработки, не стоит думать как интефейс будет выглядеть на старых айфонах и будет ли работать в IE с используемым polyfill'ом.
В плане прототипирования идеи, мне импонирует подход Naked objects, когда весь интерфейс - это просто отображение доменной модели. Реализовать просто, выглядит убого но зато быстро и дешево! Apache Causeway, вышел из апачевского инкубатора в Isis, его ребрендировали и он дожил до наших дней, обновляется и появляются новые фичи. Но, я честно, не готов возвращаться в эпоху Java Server Faces с их фреймворком Apache Wicket!
На какие проекты я смотрел:
https://github.com/ToolJet/ToolJet
https://github.com/directus/directus
https://github.com/marmelab/react-admin
https://github.com/jmix-framework/jmix
ToolJet - подкупил «зведностью» и тем что я когда-то на него смотрел с интересом. В итоге на моей небольшой базе данных PostgreSQL в сотню мегабайт все тормозило до перезагрузки контейнера. Поигравшись понял что надо что-то менять и залазить "под капот" после чтения документации, к тому же не завелись мои hstore и массивы из БД.
Directus создал в моейсхеме пару десятков своих таблиц directus_* и работал получше ToolJet, но при ошибке с таблицей без ключей, с помощью него я ее нечаянно дропнул через интерфейс. Та же история с не поддерживаемыми типами данных и неявные ошибки.
react-admin - я отмёл на этапе чтения его документации, когда базовый grid компонент мне не подходит, но нужные функции по фильтрации и сортировкам есть в платной версии. Я не уверен что хочу платить за фреймворк, который может захочу выкинуть через неделю наигравшись с прототипом.
Jmix это ребрендированная Cuba платформа, мне понравилось как они переписали виджеты на React, что достаточно функциональный UI. И для прототипов энтерпрайз приложений на проекте когда-нибудь работодатель купит лицензию или я успею разобраться в 28 триальных дня лицензии на Jmix Studio IDE, но не в этот раз!
Остались на проверку:
https://github.com/Budibase/budibase
https://github.com/appsmithorg/appsmith
https://github.com/openblocks-dev/openblocks
Еще мысли вслух про JSON Forms. Видел этот подход раньше с XSD Schema и каждая компания переизобретала свой генератор форм. Казалось бы теперь все отлично. А вот я не совсем уверен...
Впечатления, что "Nо trials, nо fees, nо taxes Nо card needed fоr the premium access" это не про разработку фронтэнда и я начал подозревать почему пьют смузи фронтэндеры.
В итоге, не выдержал и начал %овнокодить на чистом JavaScript. Признаться, я все забыл что даже умел раньше, но все равно иду к своей цели быстрее, чем пытаясь разобраться в очередной платформе и понять что нужно там подшаманить, чтобы появилась нужная мне форма, табличка, график и т. п. И дело пошло! У меня нет проблем с REST API к моей базе благодаря PostgREST(кому-то удобнее Hasura), то время что я трачу на JavaScript и то чтобы разобраться с виджетами, просто рассматриваю как инвестицию в будущее, хотя возможно Copilot будет удовлетворительно CRUDошлепить гораздо раньше этого!
Комментарии (57)
sshikov
23.08.2023 18:06+3Про сериализацию и передачу данных между фронтом и бэком можно было не думать, GWT делал магию, как и с биндингом моделей на компоненты.
Самое смешное, что Flex позволял примерно тоже самое. Ну то есть, можно было создать объектную модель на Java, и сгенерировать из нее модель на ActionScript. И нарисовать на MXML некий несложный (или сложный) UI, который мог из коробки практически работать с сервисами, экспортируемыми в виде EJB. И я правда нынче далек от фронтенда, но когда приходится к нему приближаться, то что я вижу, меня не вдохновляет. Потому что по ряду параметров не дотягивает до Flex.
stgunholy
23.08.2023 18:06-5Те же самые мысли... И ещё - зачем этот TS обрубок сейчас, если AS3 10 лет назад позволял делать всё тоже самое...
igor_suhorukov Автор
23.08.2023 18:06+3Ээх, прогресс UI со времен Flash и Delphi не такой бурный как в бэкэнде и нейросетях
ImagineTables
23.08.2023 18:06Можно поинтересоваться, а почему вообще задача стоит именно так: сначала накидываем БД (надо полагать, SQL), потом — генерируем интерфейс? Почему нельзя наоборот — взять low-code/no-code платформу (например, SharePoint), создать БД в ней (автоматически получая интерфейс), а уже потом подключать к ней свой бэк через OM и делать всё необходимое?
Выбор, правда, невелик — кроме SharePoint на ум ничего и не приходит.
igor_suhorukov Автор
23.08.2023 18:06+6Данные обычно переживают приложение, фронт меняется а бэк матереет. В моем случае когда объемы данных от сотни мегабайт в прототипе до терабайт в целевом решении, то лучше сразу идти от модели данных.
В случае же с проприетарным SharePoint пространства для развития и возможностей не так много.
mayorovp
23.08.2023 18:06+1Как хранилище данных шарик ужасен. Поверьте, я работал с ним в этом режиме...
igor_suhorukov Автор
23.08.2023 18:06А я работая рядом с людьми, которые на нем почти сделали проект и из-за ошибки для которой не нашли обходного пути не могли завершить проект. Причем компания была золотым партнером MS и имела приоритеты в заявках
Tzimie
23.08.2023 18:06А какая ошибка? Расскажите
igor_suhorukov Автор
23.08.2023 18:06Это был 2007 год. Технических подробностей не помню, я не SharePoint разработчик. Но отлично запомнил вопли команды, нескончаемые митинги, эскалации рядом с моим рабочим местом меня сильно отвлекали от моей бессмысленной работы по мэпингу хранимок MSSQL в Hibernate ORM и это была воля заказчика...
ImagineTables
23.08.2023 18:06Там всё заминировано, и наступить на мину не просто, а очень просто. Например, есть (был?) таймер 30 секунд, по окончании которого плагину (аналогу хранимки) настаёт секир-башка. Но, в отличие от хранимки, нет никакой транзакционности. Разумеется, всё это не документировано, и выяснять приходилось опытным путём. Выше изложена причина, по которой проект пришлось отменить у нас: выяснилось, что транзакционность изменений обеспечить не получается, а без неё — данные клиентов превращаются в страшное месиво.
(Как можно не уложиться в 30 секунд — если в API не предусмотрены пакетные изменения для какого-то сценария (UPDATE… WHERE), приходится гонять данные запись за записью, открывая каждый раз соединение, на железе недорогого хостера хватает десятков тысяч записей).
Мой вопрос был не конкретно про ШП, а про low-code/no-code в целом. Да и сам ШП мог улучшиться, десять лет прошло, как-никак.
mayorovp
23.08.2023 18:06Мда. Этот таймер — особенность даже не шарика, а раннего ASP.NET, и как его отменять давно известно. Решение когда-то гуглилось по запросу "ASP.NET long running request" и заключалось в вызове одного метода который отодвигает срабатывание таймера; сейчас его найти сложнее (исключительно из-за того что под ASP.NET сейчас понимается Core-версия без этой особенности).
Вот с пакетными операциями и транзакционностью всё и правда "весело".
Да и сам ШП мог улучшиться, десять лет прошло, как-никак.
Ну-ну :-)
ImagineTables
23.08.2023 18:06Я, возможно, неудачно выразился. Дело было не в том, что мы не побороли какой-то таймер, а в том, что к этому моменту настало осознание, куда мы забрели. И было принято мужественное решение переписать всё на SQLCLR, работая непосредственно с таблицей AllUserData в SQL Server, оставив от SharePoint формы, типы, представления и т.п.
Что касается форм, типов и представлений (интерфейса и идеологии), они мне и сейчас нравятся. Сама идея универсальной мультиклиентной СУБД с GUI нравится больше, чем генерация GUI из SQL БД. Отсюда и взялся мой вопрос.
mayorovp
23.08.2023 18:06+1Вряд ли там дело было именно в ошибке, в конце концов ошибки либо исправляются, либо обходятся. Даже если это NRE в глубинах Шарика, всё равно можно понять условия его возникновения по трассировке стека и декомпилированному коду, в этом нет ничего сложного. Хотя если вместо программирования там пытались получить помощь от MS — ничего удивительного что ничего не получалось.
Хуже то, что EAV тормозит. Поначалу незаметно и к его лагам привыкаешь, но, по мере усложнения запросов, неустранимых тормозов становится всё больше и больше. Смотря на страницу, которая открывается 10 секунд, чувствуешь себя тем самым серийным программистом.
Ещё хуже если напарываешься на фундаментальные ограничения. Если нужно скомбинировать полнотекстовый поиск и обычную фильтрацию — ты проклят. Они делаются в двух разных базах, и единственный способ их скомбинировать — это сделать поиск по одной базе и передать список идентификаторов в другую. Скорее всего ещё и транзитом через фронт, потому что к беку в шарике хочется притрагиваться как можно меньше.
Помню тот день, когда впервые на проекте сумели вынести часть данных в отдельную БД. Это выглядело таким чудом: целых два гигабайта данных, а поиск по ним не тормозит!
ImagineTables
23.08.2023 18:06Даже если это NRE в глубинах Шарика, всё равно можно понять условия его возникновения по трассировке стека и декомпилированному коду, в этом нет ничего сложного.
Вот я тоже так думал, когда мне понадобился калькулятор выражений (функции и операторы, поддерживаемые для вычисляемых полей), идентичный натуральному. (Надо было именно получать абсолютно такой же результат, что и ШП, имея формулу и список значений — чтобы напрямую можно было работать с БД, иначе ну никак не получалось обеспечить функционал, не говоря про такие мелочи, как скорость). Я залез внутрь, чтобы посмотреть, что можно вызвать, и оказалось, что эта функциональность вообще написана не на дотнете, вызовы на каком-то этапе уходили в классическую dll, а с ней разобраться уже не так просто.
Пришлось кропотливо, шаг за шагом, воспроизводить все эти функции (а их там немало), и каждую сопоставлять и покрывать тестами.
С остальным горячо согласен.
LeshaRB
23.08.2023 18:06Vaadin...
Бесплатной версии хватает за уши
Плюс есть маркет виджетовЯ делаю админку на ней, чтоб не тратить время фронтов
kh0
23.08.2023 18:06Во! Ты мне бро! Держи в курсе! Давно об этом мечтал, чтобы у меня все было, а мне за это ничего не было!
michael_v89
23.08.2023 18:06я ожидал обнаружить революцию в сфере создания веб-интерфейсов
Так она и случилась. Только не в Java.
Если нужен веб-интерфейс к базе данных, то есть phpMyAdmin/phpPgAdmin и аналоги.
Если нужен API или веб-интерфейс для редактирования, в Yii есть кодогенерация CRUD по таблице из базы. В Symfony и Laravel тоже, хотя там есть свои особенности.Практического применения для штук типа PostgREST я если честно не вижу, если только для своих проектов. Тут вся бизнес-логика будет на клиенте. Но мне кажется, аналог для собственного использования можно написать на любом языке за пару дней.
igor_suhorukov Автор
23.08.2023 18:06+1PostgREST написан на Хаскеле и работает так отлично, что мне не пришлось изучать Хаскель и править код проекта. В случае же с Yii, Symfony и Laravel мне прийдется изучать PHP.
phpMyAdmin/phpPgAdmin
Отличный вариант для внутренних технических пользователей, тех кто боится psql. И встречал такие советы на Reddit/Stackoverflow. В моем случае phpPgAdmin не дает преимуществ перед ручными INSERT из-за типов данных.
michael_v89
23.08.2023 18:06В случае же с Yii, Symfony и Laravel мне прийдется изучать PHP.
Конечно, только статья у вас в хабе "Программирование", а в тексте вы подразумеваете только Java. Я просто сказал, что в других языках с этим получше, и там сгенерировать веб-интерфейс из БД не представляет сложности.
Если превращать прототип в реальное приложение, то в любом случае придется делать нормальное API и править код проекта.
igor_suhorukov Автор
23.08.2023 18:06JavaScript/TypeScript мне было было бы достаточно и только на фронте(без NodeJS). Все серверные заморочки на данном этапе пока не интересуют, как и Java. Java тут лишь поскольку похожий опыт был на ней больше 10 лет назад.
А вот с PHP по опыту работ на масштабах начинаются свои сложности, так что вариант с Yii, Symfony и Laravel "на вырост" не предлагайте пожалуйста!
michael_v89
23.08.2023 18:06+1Вы не поняли, я не предлагаю это вам, я говорю, что ваше утверждение "Революции в сфере создания веб-интерфейсов не случилось, сгенерировать веб-интерфейс из БД сложно" неверно. Случилось и несложно.
Судя по описанию, у вас вообще какой-то крайне специфичный кейс, когда нужен веб-интерфейс, но не нужен сервер. У большинства другие цели, для которых прямой доступ к базе данных с клиента не подходит. Они пользуются инструментами, которые это обеспечивают, они есть для всех распространенных языков.
michael_v89
23.08.2023 18:06Есть такой проект Retool. Это конструктор приложений, позволяет подключаться к БД или Rest API и создавать UI. Есть много UI-компонентов. Подходит например для случаев когда менеджеры хотят сделать себе какой-то интерфейс, но не хотят отвлекать программистов от основных задач. Конечно платный.
igor_suhorukov Автор
23.08.2023 18:06Да, я смотрел на него. Опять же не понятно зачем платить для разовой задачи и насколько он лучше ToolJet/ Openblocks/ Appsmith ?
BugM
23.08.2023 18:06У Оракла был/есть неплохой проект ADF. Это самой близкое приближение к почти автогенерации типичного круд интерфейса к БД. Изысков там нет, но типовые штуки неплохо получаются.
igor_suhorukov Автор
23.08.2023 18:06Теперь Apache Wicket выглядит не таким уж устаревшим в сравнении с ADF. Еще вспоминаю OracleForms и проект на котором его нужно было перенести на более современные технологии.
BugM
23.08.2023 18:06Формсы для своего времени тоже неплохи были. Жаль что все заброшено. Для типичных админок когда писать много кода не хочется и при этом Сваггера уже не хватает что-то такое выглядит оптимальным вариантом.
igor_suhorukov Автор
23.08.2023 18:06
rPman
23.08.2023 18:06Майкрософтовский windows forms для .net и соответствующая поддержка этих классов (DataSet и Bindings) для asp.net, и все это работает из WYSIWYG редактора даже не стоит упоминания? Появилось как раз 10 лет назад, потом как я понимаю развитие в wpf, ну а сейчас немного сломано майкрософтом, но все еще поддерживается, в т.ч. в веб.
igor_suhorukov Автор
23.08.2023 18:06Это же проприетарная технология, тем более в закате своих дней как вы описываете.
forthuse
23.08.2023 18:06+1Ведь с появлением low code и no code платформ, а также активным развитием open source сообществ
Как вариант, предположу, что близко к такой функциональности по тематике статьи может быть в рассмотрении проект HiAsm — Конструктор программ по сумме идей и возможностей в нём реализованных?
Визуальные элементы интерфейса — это зачастую адаптированные компоненты из Delphi|FreePascal на одном рабочем поле с "бизнес" компонентами составляющих логику
работы схемы при взаимодействии с пользователем.P.S. Правда сам автор проекта, возможно к нему охладел как неокупаемый свои
трудозатраты на него, но форум и сообщество ещё живо, но нет активно как ранее.igor_suhorukov Автор
23.08.2023 18:06Так это же про схемы? Я успешно работал с drawio, который развивается и поддерживает разные виды диаграм, море интеграций итп. Но моя задача, что описал в статье - иная
forthuse
23.08.2023 18:06+1Там не только основная своя концепция визуального программирования, но и возможность программно, в разных вариантах при поддержке в пакетах требуемого языка программирования расширять функционал возможных решений.
К, примеру, С# уже отдельным разработчиком поддержан в рамках следования общим
идеям заложенных в авторский проект.P.S. "Сложно" даже представить как на Бейсике делались самопальные системы заводского бухгалтерского учёта на переломе 80-х годов на 386-х DOS компьютерах в основных аспектах понимания реляционных баз c разбивкой их данных на таблицы и визуального отображения и ввода данных в табличные формы при их контроле. :)
Структура взаимосвязи таблиц и полей в них описывалась отдельно и при выводе
данных система автоматически их форматировала по размерам ячейки.igor_suhorukov Автор
23.08.2023 18:06Спасибо, необычный проект! Судя по репозитарию он не развивается с 2016 года. А web IDE c 2017. Концептуально напомнило мне Delphi.
forthuse
23.08.2023 18:06Да, интересный, но по нему даже сообщество не сделало публичных статей например на Хабр, что тоже, думаю, не добавило популярности, востребованности и узнаваемости этого проекта при достаточности документации и снятых видео роликов по нему.
P.S. Репозитрий на Github это авторский заход на переписываниe HiAsm на Си также
как и на JavaScript для компонентов Web. т.к. базовые Паскаль исходники он публично не размещал начиная с какой то версии ~20 лет давности.
… Сам сайт и форум проекта, по озвученной информации сделан на самом же HiAsm.
Batalmv
23.08.2023 18:06Посмотрите в сторону BPM систем. Они в основном за деньги, но есть и опен сорс
Там правда паровозом идет и построение решения на их принципах, но это иногла неплохо и даже хорошо
igor_suhorukov Автор
23.08.2023 18:06Почитайте "Все что вы хотели узнать о BPM, но боялись спросить", я разделяю мнение с @sshikov Как здорово что все мы здесь сегодня собрались!
Batalmv
23.08.2023 18:06Попробую вкратце. Из моего опыта почти все проекты были не слишком удачными. Т.е. задача решена, но дороговато и требует поддержки большого и редкого скиллсета в команде
Причины:
Часто начинают не с оптимизации процессов, а с давайте автоматизируем то, что сейчас (doing shit faster). Уже тут можно лавочку закрывать, но на другой технологии бвло бы тоже самое
Часто заказчик просит добавить очень важные фичи которые требуют кастомного кода в большом количестве, хотя фича больше похожа на изобретение своего велосипеда с многоугольными колесами
-
Часто команда внедрения не ищет путь через штатный функционал, а вот мы ща тут накодим ....
В целом, добавляя или нет BPM в стек,я принимаю решение на основании того, могу ли я собрать паззлик так, чтобы остаться в штатном функционале системы. Если не выходит, не беру либо аккуратно саботирую
НО это просто инструмент, я ж не агитирую
andrey_nado
23.08.2023 18:06+1Прочитав статью я не понял суть проблемы, стоявшей перед автором. Поэтому мой комментарий может быть нерелевантным.
В общем случае, объектная модель, реализованная на back-end не может быть без изменений перенесена на front-end. Для последнего всегда создаются какие-нибудь views. Исключение - это всякие специфичные CRUD-интерфейсы, вероятно у автора что-то такое?
Писать на GWT и ему подобном может казаться быстрым, пока не случится какая-нибудь непонятная проблема (например баг в реализации, баг в браузере, недокументированное поведение компонента и пр.). На поиск проблемы может уйти всё сэкономленное время, а решение и вовсе может не найтись. Всё же лучше использовать отдельные инструменты для back- и front-end.
igor_suhorukov Автор
23.08.2023 18:06+1Задача - создать несколько CRUD для существующей БД. В основном это гриды с сортировкой, страничками и формы для создания новых записей в эти таблички. Есть пара нетипичных моментов связанных с виджетом для выбора значений(уже набросал работающий черновик в стиле дельфишко-кода).
В общем случае, объектная модель, реализованная на back-end не может быть без изменений перенесена на front-end.
В общем случае да, но тут как и в Naked Objects я контролирую БД и могу немного подрихтовать схему чтобы просто проверить идеи прототипа.
Мне некогда городить слой DTO/VO на сервере, делать все идеологически правильно на Redux со стейтом. Не та история, несколько экспериментов, большая часть просто проверить идею и выбросить код после для неудачных.
GWT я и не собираюсь воскрешать, я его привел в пример уровня сложности виджетов и возможностей для энтерпрайз систем. Как "протекают" абстракции я много раз в своем опыте видел, в том числе и в google web toolkit.
Так что пока чистый JavaScript оказался быстрее... Хотя казалось бы столько людей сталкиваются с похожими задачами создания CRUD по схеме базы данных и уже столько времени прошло с эпохи GWT.
michael_v89
23.08.2023 18:06+1Так есть же генераторы DTO классов. Все ими и генерируют.
igor_suhorukov Автор
23.08.2023 18:06Есть и мэперы между доменными объектами и DTO... Был у меня был опыт работы в проекте, где большая часть кода была по перекладывания из/в protobuf, а не бизнес логика. Рядом был их собственный аналог gRPC. Знаю эту лишнюю сложность и не хочу ее на этом этапе. Код ради кода в моем случае не нужен, напомню про PostgREST. Максимум вьюшку или хранимку создать.
leha_gorbunov
23.08.2023 18:06+1Вот такой еще велосипед есть https://platformerp.ru
правда для MySQL, а не PostgreSQL .
CRUD, фильтрация, сортировка, добавление, удаление, простые формочки из коробки.
igor_suhorukov Автор
23.08.2023 18:06Спасибо! Я не разобрался какая лицензия, есть ли исходники итп ?
vagon333
23.08.2023 18:06+1После похожих терзаний написал свою платформу data driven среды разработки.
Начал в 2017, спустя 6 лет платформа вышла на плато надежной среды с необходимым функционалом backend и набором контролов frontend.
Сейчас создаю ндежные веб-приложения, допольно сложные с т.з. архитектуры.
Вывод - иногда легких путей нет.igor_suhorukov Автор
23.08.2023 18:06+1Начинал подобное еще в эпоху GWT для ускорения своей работы и успешно забросил, уйдя в бэкэнд/бигдату.
Расскажите про свой опыт, интересно. Может публикацию сделаете и сравните с альтернативами из Open Source?
vagon333
23.08.2023 18:06Думаю, часть решений может быть интересны.
Все собираюсь поделиться, но не знаю с чего начать. За 30 лет в IT никогда не писал. :)
Может посоветуете, с чего начать?igor_suhorukov Автор
23.08.2023 18:06+2Вы же автор, не мне вам советовать)
Я бы составил такой примерный план:
Какие задачи может решать ваш фреймворк. Как упрощает разработку. Какие ограничения и область применимости к моделям данных, объемам, типам данных.
Сравнения с подобными OpenSource/low code решениями. Как лучше всего "продать" программисту, какие его проблемы легко решает, а где может создать новую проблему(абстракция же где-то "протекает")
Что является входными данными и как описывать метаданные для кастомизации процесса генерацию списков/форм. Есть ли подгрузка сущностей связанных по ключу, поиск из больших объемов данных, динамические визуальные фильтры.
Какие компоненты доступны в UI и их биндинг с серверной частью (протоколы, сериализация, возможность подключать endpoint).
Как вызывается бизнес логика фреймворком?
Возможности визуализации и отчетности.
Диаграмма развертывания, аудит доступа, технические логи, репортинг ошибок фреймворка(что отлавливается во время компиляции/загрузки, а что во время исполнения), отладка и тестирование решения
Планы развития фреймворка, поддержки новых форматов данных, технологий и т.п.
igor_suhorukov Автор
23.08.2023 18:06+1Ну и демо, в духе SmartClient здорово бы систематизовало все ваши наработки
proman1968
23.08.2023 18:06+1Есть еще такое...
https://odajs.org/igor_suhorukov Автор
23.08.2023 18:06Спасибо! Судя по коммитам, вы один из соавторов вместе с Ильей. Глянул пару видео, посмотрел что проект не обновляется с прошлой осени.
Можете рассказать в двух словах как его применить на существующую схему в PostgreSQL или REST сервис.
ryoko_sha
23.08.2023 18:06Из статьи так и не понял, а чем же не устроил для описанной задачи Jmix? В версии 2.0 и крайнюю версию 24 Vaadin прикрутили.
VGoudkov
Vaadin? Не то чтобы no-code, но концепцию "щас повесим на on-click бизнес-логику" позволяет реализовать замечательно. А так да... для того, чтобы это вот всё завелось, нужна рядышком ролевая модель и метаданные, какие поля в какой таблице что означают на бизнес-языке, и куда по какой связи ходить можно ... и при каких условиях... и кому... и где и как создавать новые записи. Была такая SugarCRM, которая этот концепт неплохо так развила
igor_suhorukov Автор
Vaadin мне больше нравится чем Wicket, но все же раньше уже делал выбор в сторону других GWT фреймворков, которые не навязывали свою модель. Задача то у меня проще чем ту что пытаются решать на Vaadin и Jmix... И REST API у меня уже автомагически есть из базы данных! Получается все серверные заморочки с фреймворками для этого прототипа лишние.