Комментарии 23
Ничего, что бы отвечало этим требованиям, я найти не смог.
Похоже, что здесь еще присутствовало неявное требование web-интерфейса. Потому что непонятно, почему не рассматривался Qt.
В любом случае здорово.
Смотрите, я вам сразу обозначу грабли. То, что вы делаете — это CRUD-генератор. Идея в целом хороша, но есть одно но.
При разработке подобных штук вы неизбежно упретесь в дихотомию "гибкость-порог вхождения". Иными словами, если вы сделаете простой инструмент, который позволяет делать подобные CRUD-интерфейсы быстро, то он будет негибким. Что это значит? Это значит что на сравнительно простых задачах (накидать CRUD для простенькой БД) ваши юзеры будут пищать от восторга. Однако, когда к ним придет капризный клиент и понадобится сделать что-либо выходящее за задуманную вами функциональность (ну например клиент захочет концептуально другой дизайн, или там… я не знаю… скрывать кнопочку "сохранить" в зависимости от хитрых параметров валидации, или в конце концов рисовать поней в ячейке датагридов) — то тут-то ваши юзеры повесятся, потому что возможности глубокой кастомизации вы, скорее всего, не предусмотрите. Это нормально — вы же делаете простую вещь, так?
Но это не трагедия. Трагедия вот в чем. Если вы решите-таки сделать возможность глубокой кастомизации, сядете и тщательно нарисуете архитектуру, предусмотрев кучу extension points для таргет-юзера, то порог входа в вашу библиотеку неуклонно поползет вверх и для более-менее массового использования вы будете вынуждены писать тонны документации. И далеко не факт что ваши таргет-юзеры захотят в ней копаться.
Но в целом — удач вам и успехов :)
(чуть подумав) Проблема так же известна как "шаг влево/шаг вправо — расстрел". Самое узкое место у пользователей будет возникать, когда надо изменить ну вот совсем маленькую фиговинку. Хоть ту же поняшу добавить. Очень, знаете ли, обидно из-за фичи вроде как на 2 минуты работы отключать стандартный интерфейс и пилить все на angular-е. Ну то есть я говорю о кейсах, на которые разработчик смотрит и думает — о, да тут работы должно быть на полчаса максимум. А когда пытается это по факту сделать — то получается целая эпопея.
По поводу проблем CRUD ориентированных интерфейсов можно вот эту статейку попробовать почитать: https://cqrs.wordpress.com/documents/task-based-ui/
Если кто похожее чего порекомендует, буду признателен.
Это очень актуальный вопрос. Такая проблема ярко выражена в Django Admin, почему я и отказался от его использования для ряда задач. Разрабатывая фреймворк, я старался минимизировать её влияние.
Как я писал в статье, фреймворк предоставляет возможность выбора: разрабатывать интерфейс либо его часть быстрее (но менее гибко) либо функциональнее (но медленней).
В фреймворке предусмотрена разработка интерфейса либо его части на нескольких уровнях. На каждом последующем уровне увеличивается время разработки, но добавляется гибкость:
- Генерация всего интерфейса автоматически.
- Генерация отдельных частей интерфейса автоматически.
- Полная ручная кастомизация интерфейса или его части.
Поэтому ситуация, когда среди автоматически сгенерированных элементов нужно разместить на форме нестандартные элементы или элементы в произвольном порядке, решается давольно просто. Пример такой кастомизации: https://github.com/astoniocom/astonio-shop/tree/master/src/app/flow-record-window
Если в Django для кастомизации используется подход "внедряемся и меняем", то у меня используется подход "собираем заново из кирпичиков", причем кирпичиком может быть как самописная, так и встроенная часть. Также для решения проблемы с порогом входа применяются принципы разработки приложений на Angular. Как итог, даже при полной кастомизации интерфейса технически внедрить свои элементы — задача с низким порогом входа (хотя от него, безусловно, никуда не деться).
Я говорю как раз о моменте, когда "видит око, да код неймет". Т.е. ты видишь какую-то фичу, которая визуально должно реализовываться просто, но по факту осознаешь, что надо собирать все из кирпичиков.
Я сделал что-то подобное на C#, да и дошел примерно до того же. Все закончилось, к слову, написанием собственного движка клиентского шаблонирования. Как говорится, we need to go deeper. И у меня как раз получилось так, что ради сложной кастомизации надо не собирать решение из кирпичиков, а разбирать готовое, потом собирать обратно. Как подход — рекомендую. Think about it :)
Для подобных целей использовал activeadmin. Из коробки более-менее нормально кастомизируется с помощью DSL.
2 If DB like ODBC & OS=Windovoz THEN MS Access
3 If DB like JDBC & OS != Windovoz THEN OpenOffice Base
2) Почему angularJS? так исходники используют на Angular 4.
Поиск решения для быстрого создания интерфейсов СУБД