Программист-ЛюбительЕсли данные собираются вашим энджином на основании метаинформации (динамически формируется селект) из таблиц, то такой принцип не подойдет для реальных сложных вью, процедур где сидит существенная бизнес логика. Я прдпочитаю в таких случаях брать готовый объект сервера и описывать/мапить его поля на описание метаданных. Максимум что динамически доклеивается с клитента - ORDER BY, WHERE.
Это к:
авторЧисто технически у меня не вьюшек скуля, я подразумеваю набор данных собранных по связям из различных физ табл.

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

Почти

Загрузка узлов дерева возможна из любых объектов сервера, возвращающих набор данных. На разных уровнях могут быть разные объекты. Очевидно, что при переходе на следующий уровень должна быть связь с узлом более верхнего уровня (простейший случа парент-чаилд). Каждый узел может иметь свою индивидуальную карточку в правой части формы. Карточка может иметь вложенные панели с полями, гридами, табстрипы и т.п. Все узлы дерева могут иметь в том числеи карточки одинакового типа - это простейший случай.

(покрасневший от стыда смайлик) Загрузка дерева пишется кодом на клиенте - недоделка. Описание узлов дерева и карточек всех узлов - конфигурируются. Карочка любого узла может открываться как полноценная отдельная форма. Есди необходимо собрать все однообразные узлы или конечные листики в общий набор, то используется табличная форма.

То, что у тебя мощный конструкт, я знаю - давно слежу на форуме.

LSVВсяким там скептикам и прочим льющим сарказм и желчь:
ТС всё правильно делает (про создание платформы как идея быстрой и гибкой автоматизации).
Не будем вдаваться в инженерные подробности и возможные ошибки.

Любая подобная инф. система - не более чем управление различными списками (что бы там не говорили).

Конкуренцию САПу именно в области упр. учета вполне можно составить, если оценивать именно результат автоматизации, а не надувание щёк умников в костюмчиках, отъевших хари на откатах и попилах. :)
А мне кажется обсуждаются именно инженерные детали, причем вполне конструктивно. Что как раз и уместно на этом форуме.

ViPRos,
Сделать можно все. Не получается все сразу
У меня гораздо актуальнее был общий/универсальный конфигуратор - существющие возможности удовлетворяли темпы разработки прикладного функционала, а бизнес-специализированные конфигураторы. Если прикладной блок большой/сложный я делаю под него специализированный конфигуратор (на универсальном )
Типа:
Конфигуратор тикетов
Конфигуратор доверенностей
Конфигуратор специальной отчетности для надзорных органов
и т.п.

Когда мало ресурсов всегда выбираешь наиболее горячие задачи.

И потом, я же покраснел.

Замечание справедливое, я ни в коем случае не воспринимаю его как упрек. Я ж и сам вижу где внутри "слабина".

Если б кто спросил на какой платформе сделан мой фреймворк, то-то было бы смеху...

ViPRos, я вечером из дома принсткрин приложу.

egorych, Интригу поломал...