Здравствуйте, Shmj, Вы писали:

S>Неужели никто ничего не придумал?
Я таких велосипедов несколько видел.
Публичный на сколько помню Гедемин, остальные коммерческие типа Искрам или внутри-корпоративные разработки.


Проблемы которые ты не видишь:
1. Данные.
1.1 Если данных мало,то все пучком. С увеличением объемов тормоза увеличиваются в геометрической прогрессии.
Вот пример на картинке, если бы была такая форма в базе, где гигабайтные таблицы (уточняю гигабайтная не база, а таблицы), то разраба утопили бы в туалете.
1.2.Если мы говорим о профессиональной разработке, то разрабатывать нужно структуру данных в профессиональной среде, с профилированием планов и тд. Если в своем конструкторе то инструмент д/б не хуже профессионального. Такое проектирование как в примере подойдет для студенческой разработки или для прототипов.

2.Интерфейс.
Конструкторы имеют очень большой минус, когда разрабатывается форма не попадающая в шаблон используемоей логики, вот тогда наступает полная жопа.
На начальном этапе все быстро, круто, но !!! Приходит ТЗ от заказчика и в нем сортировка, отрисовка не такая как в стандарте, доп функционал на кнопочках или в гриде и все! Сели в лужу.
Разработка нестандартных форм сливает в унитаз всю скорость начальной разработки.
Поэтому появляются несколько базовых конструкторов и их все больше и больше и наступает вторая жопа разбираться в этой тьме базовых шаблонов. И просто так подправить что то в шаблоне нельзя!!! На его основе наваяли кучу форм.

Итог:
Самое оптимальное решение, это шаблонное наследуемое проектирование.
Написал 1 раз шаблон, любой сложности, скопировал его, переименовал и прямо в форме вносишь любые изменения и они нигде не аукнутся.

Вот ты написал, сколько времени понадобится сделать аналогичную форму.
1-й раз, да, понадобится время, второй раз аналогичную нужно только копирование и время "причесать форму" не такое и большое, где то час, где то 4, а если совсем аналогичная, то вообще времени не надо.

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

PS: Это все подходит только для прототипов или простых систем учета.

Здравствуйте, Shmj, Вы писали:
S>Может и не велика, но когда форма вот такая:

S>Image: ServiceCenter_Main.jpg

S>т.е. когда есть 6 других таблиц, связанных с данной — то представьте сколько времени уйдет на создание такой формы. Нужен не только просмотр, но и добавление/редактирование данных. Вручную забембаешься поля вводить — даже если по 1 мин. на каждое — уже дня 2 уйдет.

S>Вот вы бы за сколько времени создали такую форму вручную? Притом что форма должна не просто быть, но еще и связана с данными — с 7 разными таблицами + еще словари (около 10). Путем конфигурации это делается максимум за час. Сколько у тебя уйдет на ручное написание?
Вот прямо спасибо за отличный пример.
Эта форма — тупик цивилизации. Программисту она может казаться даже красивой — полное доминирование математической модели над здравым смыслом. Нормальному человеку эта форма кажется ужасной.

Проектирование нормальных приложений идёт не от структуры данных, а от сценариев. Что люди делают с этой "формой"? Ищут заказы, создают новые заказы, изменяют существующие? Ответ "всё это, и ещё 12 действий из контекстного меню" не подходит — надо разобраться во всех из них. Классифицировать пользователей по ролям, для каждой роли знать относительные частоты всех сценариев.
Для каждого из сценариев прояснить основной успешный вариант и две-три самых популярных вариации — то есть прямо по шагам "смотрим на XXX, делаем YYY". Для каждого неуспешного сценария выяснить предлагаемые шаги по исправлению проблемы.
Внимательно изучить данные, которые нам нужно показать пользователю на каждом шаге каждого сценария, и данные, которые нужно у пользователя запросить.
Данные для показа приоритизировать. Запрашиваемые у пользователя данные нужно изучить под микроскопом на предмет того, как избежать их запроса вообще; если нельзя избежать — то минимизировать то, что спрашиваем; то, что осталось — валидируем мягким способом, расставляем хинты. Характерный пример — создаём новый заказ. А часто ли встречается такая ситуация, что клиент повторяет свой предыдущий заказ с небольшими вариациями — то есть можно его скопировать и дать подправить; ведь это быстрее, чем плодить новый? Часто ли встречается такая ситуация, что есть популярный набор работ для каждой модели телефона, и сразу после ввода букв "6s" можно угадать, что будут заказывать?

Даже не проделав всю эту титаническую работу, одного взгляда на форму достаточно, чтобы оценить её usability.
0. Поиск заказов сделан опытным мизантропом. Вместо популярного лет 10 уже паттерна query language, который бы позволял просто искать в стиле "статус:закрыт И периодтекущий месяц)" (а заодно ставить закладки или автоматически вычислять наиболее запрашиваемые фильтры) мы имеем сочетание комбобоксов и свободнотекстового поля ввода. 1990е.
1. Список заказов выведен в грид, который вдвое шире доступного места. Либо там справа — какая-то муть, которую вообще в списке заказов показывать не надо, либо пользователь вынужден постоянно скроллить влево-вправо.
2. Все связанные сущности выведены в виде гридов на взаимоисключающих табах. Нет возможности увидеть одновременно работы и материалы. WTF? Ведь очевидно, что для работы "замена экрана на S9" есть стандартный набор материалов, без которых она невыполнима. Нет, пусть пользователь потеет, ручками вбивает пары "работа-материал" в разные табы.
3. Всё, чего может быть больше одного, засовывается в грид, без малейшей попытки оценить распределение количества элементов. Например, у 99% заказов 0 или 1 платёж. Тем не менее, мы выделяем под них целый грид, а под него — отдельный таб. Теперь, чтобы посмотреть, оплачен ли заказ, надо кликать в него, а потом прыгать в таб. Десять баллов Слизерину.


В итоге вы за час делаете говно. Вот прямо берёте и увеличиваете объём страданий и ненависти в мире. Понятно, что можно сделать то же говно вручную, потратив неделю на раскладку гридов и кнопок по форме в том же виде.
Но речь не об этом, а о том, что можно было сделать UX примерно в 100 раз лучше безо всяких "гридов" и "табов", потратив чуть больше времени на анализ действий пользователей.
И вот такой, нормальный UX, вам не сделает никакой генератор. По крайней мере до тех пор, пока генератор собирается работать по модели данных.
Чтобы сделать хоть что-то приемлемое, генератор должен работать с моделью сценариев. Типа "пришёл клиент с новым заказом", "пришёл клиент забрать выполненный заказ", "позвонил клиент узнать статус заказа", "в процессе выполнения заказа возникли вопросы к клиенту, требующие согласования", "нужно оповестить клиента о готовности заказа". Вот с чем работает разработчик UI, и с чем должен работать генератор. А не со схемой типа "к заказу можно прицепить файлы, фотографии, платежи, работы и материалы". Да, можно. Ну и что?

Здравствуйте, Shmj, Вы писали:
S>Ну почему? У нас чувак сделал всю логику на MS SQL.
Я таких решений видел десятки.
У всех (кроме хренового качества получающегося GUI) есть одна большая проблема: то, что раньше было программой, теперь становится конфигурацией.
Ошибки в программе помогает искать IDE с её компилятором и дебаггером. Есть развитый тулчейн по контролю версий — мы всегда можем понять, кем, когда, и зачем было внесено каждое изменение; можем взять из архива исходник 2003 года и собрать его, чтобы починить багу у удалённого клиента, который не обновлялся с тех пор; можем тестировать изменение в бранче, и мёрджить в транк только проверенную версию; можем откатиться на неделю назад, чтобы исправить неверное изменение.

"Конфигурации" ничего этого не умеют. В лучшем случае они живут в текстовых файлах, которые можно засунуть в VCS.
В вашем случае они живут в базе; это означает, что вообще никто не знает, что там стоит у заказчика. Нет понятия "версия", нет blame, нет changelog, нет веток, нет confliсt resolution.
Такие решения создают больше проблем, чем решают. Пишется-то система быстро, а вот стоимость поддержки начинает зашкаливать.

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

Ранее писали: "когда разрабатывается форма не попадающая в шаблон используемоей логики, вот тогда наступает полная жопа"

Это не так. Конструктор позволяет писать на C# любые кастомные формы и открывать их в программе. При этом эти кастомные формы могут пользоваться всей инфраструктурой конструктора если требуется (например создать пункты меню не руками).
Вот реальный пример формы которую проще было сделать в дизайнере студии чем в конструкторе так как логика работы была не стандартная.
Специально для форума написал большую зелёную надпись — а можно было и бегущих красных муравьёв.



вот как форма интегрируется в конфигурацию:



Точно так же можно в коде C# подписаться на форму сделанную в конструкторе и управлять всеми её элементами (поля, вкладки, таблицы, меню). Т.е. поверх стандартной формы навешивать любую дополнительную сложную логику.
И становится понятно что это опасение напрасно: "Приходит ТЗ от заказчика и в нем сортировка, отрисовка не такая как в стандарте, доп функционал на кнопочках или в гриде и все! Сели в лужу."


кто-то писал: "Вместо популярного лет 10 уже паттерна query language, который бы позволял просто искать в стиле "статус:закрыт И период текущий месяц)" мы имеем сочетание комбобоксов и свободнотекстового поля ввода"

Есть и такой конструктор запросов:



кто-то писал: "Нет возможности увидеть одновременно работы и материалы. WTF? Ведь очевидно, что для работы "замена экрана на S9" есть стандартный набор материалов, без которых она невыполнима. Нет, пусть пользователь потеет, ручками вбивает пары "работа-материал" в разные табы.
3. Всё, чего может быть больше одного, засовывается в грид, без малейшей попытки оценить распределение количества элементов. Например, у 99% заказов 0 или 1 платёж."

Конструктор умеет отображать данные в двух представлениях: табличное и карточное. Данные ищутся в табличной части а работа с данными может быть и в таблице и в карточке. Так вот конструктор как раз позволяет по требованию заказчика оперативно поменять представление.

Представим что "Нет возможности увидеть одновременно работы и материалы" — поступило от пользователя. Вот как выглядит карточка до:



и вот как выполнено требование заказчика. В конструкторе снято 3 галки и затем перемещением мыши таблицы разложены так как укажет заказчик интерфейса. Возможно скорость и не важна но это заняло около 2 минут.



Конструкторы идеальны для решения прикладных задач и когда есть необходимость постоянной доработки или переработки интерфейса. Никто не говорит о том что на конструкторах нужно писать систему реального времени управления взлётом и посадкой самолётов.

P.S.
То что этот и похожие конструкторы "говно" — даже не поддаётся сомнению — это так! Только ручное создание и изменение форм и тысячи строк кода позволяют нам всем намазывать масло на хлеб.

Над проблемой периодически задумывался в течение многих лет. (Но не дождался такого приступа энтузиазма, чтобы броситься уже что-то кодировать.)

Из разных архитектурных вариантов подобной "среды" для себя остановился на варианте кодогенератора, который на основе структуры БД + какого-то дополнительного простого метаописания генерировал бы примерно такой же код, какой бы написал вручную сам программист. После этого код можно дорабатывать как обычно, стандартными средствами. А можно продолжать использовать генератор. При этом, возможно, придется вручную выделять из заново генерируемого кода нужные куски и вставлять их в нужные места основного кода. Скорее всего, при желании можно будет изолировать автоматически генерируемый код от подвергаемого ручным правкам.

Вроде бы это вписывается в термин "scaffolding". (Он используется почему-то только в веб-программировании, до которого я пока не добрался.)

Плюсы подхода особенно хорошо проявляются, если ты — наёмный программист в чужой конторе:
+ поддерживающие код после тебя не столкнутся с незнакомой и загадочной для них "средой" или "фреймворком" — везде самый обычный код.
+ в случае, если начальство и коллеги являются противниками всяких велосипедных метаинструментов, можно им ничего не говорить — просто нагенерировать себе кода и далее работать с ним, при необходимости легко зачистить все следы от присутствия своего кодогенератора. И в VCS можно коммитить только сгенерированный код.
+ как вариант, ты автоматизируешь только свою собственную работу и получаешь профит или хотя бы конкурентное преимущество.

При написании инфосистем под заказ такой подход тоже оправдан: чем отдавать самому заказчику "средства конфигурирования", не лучше ли периодически (а лучше — систематически) брать с него денежку за поддержку?

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

P.S. под WPF кое-что есть, сам пока не смотрел: https://stackoverflow.com/questions/704337/scaffolding-for-wpf-using-mvvm

P.P.S. Совсем забыл про вариант "Model first", когда сначала набрасывается "метаописание" (возможно, в некоей "визуальной" или табличной тулзе, т.е. не в чисто-текстовой форме), а из него генерится и сама БД, и код. С возможностью реверса БД в модель. А ведь я как-то раз все же начинал кодировать свой велосипед — именно по этому варианту.

Здравствуйте, yukosoft, Вы писали:

Y>Специально для форума написал большую зелёную надпись — а можно было и бегущих красных муравьёв.
Image: core15.jpg
Вы не понимаете, о чём я пишу, увы.
Чисто для контекста: первую такую систему авто-генерации гуя по БД лично я написал в 1991 году на Clipper. И с тех пор наблюдаю возрождение этой идеи с завидной регулярностью.
То есть дело не в том, что я не понимаю, как это работает — я этот этап уже прошёл.

Y>кто-то писал: "Вместо популярного лет 10 уже паттерна query language, который бы позволял просто искать в стиле "статус:закрыт И период текущий месяц)" мы имеем сочетание комбобоксов и свободнотекстового поля ввода"
Y>Есть и такой конструктор запросов:
Y>Image: core12.jpg
Вы неверно понимаете мои аргументы. Дело не в конструкторе или деструкторе запросов. Речь о сценарии работы. Давайте рассмотрим подробнее паттерн, о котором я говорю.
Когда я ищу письмо в аутлуке, я могу написать просто

brent

Это мне найдёт все письма, где брент — отправитель, или получатель, или упомянут в тексте.
Если писем слишком много, я могу уточнить запрос вот так:

from:brent

Мне не надо возить мышкой, чтобы строить предикат типа "Атрибут: скролл-скролл-скролл-скролл... Имя Отправителя. Операция: клик-клик... равно содержит. b-r-e-n-t". Я просто пишу текст.
Я могу уточнить поиск, написав (опять в тексте! Безо всяких кликов, драг-н-дропов и прицеливаний в выпадающие окошки)

from:brent AND sent:August 2019

При этом, естественно, работает автодополнение.
Что это мне даёт? Всю мощь работы с текстом: то есть я могу редактировать запрос при помощи copy-paste. Автодополнение помнит мои запросы, поэтому если я часто ищу закрытые заказы, то достаточно набрать "ст", чтобы поиск предложил мне дополнить его до "статус:закрыт". И все остальные варианты запроса, вроде "статус:закрыт И закрыт>неделя назад", "статус:закрыт И закрыт:сегодня" тоже показаны прямо тут, достаточно пару раз нажать "вниз" и enter.

В чём преимущество? В пологой кривой обучения: вначале работы всё, что я умею — вводить буковки в поле ввода. Когда я осваиваю "конструктор фильтров", построенный в виде тех самых кнопочек/дропдаунов, то он строит именно текст — и если сначала я выбирал фильтр "закрытые за неделю" через меню, то через пару дней я уже запоминаю, как это пишется. Система подстраивается под меня, и в итоге я получаю доступ к фильтрам, актуальным именно для меня, буквально за пару кликов. Независимо от количества условий. Очень легко делать функции типа "сохранить как именованный фильтр", как это сделано в той же Jira.

Y>Конструктор умеет отображать данные в двух представлениях: табличное и карточное. Данные ищутся в табличной части а работа с данными может быть и в таблице и в карточке. Так вот конструктор как раз позволяет по требованию заказчика оперативно поменять представление.

Y>и вот как выполнено требование заказчика. В конструкторе снято 3 галки и затем перемещением мыши таблицы разложены так как укажет заказчик интерфейса. Возможно скорость и не важна но это заняло около 2 минут.
Y>Image: core14.jpg
Ок. А стало ли лучше? Во-первых, всё ещё кто-то должен сесть, и "заказать интерфейс". То есть проделать всю ту работу по проработке сценариев, про которую я говорил.
Во-вторых, потом надо ещё и выразить эти сценарии в терминах блоков конструктора. Вот вы за две минуты "решили" задачу "показать одновременно платежи, работы, и материалы".
Начнём с платежей. Они по-прежнему свалены в таблицу. Занято дочерта места (~7 строк) под бессмысленные заголовки, скроллбары и кнопки навигации. Это примерно как использовать рамный джип для того, чтобы тарелку с завтраком везти от кухни до дивана. В реальном UI достаточно одной строки: "Оплата: 100% (18 сентября: 2000р нал через кассу)". Если платежей несколько, то строка выглядит так: "Оплата: 100% (18 сентября: 1500р VISA, 500р нал через кассу)".
Если оплата неполная, то выглядит так: "Оплата: 25% (18 сентября: 500р нал через кассу) [+])
Таким образом, мы экономим место для действительно важных вещей на экране. Почитайте классиков — Нильсена, Тафти. У вас весь экран загажен chrome и non-data ink.

Далее — работы и материалы. В UI никак не видна связь между работами и материалами, что провоцирует на ошибки — например, есть работа по замене клавиатуры, а самой клавиатуры в заказе нет.
Неверно выполнена декомпозиция задачи. Очевидно, вместо "работ" и "материалов" должны быть "операции", которые, в свою очередь, требуют "работ" и "материалов". Попытка выразить эту идею при помощи конструктора эту идею попросту убьёт, т.к. у нас будет уже три уровня иерархии таблиц master-detail.
Очевидный способ решения — это список операций в не-табличном виде:

- замена аккумулятора: 500 р (работа: 500р, аккумулятор: 0р [+])
— замена экрана: 1100р (работа: 500р, матрица экрана: 600р [+])
[+]
Итого Работы: 1000р [Сделать скидку]
Итого Материалы: 600р

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

Основная цель — оставить на экране только то, что нужно, чтобы человек мог одним взглядом ухватить суть. Ввод оптимизирован под то, чтобы человек мог пользоваться клавиатурой — с максимальным угадыванием всего подряд. Текст является интерактивным — клик по соответствующему фрагменту открывает мини-форму редактирования, опять же нацеленную на использование клавиатуры; правый клик показывает контекстное меню типа "сделать скидку"; при вводе активно работает авто-дополнение с контекстным поиском — например, начинаем вводить "акк" и нам выпадает список совместимых с s9 аккумуляторов с их ценами).

Y>Конструкторы идеальны для решения прикладных задач и когда есть необходимость постоянной доработки или переработки интерфейса.
Скорее наоборот: использование конструкторов гарантирует необходимость постоянной доработки или переработки интерфейса.
Y>То что этот и похожие конструкторы "говно" — даже не поддаётся сомнению — это так! Только ручное создание и изменение форм и тысячи строк кода позволяют нам всем намазывать масло на хлеб.
Конструкторы, на самом деле, хорошая и правильная идея. Проблема — в их ориентации на структуру данных, а не на пользовательские задачи. При этом выбор выразительных средств крайне ограничен: для списков у нас есть только "грид", а он хорошо работает для очень специфических данных.

Кроме того, основная критика всё же не в адрес конструкторов, а в адрес авто-генераторов.
Конструктор подразумевает хоть какое-то участие человека, который может попытаться применить здравый смысл и дополнительные знания — например о том, что в типичном заказе 200 строк "деталей" и только 1 платёж, а не наоборот.

Автогенератор ничего этого не знает, он видит список с кардинальностью 0..∞, и хреначит его в таблицу. Он видит набор из 30 свойств у объекта, и хреначит их всех в колонки. У него нет данных о том, какие свойства являются важными, а какие — нет; какие используются редко, а какие — часто. В итоге получаем разрежённые гриды, которые одновременно показывают слишком много всего и слишком мало всего.
Прикладной программист начинает приносить структуру в жертву богу конструктора. Например, он интуитивно понимает, что колонки "Фамилия, Имя, Отчество" — это какой-то треш, подавляет их вывод в генератор атрибутами, и придумывает вычисляемое свойство ФИО, которое клеит всё вместе, борется с лишними пробелами при отсутствующем отчестве, и изобретает специальный контрол, который используется для ввода такого "композитного" свойства.

Всё это время стоило бы потратить на дополнительные исследования реальной задачи — как раз чтобы знать, что встречается часто, а что — редко. Less is more — идеальный UX должен как показывать как можно меньше мусора, и задавать как можно меньше вопросов.

Здравствуйте, yukosoft, Вы писали:

Y>Конструкторы идеальны для решения прикладных задач и когда есть необходимость постоянной доработки или переработки интерфейса. Никто не говорит о том что на конструкторах нужно писать систему реального времени управления взлётом и посадкой самолётов.

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

Надо изучить этот конструктор, поработать с ним некоторое, понять и простить его концепции и особенности. Но зачем это надо опытному разработчику? Ему это будет просто неинтересно, ведь есть более популярные и привычные средства разработки.

При этом иногда все-равно надо дорабатывать формы "руками". Как это сделает человек, обученный только работе в конструкторе? Ему сначала придется пройти долгий и нелегкий путь до опытного разработчика.

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

Здравствуйте, yukosoft, Вы писали:

Y>кто-то писал что это реклама... На форуме программистов рекламировать конструктор который не продаётся это реклама?

Подтверждаю, с автором даже не знаком.

Расскажите подробнее сколько времени ушло на написание и планируете ли продавать?

Вот поиск текстом



Выбор работ и товаров это 10% от всех возможностей. И если конструктор поможет сделать 90% работы а остальные 10% нужно будет сделать "руками" то это ли не то ради чего всё делается?
Если от заказчика поступает запрос на неудобство работы с товарами и работами и он требует переделать всё на такую систему:

— замена аккумулятора: 500 р (работа: 500р, аккумулятор: 0р [+])
— замена экрана: 1100р (работа: 500р, матрица экрана: 600р [+])
[+]
Итого Работы: 1000р [Сделать скидку]
Итого Материалы: 600р

то обсуждается сроки и стоимость и делается такая система подбора в кастомной форме. И это не мешает использовать конструктор.

Опытному разработчику конструктор не нужен. Он нужен опытному руководителю.

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

Этот конструктор просто как пример одного из многих (просто мало кто готов показать свои велосипеды и смотреть как тычут пальцем — "говно").
Подобный конструктор пишется за 2-3 года и затем дописывается всю его жизнь.

Здравствуйте, yukosoft, Вы писали:

Y>Вот поиск текстом

Но это же все фичи компонентов DevExpress. Если делать эти формы в студии, будет всё тоже самое.

Y>Этот конструктор просто как пример одного из многих (просто мало кто готов показать свои велосипеды и смотреть как тычут пальцем — "говно").
Y>Подобный конструктор пишется за 2-3 года и затем дописывается всю его жизнь.

А сколько новый сотрудник въезжает в работу, прежде чем перестает задавать уточняюшие вопросы?

A>А сколько новый сотрудник въезжает в работу, прежде чем перестает задавать уточняюшие вопросы?

Это зависит от изначальной "стоимости" нового сотрудника и от его опыта. Если есть минимальный опыт работы с таблицами в любой базе данных то разобраться можно за месяц испытательного срока.

Здравствуйте, yukosoft, Вы писали:

Y>Это зависит от изначальной "стоимости" нового сотрудника и от его опыта. Если есть минимальный опыт работы с таблицами в любой базе данных то разобраться можно за месяц испытательного срока.

То есть стоимость сотрудника все-таки имеет значение? А то я изначально понял, что любой человек с улицы сразу начнет клепать по форме в час.

Здравствуйте, Sinclair, Вы писали:

S>Проектирование нормальных приложений идёт не от структуры данных, а от сценариев. Что люди делают с этой "формой"? Ищут заказы, создают новые заказы, изменяют существующие? Ответ "всё это, и ещё 12 действий из контекстного меню" не подходит — надо разобраться во всех из них. Классифицировать пользователей по ролям, для каждой роли знать относительные частоты всех сценариев.
Да, всё так. Но это работа не программиста, а аналитика, проектировщика интерфейсов. Уже после всей этой работы разработчик и получает ТЗ в виде конкретного экрана/формы и его дело его реализовать.
Дело же не в той конкретной форме. Мысль Shmj о том, что интерфейсы (которые предположим что уже обдуманы аналитиком и проектировщиком интерфейсов) проще и быстрее конфигурировать чем программировать ручками.
Более того во многих случаях, когда платформа позволяет, аналитики в состоянии вносить изменения в интерфейсы, не привлекая программистов.

Здравствуйте, MadHuman, Вы писали:
MH>Да, всё так. Но это работа не программиста, а аналитика, проектировщика интерфейсов. Уже после всей этой работы разработчик и получает ТЗ в виде конкретного экрана/формы и его дело его реализовать.
MH>Дело же не в той конкретной форме. Мысль Shmj о том, что интерфейсы (которые предположим что уже обдуманы аналитиком и проектировщиком интерфейсов) проще и быстрее конфигурировать чем программировать ручками.
MH>Более того во многих случаях, когда платформа позволяет, аналитики в состоянии вносить изменения в интерфейсы, не привлекая программистов.
Ну, вообще-то исходная мысль Shmj была ровно о том, что интерфейс должен возникать сам из описания структуры данных, безо всяких там аналитиков.
Если же мы отказываемся от этой мысли, то у нас остаётся что? Собственно, реализация интерфейса. Он строится из каких-то кусочков, кирпичиков.
Кирпичики укладываются в формы, свёрстанные определённым образом.
Где лежит граница между программированием и конфигурированием? Вон, ещё в Delphi можно было быстро накидать контролов на форму, понастраивать свойства, привязать их друг к другу и получить работающее приложение, не написав ни строчки кода.

1. Внесение изменений "на лету". То есть при визуальном программировании в той же Delphi или Visual Studio мы всё же должны выполнить компиляцию и деплоймент, чтобы изменения увидел клиент. "Конфигуратор" потенциально даёт возможность править формы без перезапуска приложения.
На практике, для веб приложений деплоймент не сложнее кнопки Save. В том смысле, что у всех 10000 клиентов новая версия появляется одновременно, без даунтаймов и беготни с дискеткой по машинам.
Зато принуждение хранить дизайн в исходниках позволяет, как я уже говорил, пользоваться контролем версий. Если правка формы сломала приложение, то версионированные исходники позволят нам оперативно вернуть всё назад. Конфигурация, сохраняемая "в базу" таких плюшек не даёт — придётся весь тулчейн изобретать заново.

2. Состав кирпичиков. Аналитик с опытом работы неизбежно привыкает мыслить в рамках конструктора. Хорошие решения ему уже даже в голову не приходят; он сразу мыслит "вот тут будет грид, тут табы, тут тулбар". Даже если ему приходит в голову хорошая мысль, то он отбрасывает её как заведомо трудную в реализации. Типа "ну, грид с деревом и тулбаром я и сам накидаю; а за интерактивной картинкой придётся идти к разработчикам и дизайнерам, это минимум месяц ждать. Ну его".
В принципе, это можно было бы решить при помощи более могучего набора кирпичей. То, что мы видим сейчас в гуй-конструкторах — то же, что в 1994 году. Чуть другие формы кнопок, а так всё то же самое. Гриды, табы, тулбары, деревья. Дропдаун, спиннер, календарь. TreeGrid как венец сложности контрола; динамический докинг как венец кастомизации гуя пользователем. Полный тупик, уныние, казарма.

Единственная система с мало-мальски другой парадигмой форм ввода, которую я видел за последние 20 лет, была Lotus Notes. Увы, канула в небытие, раздавлена мейнстримом. Там, похоже, в какой-то момент ушёл последний человек, который понимал в usability, а наследники быстро развалили все достижения, став на несколько лет завсегдатаями WTF сайтов.

Фокус разработки usable софта переместился сначала в веб, потом в мобилки. На десктопе мы безнадёжно застряли в девяностых. Впрочем, веб — немногим лучше. Сайтов, которые было бы реально удобно использовать — единицы. Более-менее приемлемо работают только топовые мобильные приложения. И то — в каждом найдётся, за что поругать.

Здравствуйте, Sinclair, Вы писали:

S>"Конфигурации" ничего этого не умеют. В лучшем случае они живут в текстовых файлах, которые можно засунуть в VCS.
S>В вашем случае они живут в базе; это означает, что вообще никто не знает, что там стоит у заказчика. Нет понятия "версия", нет blame, нет changelog, нет веток, нет confliсt resolution.
S>Такие решения создают больше проблем, чем решают. Пишется-то система быстро, а вот стоимость поддержки начинает зашкаливать.

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

Здравствуйте, L_G, Вы писали:

L_G>Над проблемой периодически задумывался в течение многих лет. (Но не дождался такого приступа энтузиазма, чтобы броситься уже что-то кодировать.)

L_G>Из разных архитектурных вариантов подобной "среды" для себя остановился на варианте кодогенератора, который на основе структуры БД + какого-то дополнительного простого метаописания генерировал бы примерно такой же код, какой бы написал вручную сам программист. После этого код можно дорабатывать как обычно, стандартными средствами. А можно продолжать использовать генератор. При этом, возможно, придется вручную выделять из заново генерируемого кода нужные куски и вставлять их в нужные места основного кода. Скорее всего, при желании можно будет изолировать автоматически генерируемый код от подвергаемого ручным правкам.

L_G>Вроде бы это вписывается в термин "scaffolding". (Он используется почему-то только в веб-программировании, до которого я пока не добрался.)

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

Я считаю, что можно было бы данный недостаток побороть, используя автоматический мерж. Только мержить надо не плейн-текст, а синтаксические деревья. Причем не абстрактные, а конкретные, чтобы все форматирование сохранилось.

Здравствуйте, Sinclair, Вы писали:

MH>>Более того во многих случаях, когда платформа позволяет, аналитики в состоянии вносить изменения в интерфейсы, не привлекая программистов.
S>Ну, вообще-то исходная мысль Shmj была ровно о том, что интерфейс должен возникать сам из описания структуры данных, безо всяких там аналитиков.
это в некоторых случаях тоже актуально, а там где не подходит авто-интерфейс и конфигурируется спец. интерфейс, который Shmj и привел в пример.

S>Где лежит граница между программированием и конфигурированием? Вон, ещё в Delphi можно было быстро накидать контролов на форму, понастраивать свойства, привязать их друг к другу и получить работающее приложение, не написав ни строчки кода.
формальную границу определить пожалуй невозможно. так как, да, если хорошо продумать "кубики", упаковать сложность в классы/функции, то программирование будет почти тем же конфигурированием, за разницей что в программирование — в текстовом виде, а конфигурирование чаще — какой-то визуальный редактор.

S>Зато принуждение хранить дизайн в исходниках позволяет, как я уже говорил, пользоваться контролем версий. Если правка формы сломала приложение, то версионированные исходники позволят нам оперативно вернуть всё назад. Конфигурация, сохраняемая "в базу" таких плюшек не даёт — придётся весь тулчейн изобретать заново.
это проблема не конфигурирования как такового, это проблема вследствии конкретного технического решения — хранить результат конфигурирования в базе.
можно ведь его хранить и в текстовых файлах и их в системе контроля версий.
по сути конфигурирование можно сравнить с использованием специального DSL, скрывающего муду и сложность для типовых задач.


S>2. Состав кирпичиков. Аналитик с опытом работы неизбежно привыкает мыслить в рамках конструктора. Хорошие решения ему уже даже в голову не приходят; он сразу мыслит "вот тут будет грид, тут табы, тут тулбар".
такое возможно. но такое возможно и с програмистом, кто-то привык юзать конкретный грид и типовые интерфейсы делать, что-то новое уже будет также выглядеить что делать сильно дольше со всеми озвученными вами последствиями.
это не проблема подхода с конфигураторами, это проблема человеского мозга — он привыкает, к тому с чем человек часто работает и новые подходы/взгляды всегда имеют определенный барьер который надо преодолеть.


S>Единственная система с мало-мальски другой парадигмой форм ввода, которую я видел за последние 20 лет, была Lotus Notes. Увы, канула в небытие, раздавлена мейнстримом. Там, похоже, в какой-то момент ушёл последний человек, который понимал в usability, а наследники быстро развалили все достижения, став на несколько лет завсегдатаями WTF сайтов.
ну как же, 1с вполне нормальная платформа для учетных решений. хотя я и не являюсь их сторонником, но справедливости ради.


S>Фокус разработки usable софта переместился сначала в веб, потом в мобилки. На десктопе мы безнадёжно застряли в девяностых. Впрочем, веб — немногим лучше. Сайтов, которые было бы реально удобно использовать — единицы. Более-менее приемлемо работают только топовые мобильные приложения. И то — в каждом найдётся, за что поругать.
сайты, мобильный приложения, это всё таки другой класс приложений, это не учетные приложения для корп. использования, где оправданы конфигураторы, о которых трэд.

Здравствуйте, ltc, Вы писали:
ltc>Безотносительно здравости изначальной идеи запихивать все в базу: в чем проблема с версионностью, контролем версий, ветками и конфликтами? Вся конфигурация базы задается через скрипт, который и лежит в сорсконтроле, и версию проставляет-проверяет в базе.
Ээээ что?
Вот у вас бегает ентерпрайз-приложение. Бегает пять лет. База — полсотни гигабайт.
Где-то в этой базе хранятся описания формочек, которые правятся штатным аналитиком при помощи штатного конструктора форм без перезапуска приложения.
Вот в пятницу аналитик что-то напорол, и форма разъехалась. Что мы будем делать в понедельник?
Из какого сорс контрола и какой скрипт мы будем поднимать? Или мы будем поднимать всю базу из четвергового бэкапа, с потерей всех продаж и и т.п. за пятницу и выходные?

Здравствуйте, MadHuman, Вы писали:

MH>по сути конфигурирование можно сравнить с использованием специального DSL, скрывающего муду и сложность для типовых задач.
Ну, так современное программирование гуя — это оно и есть. Если мы отбросим бредовые идеи "создавать ГУИ по схеме данных" и "хранить описание ГУИ в СУБД", то останется совершенно нормальное программирование на обычном современном языке.

MH>ну как же, 1с вполне нормальная платформа для учетных решений. хотя я и не являюсь их сторонником, но справедливости ради.
1с — то же самое, вид сбоку. Для 90х — офигенная штука. С точки зрения юзабилити — твёрдые 3 с минусом.

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

Здравствуйте, Sinclair, Вы писали:

ltc>>Безотносительно здравости изначальной идеи запихивать все в базу: в чем проблема с версионностью, контролем версий, ветками и конфликтами? Вся конфигурация базы задается через скрипт, который и лежит в сорсконтроле, и версию проставляет-проверяет в базе.
S>Ээээ что?
S>Вот у вас бегает ентерпрайз-приложение. Бегает пять лет. База — полсотни гигабайт.
S>Где-то в этой базе хранятся описания формочек, которые правятся штатным аналитиком при помощи штатного конструктора форм без перезапуска приложения.
S>Вот в пятницу аналитик что-то напорол, и форма разъехалась. Что мы будем делать в понедельник?
S>Из какого сорс контрола и какой скрипт мы будем поднимать? Или мы будем поднимать всю базу из четвергового бэкапа, с потерей всех продаж и и т.п. за пятницу и выходные?


Хм. Я, видимо, недостаточно въехал в контекст.
Если формочки постоянно правятся без изменения схемы базы данных, то почем нельзя относиться к ним как к обычным данным (коими они и являются в таком случае)?
Если нам важна история данных — то не апдейтим, а инсертим, по дефолту используем последнее добавленное. В таком случае откат на любое предыдущее состояние тривиален.