Pull to refresh

Comments 23

Круче всех по построению интерфейсов я видел, когда работал в НТЦ «Сонар-Плюс». Там карточки всех объектов могли строиться самостоятельно по БД. То есть поле само знало какого оно типа, с какой ещё таблицой оно связано (можно было ограничивать запросами), добавлять связную таблицу или карточку непосредственно к объекту, сохранять/восстанавливать всё это дело… То же самое касалось и связанных таблиц, которые можно было разместить на одном экране. В общем — полная свобода действий (а ещё оно масштабировалось как в браузере — это уже я делал :) ). Пример, увы, приложить не могу, т.к. давно там не работаю, но старую версию можно посмотреть здесь (извините за ссылку). Я работал в основном уже с GUI версией. По-моему, её демо можно скачать вот здесь. Кстати, сам я тоже работаю с Django, так что большое спасибо за статью!
Ничего, что бы отвечало этим требованиям, я найти не смог.

Похоже, что здесь еще присутствовало неявное требование web-интерфейса. Потому что непонятно, почему не рассматривался Qt.

В любом случае здорово.

Да, действительно, требование веб-интерфейса присутствовало (добавил в статью).
Qt не рассматривался как по этой причине, так и потому, что он, вроде, не позволяет автоматически генерировать интерфейс на основании моделей.

Когда у меня была похожая задача я взял Dvelum. Остался доволен.

Смотрите, я вам сразу обозначу грабли. То, что вы делаете — это CRUD-генератор. Идея в целом хороша, но есть одно но.
При разработке подобных штук вы неизбежно упретесь в дихотомию "гибкость-порог вхождения". Иными словами, если вы сделаете простой инструмент, который позволяет делать подобные CRUD-интерфейсы быстро, то он будет негибким. Что это значит? Это значит что на сравнительно простых задачах (накидать CRUD для простенькой БД) ваши юзеры будут пищать от восторга. Однако, когда к ним придет капризный клиент и понадобится сделать что-либо выходящее за задуманную вами функциональность (ну например клиент захочет концептуально другой дизайн, или там… я не знаю… скрывать кнопочку "сохранить" в зависимости от хитрых параметров валидации, или в конце концов рисовать поней в ячейке датагридов) — то тут-то ваши юзеры повесятся, потому что возможности глубокой кастомизации вы, скорее всего, не предусмотрите. Это нормально — вы же делаете простую вещь, так?
Но это не трагедия. Трагедия вот в чем. Если вы решите-таки сделать возможность глубокой кастомизации, сядете и тщательно нарисуете архитектуру, предусмотрев кучу extension points для таргет-юзера, то порог входа в вашу библиотеку неуклонно поползет вверх и для более-менее массового использования вы будете вынуждены писать тонны документации. И далеко не факт что ваши таргет-юзеры захотят в ней копаться.
Но в целом — удач вам и успехов :)

(чуть подумав) Проблема так же известна как "шаг влево/шаг вправо — расстрел". Самое узкое место у пользователей будет возникать, когда надо изменить ну вот совсем маленькую фиговинку. Хоть ту же поняшу добавить. Очень, знаете ли, обидно из-за фичи вроде как на 2 минуты работы отключать стандартный интерфейс и пилить все на angular-е. Ну то есть я говорю о кейсах, на которые разработчик смотрит и думает — о, да тут работы должно быть на полчаса максимум. А когда пытается это по факту сделать — то получается целая эпопея.

По поводу проблем CRUD ориентированных интерфейсов можно вот эту статейку попробовать почитать: https://cqrs.wordpress.com/documents/task-based-ui/


Если кто похожее чего порекомендует, буду признателен.

Я такое и реализовал у себя в Lattice. Демок пока нет, лично могу показать реализацию.

Это очень актуальный вопрос. Такая проблема ярко выражена в Django Admin, почему я и отказался от его использования для ряда задач. Разрабатывая фреймворк, я старался минимизировать её влияние.


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


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


  1. Генерация всего интерфейса автоматически.
  2. Генерация отдельных частей интерфейса автоматически.
  3. Полная ручная кастомизация интерфейса или его части.

Поэтому ситуация, когда среди автоматически сгенерированных элементов нужно разместить на форме нестандартные элементы или элементы в произвольном порядке, решается давольно просто. Пример такой кастомизации: https://github.com/astoniocom/astonio-shop/tree/master/src/app/flow-record-window


Если в Django для кастомизации используется подход "внедряемся и меняем", то у меня используется подход "собираем заново из кирпичиков", причем кирпичиком может быть как самописная, так и встроенная часть. Также для решения проблемы с порогом входа применяются принципы разработки приложений на Angular. Как итог, даже при полной кастомизации интерфейса технически внедрить свои элементы — задача с низким порогом входа (хотя от него, безусловно, никуда не деться).

Я говорю как раз о моменте, когда "видит око, да код неймет". Т.е. ты видишь какую-то фичу, которая визуально должно реализовываться просто, но по факту осознаешь, что надо собирать все из кирпичиков.
Я сделал что-то подобное на C#, да и дошел примерно до того же. Все закончилось, к слову, написанием собственного движка клиентского шаблонирования. Как говорится, we need to go deeper. И у меня как раз получилось так, что ради сложной кастомизации надо не собирать решение из кирпичиков, а разбирать готовое, потом собирать обратно. Как подход — рекомендую. Think about it :)

Дело, мы сделали так же. Дошли до дизайнера интерфейсов.
Easy easy, real talk :)

Братюни.
К слову, люди из JS-сообщества, как показала практика, вообще не признают проблематику, поднятую в статье

Для подобных целей использовал activeadmin. Из коробки более-менее нормально кастомизируется с помощью DSL.

UFO just landed and posted this here
1 If DB = Oracle THEN Oracle + APEX
2 If DB like ODBC & OS=Windovoz THEN MS Access
3 If DB like JDBC & OS != Windovoz THEN OpenOffice Base
1) Посмотрел код, сразу удивился, что используется прямое подключение к базе из клиента. Как мне его перебросить в интернет?
2) Почему angularJS? так исходники используют на Angular 4.
Если все таки из готового, то может рассмотреть ODOO?
UFO just landed and posted this here
UFO just landed and posted this here
Вот бы ещё дизайна добавить, а то выглядит как привет из 90-х
UFO just landed and posted this here
Only those users with full accounts are able to leave comments. Log in, please.