GUI. Программерская печаль.

[metaclass]

Автоматическая генерация GUI

Там приведены ссылки на существующие фреймворки. Из них вроде только XAML и XUL пригодны для изготовления интерфейса для обычных прог, а не веб-морд.

(Веб-программизм, кстати, ЗАДРАЛ, кого не спроси - все занимаются этим безумием. Кто будет линиями на ком-порту рулить, я вас спрашиваю? ActiveX, загружаемый со странички, которому надо полсистемы безопасности подкрутить, чтобы он заработал?)

И еще обратите внимание - речь идет о автоматической генерации, а все фреймворки просто заменяют код или ресурсы для форм внутри проги какими-то скриптами или xml-файлами, но ведь эти долбанные скрипты все равно надо или руками набрать или в говновизуальном дизайнере индусами нарисовать. Фиг ВАМ, а не автоматическая генерация. Покупайте индусов, белые господа, они все нарисуют.


Или ведь откройте любую книгу по обучению программированию - хотя бы в одной было написано, как писать программы правильно, то бишь максимально повторно используемо. ХРЕН ТАМ НА ЛЫСЫЙ ЧЕРЕП! "Положите на форму DataGrid, положите DataSet, положите соедиение, пропишите все в их свойствах, в том числе и строку коннекта к серверу и запросы и даже названия полей таблицы."
Нужна новая форма, отличающаяся одним полем в запросе? Не вопрос, создаем копию существующих файлов, правим, итд. И так 10000 раз, пока не получим "IFSSAPR/3OEBS1СГалактику". Ах, да, надо чтобы у клиентов формы менять не перекомпилируя. Не проблема - встраиваем птичий императивный язык, встраиваем птичий декларативный язык описания форм, собственный генератор отчетов, собственный обработчик OLAP-кубофф(переделываем из шахматной ведомости) , делаем говновизуальный редактор, нанимаем индусов выпускников ПТУ Программирования и те на "языке предметной области, понятном аналитикам" рисуют формы, опять 10000 штук во всех вариациях.
Ах, да, я забыл, у нас же клавиатурой и текстовым кодом пользоваться не модно. Выпускаем очередную версию, теперь можно рисовать алгоритмы мышкой в виде блок-схем. А еще можно прямо в программу встроить Rational Rose, в ней рисовать, потом генерить промежуточные файлы, впихивать это все прямо в базу оракла, а потом еще обработчики на PLSQL писать
В итоге получаем клиническое говно, в котором могут разобраться только высокооплачиваемые сектанты, прошедшие зомбирование на специальных курсах производителей и внедрение которого стоит дороже, чем написание заказной системы.

Comments

[beskov.livejournal.com]

Я рассматривал автоматическую генерацию интерфейса как одно из преимуществ MDA-подхода - построение сквозного процесса - модель предметной области + модель бизнес-процессов + модель требований (1) -> модель архитектуры + модели компонентов системы (2) -> модели интерфейса + шаблоны / модель БД / модель БЛ (3) -> код приложения (4). Причём чтобы всё это максимально работало на стандартах UML, BPMN, XML, XSD, SQL и тех, которые приведены в конце исходного поста в ру_сисарх. Чтобы проектировщик мог основываясь на (1) и (2) спроектировать XML-документ, определить правила отображения и редактирования, и используя процессор сформирвоать приложение.

Причём тут визуальные редакторы и индусы я не понял - задача сделать более управляемым весь процесс разработки, так чтобы дешёвая рабсила не понадобилась.

Про повторное использование в книгах и проч. - всё верно, везде какая-то узость мышления - "решаем текущую задачу, а после нас хоть потоп".

[beskov.livejournal.com]

Кстати, одна из причин поиска подобных MDA-решений - в одном из проектов, например, московскими индусами от IBS было написано порядка 100 кастомных, но очень похожих ASP-форм. Теперь разгрести и найти концы практически не возможно. В БД из 400 таблиц 60 лежат вообще пустые, но удалить я их не могу без предварительного анализа ASP-кода, который бы показал, что да, действительно, эти таблицы не используются.

Так что надеюсь про индусов это сарказм.

[metaclass.livejournal.com]

Да, примерно это я и имел в виду.
Про индусов это да, сарказм :)

[metaclass.livejournal.com]

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