Сахават Юсифов Сахават ЮсифовМужики фигня все это.
Читайте DSL. Скоро уроем всех этих 1с, Аксапта и т.д.
В одиночку. Шансы начинают уравниваться. :)

Пупок не треснет? Вы хоть бы Delphi урыли бы.

А то нашли какую то хрень, и давай от "крутизны" девок тащиться....
http://www.devexpress.com/Products/NET/Libraries/eXpressApp/Architecture.xml

И вообще, чем Вы нас удивить собрались? XPO? DSL(кстати, вас из дас то)?

Да ну не смешно даже (первое). Для малолетних дурачков сие, поиграться разве.

tygraЭто ж модем, DSL, кто ж его читает?

Тссс... не, не модем. Не спугни.

Ща нам тут ишшо один скриншот психоделически-красивых градиентных гридов на XAF/WPF покажут.
И расскажут, ясен пень, как они этой голой ж...й будут бастионы Axapta и 1С брать.

(Только боюсь, ничего кроме дежаву трёхлетней J2EE давности мы увы, не узреем).

Сахават Юсифов iscrafm tygraЭто ж модем, DSL, кто ж его читает?

вообще-то Domain-specific languages ... наверное имелось ввиду

Сразу видно кто озабочен делами, а кто тащится от древного Дельфи и изначально больной J2EE.
Ну що Валер, язык бухучета уже сделал? Или вместе попробуем? :)

Наша песня хороша, начинай сначала.
PL/M, COBOL, ABAP, PL/SQL-ля, тополя.

Мало?

И это называется (языки сочинять) - делом? Ну и ну, мир, кажется, окончательно сошёл с ума.

И что там заикался про древние? Сахават - а может стоит открыть глаза, да посмотреть, к примеру,
на такую "новую" штуку, как LINQ (и вспомнить про Pro*C или SQLJ, которые были относительно
недавно названы старым и бесперспективным хламом).


Или на "новый" WCF, который, по сути - лишь относительно бездарное слизывание WorkFlow Builder и довольно немощное подражание - BPEL?

Так чем хвастаться то?

--

Вот уж действительно, все "новое" - суть, хорошо забытое старое. Вот так и гоняете по кругу, как лошади в цирке.

Сиоко АсахараА нафига спрашивается ему моделировать интерфейс, когда он не может моделировать данные?

Господа, а не пытаетесь ли вы, образно-прямо выражаясь, натянуть "глаз на ж..у"?
Моделирование данных, и уж тем более бизнес-процессов - это как бы одна стезя.

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

Иначе - просто чудеса какие то получаются. UI Дизайнер - рулит моделью, модель -
рулит эргономикой... В итоге - получаем кривых уродов, сплошь с ERP в названии
(от SAP до 1С).

--

Может таки не выстраивать диаметрально противоположные направления разработки
в одну линию (мещать соленые огурцы со молоком перед употреблением)?

///

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

P.P.S. Посмеялся вдвойне и от самой идеи. На кой каждый раз собирать и разбирать машину
до и после выезда из гаража? 95% (а то и 99.9%, если это не "времянка") времени жизни
ИС, формы в ней - статичны (в содержании).

И какая, извиняюсь, принципиальная разница хранить их в БД? Неужели так трудно организовать
обновление ПО на местах (пользователей?) Про сервера приложений (intra- internet-) и вовсе заикаться грешно (в вопросе - хранить какие .JSP в БД). Собственно говоря - да на кой?

Что оно вообще, реально, даст (кроме новых проблем)?

Codenamed Codenamed
...

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

в) Рассмотреть следующий вариант решения задачи:
- Первичная генерация форм (WEB, WinForms, Delphi) на основе хранящихся в БД метаданных или (более общий случай) описаний бизнес-объектов
- Доведение полученных заготовок до ума в штатной IDE
- Хранение подготовленных форм в БД (это не касается WEB, по понятным причинам) в виде сборок, .dll или пакетов с загрузкой их на клиентское приложение.

г) Дополнительно обсудить более сложный вопрос: внесение изменений в кастомизированные формы после изменения метаданных (или описаний бизнес-объектов).

И что? Ты хоть что то умное назвал?

Первичная генерация - для того есть банальные мастера (по сути - просто генерация кода - да хоть как и хоть куда).

Кастомизация - решается банальным наследованием (и последующей доработкой наследников).
А то и просто дублированием и заменой (формы).

Хранение и доставка - на 101% достаточно и базовых средств (БД там и даром не нужна, впрочем, в БД никто не запрещает хранить и обновлять уже готовые, собранные модули).

--

авторг) Дополнительно обсудить более сложный вопрос

Это просто банальный регламент сопровождения и развития БД.

-----

Ты лучше расскажи, какой реальный экономический эффект ты собираешься получить от всего этого?

Я пока только вижу - не эффект, а дополнительное усложнение жизни разработчикам. Особенно, если дело дойдёт до отказа от разнобразных UI дизайнеров (а это - неизбежно).

Может стоит покопать с другой стороны (всяк полезнее) - к примеру - в вопросах шаблонирования форм (высокоуровневые абстрактные заготовки)?

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

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

CodenamedНас здесь, вообще говоря, интересует, как бы, не совершая ненужных телодвижений, получить готовые или почти готовые представления списков и формы редактирования для 100 справочников и 50 видов документов, не скатываясь при этом к кривым уродам . И еще больше интересует, как лишить себя работы по переделке всех этих форм при изменении структуры данных, которая на этапе разработки бывает очень часто. :)

А я уже и сказал чуть выше - банальное Шаблонирование.
Сделай достаточно продвинутую и умную форму для Справочников, и для Журналов Документов.
А на месте - только указывай источник данных и дорабатывай какое специфичное представление (самих форм).

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

Добавление элемента - и того банальнее. Просто добавить, выбрать тип (контрола), разместить.

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


--

В результате... а в результате на клиенте вообще ничего не кодируется. Даже проверки данных - и то идут автоматом (только указать процедуру валидации в сервере БД).

-----

Но для всего озвученного выше - НЕ НУЖНО генерировать интерфейс из БД. Я вас умоляю - оставьте верстальщикам UI нормальные средства работы с UI.