AlexJmPetro123пропущено...

дык по умолчанию, никто не верит, что это ноу-хау)) именно с тонким клиентом.
А по картинке - обычная веб страничка....без "пошаговых родов".
Самое смешное - что этим (по первым впечатлениям-ковыряниям) действительно вполне можно пользоваться
в какой-там наколенной корпоративной ERP. Как замена Oracle Forms - вообще прекрасно.
Они б еще Binding Variables ввели - цены б не было. А так - надо DataAccess малость переделывать.

Да, похоже, что свой костыль для БД они впилили жёстко

privateПопробуйте сначала сделать классный интерфейс без абстракций. А потом если все еще будет желание, переработаете его в нужные абстракции.

Как показывает практика, руки "потом" до абстракций или до чего-то подобного не доходят, ибо ведь и так работает ;))
Поэтому если делать - так сразу, пусть это время займет, зато потом профит будет без лишних телодвижений...
Оно ведь как обычно бывает - пользователи: "Во, классно сделали! Давайте ещё вот это... вот это и вот это срочно... " - и так далее; потом год за годом вспоминаешь об абстракциях только в курилке))) А кода в проекте становится все больше, и без абстракций... И в один прекрасный момент приходит точка, после которой об абстракциях вообще можно забыть, потому что перепилить существующую отлаженную базу кода = переписать все заново. Спасибо за совет.

Вот ещё одна штуковина. Тот же JVx, для EE
http://sourceforge.net/projects/jvxee/

Petro123 у тебя будет ещё одна 101 штуковина, которая никому не будет нужна.

Объективно, Вам, Petro, она точно не нужна)))


Petro123 ... Даже на MVC не тянет.

..и не должно
интерфейс тут rich, в вэбе или нет - неважно
И для rich stateful моделей больше подходит MVP, который в одном ряду с MVC стоит

Как трамплин для реализации подхода, JVx отличный кандидат

privateДело не в том что это займет лишнее время, а что даже без абстракций классный интерфейс встречается в одном случае из 10. В случае-же когда внимание отвлекается на что-то еще типа абстракций - нормальный интерфейс не получается почти никога. Поэтому лучше решать постепенно.

А что понимается под классным интерфейсом?

ИМХО, организационно на интерфейс отвлечься "потом" проще, чем на внутренние конструкции приложения. Интерфейс живёт отдельно от логики приложения, меньше рисков сломать что-то отлаженное. Пользователям/заказчикам эти изменения видны, эта работа очевидна. Если заниматься внутренними конструкциями и абстракциями позже, то у пользователей/заказчиков возникают вопросы типа "Вы изменили внутренний код приложения, а что для нас изменилось" и претензии "а стоило ли, если все и так хорошо работало, зачем вы тратите время? задача уже решена, нас все устраивает". У нас есть унаследованное приложение, ситуация ровно такая, как я описал в самом начале: лучше не трогать, чтобы штукатурка не посыпалась, хотя интерфейс меняется без проблем и под аплодисменты. Мое мнение конкретно по этому вопросу не изменится.

И, да, как подметил Petro, существует паттерн MVC, который изолирует интерфейс. Эта изоляция позволяет менять интерфейс без изменений в контроллерах и моделях. НО! Если не продумать заранее применение этого паттерна в проекте, но нарисовать классный интерфейс, то стоимость поддержки и изменений такого кода будет возрастать прогрессивно в зависимости от "размера" проекта, неважно, на уровне логики или интерфейса эти изменения вносятся.
Кстати, то что я имел ввиду под абстрагированием, покрыто паттерном Adapter.

Petro123-=*ShamaN*=-интерфейс тут rich, в вэбе или нет - неважно
Огласите весь список "неважно".
1 - HTML5 или неважно?
2 - без апплетов или чистый тонкий клиент или неважно?
3 - для мобилок или неважно?
4 - за 6 шагов пишется проект или за 55
5 - модель 1С, где свой класс программистов и ЯП или неважно.
6 - Просто всё пока абстрактно и далеко от программиста.
IMHO

1) HTML5 или XUL или Swing или Flex или @Delphi! renderer@ - не важно
я, как прикладной программист, хочу только описывать: 1) декларативно - что должно быть в интерфейсе 2) программно - обработчики
далее я хочу деплоить свои артефакты в абстрактное "приложение" и чтобы они обрабатывались там, т.е., что бы я видел интерфейсы и реакцию

2) В данном подходе есть артефакт, называемый "приложение" - это конкретная реализация, и их может быть несколько (нами выбран Vaadin, как клиентская платформа). Для того чтобы мои декларативные описания работали, нужно написать конкретный движок на Ваадине, а точнее фабрику компонентов. Мои декларативные интерфейсы должны работать на ваадиновском виджетсете.
Ну, я завтра захочу Swing... Теперь пишем рендер декларативных интерфейсов в Swing, ведь они и там работать будут, верно?

3) Для мобилок это работать не будет, не стыкуются лэйауты. Хотя поведение менять не придётся.

4) Проект пишется за 55 шагов

5) Декларативная часть подразумевает описание на Java. Хотя приложение, которое рендерит интерфейсы и исполняет обработчики может быть написано и на С.

6) Petro, Вы, как всегда, правы... Реально, этот вопрос относится к компетенции архитекторов. В SCJP вроде бы даже есть отдельно сертификация такая...

Я технических проблем реализации не вижу.
Паттерны: MVP + Adapter (для компонентов и приложения)
JVx ясно даёт показать, что это возможно... Одна и та же демка поставляется: - в Swing (как апплет и Standalone), Flex, GWTxxx, пилится фабрика для ваадин реализации...

Чего мы тут спорим, это реально... И, действительно, не важно, что там, HTML или ещё что-то... Да хоть QT/// был бы движок и хавал бы УНИВАРСАЛЬНУЮ АБСТРАКТНУЮ (чувствую, Petro зеленеет) декларацию...

Вопрос уже исчерпал себя... давайте завершать дискуссию, уже все понятно, во всяком разе, я разобрался в своём вопросе и уже даже XSD-схему успел нарисовать для описания представлений в XML, а тут все спор никак не утухнет не понятно из-за чего.

Petro123-=*ShamaN*=-Декларативная часть подразумевает описание на Java
конкретнее пример , и почему не на JS?

Думали над этим (чтобы в БД типа сложить все можно было). Отказались из-за типизации (её отсутствия) и чтобы не плодить нотации. Хотя идея применения JS в данном случае имеет своё право на жизнь...

GregTk Вон у Vaadin часто меняются концепции...

Вот от этих изменений я и хочу основную массу прикладного кода оградить...

PS// Сама эта идея возникла в процессе перевода с ваадина 6 на 7

GregTk-=*ShamaN*=-, ... желаю вам удачи, думаю вот так сразу вас эта идея не отпустит :)

Спасибо)) точно, не отпустит, забористая зараза))

Petro123-=*ShamaN*=-Вот от этих изменений я и хочу основную массу прикладного кода оградить...
с этим согласен.
Удручает, что при смене версии Любой библиотеки приходится рефакторить код.
Но, это наша работа)). Никак не "оградить" )))))

Petro, на исходе своей кампании по захвату этой методики, могу поделиться впечатлениями и результатом, получилось или нет, если Вам интересно ;)

Petro123-=*ShamaN*=-,
угу.
Вы будете первый, кто разделил 3 богатыря в Java
ГУИ <--> прикладной код <--> БЛ с событиями.
))

ОК

Вот набросок того, что получается, "as is" (попрошу без критики - это пока всего лишь рабочий черновик)