Товарищи, взываю вашему кругозору! Есть ли фреймворки для построения интерфейсов, содержащие в себе:
- API - описательный слой (аннотации и интерфейсы) для определения представлений и виджетов
- Common классы - реализация классов-обработчиков аннотированных классов, евэнтов, команд и пр.
- Реализация - конкретный движок, который "рендерит" интерфейс в рамках какой-то одной технологии, SWING например.

С точки зрения использования хотелось бы иметь такой:
1. Создать класс представления
2. Заинжектить виджеты, сервисы и ... при помощи спец. аннотаций из API с указанием атрибутов каждого элемента (возможно создать некий XML с параметрами разметки и пр.)
3. Закодить события, листенеры и обработчики и отметить их аннотациями
4. Зарегистрировать этот класс представления в "Регистре"
5. Увидеть результат

Конечная цель: иметь классы представлений, абстрагированные от конкретной технологии

Blazkowicz-=*ShamaN*=-Конечная цель: иметь классы представлений, абстрагированные от конкретной технологии
В Sun когда-то тоже такие мечтатели были. Они придумали JSF.

Спасибо. Но описания представлений и виджеты там вроде не универсальные, т.е. обработчики общие (Backing Beans), а представления нужно делать отдельно для каждого рендера... или я не прав?

Blazkowicz, премного благодарен, я серьёзно рассмотрю JSF в качестве клиентского двигла. Получается, в данной трактовке, нужно будет JSF-представления рендерить в Vaadin...

Пока ждал ответа наковырял вот эти библиотеки:
- http://code.google.com/p/jo-client-platform
- http://www.sibvisions.com/en/jvxmdemo
Последний (судя по демкам) - это то что нужно, но необходимо исходник ковырнуть). И, кстати, рендер для Vaadin там уже есть :) http://sourceforge.net/projects/jvx/files/?source=navbar

Ок, буду ковыряться, но JSF пока №1, ибо стандарт, а не конторская поделка, спасибо ещё раз...

Blazkowicz,

Vaadin - целевой end-user фреймфорк
А вот нам, программистам, от него как то надо абстрагироваться, чтобы код представлений не был завязан на конкретную технологию...
Поэтому я на решение этой задачи смотрю примерно так: "Common independent UI XML" -> Vaadin App Implementation -> User Happy, чтобы можно было "Common independent UI XML" -> Swing App Implementation -> Second User Happy

Опыта у меня немного, как бы Вы это сделали?

Blazkowicz-=*ShamaN*=-А вот нам, программистам, от него как то надо абстрагироваться, чтобы код представлений не был завязан на конкретную технологию...
Зачем?

Вот на эту тему готов в личке пообщаться, чтоб флуд не разводить...

Petro123-=*ShamaN*=-Вот на эту тему готов в личке пообщаться, чтоб флуд не разводить...
упрямый))). Всё равно будет делать)

Не, Петро, убиваться над технологией не буду... Но изолировать прикладной код буду по-любому))

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

В смысле "на клиента или на сервер"?

Blazkowicz-=*ShamaN*=-В смысле "на клиента или на сервер"?
Web GUI бывают с реализацией логики на сервере (JSP) или на клиенте (GWT).

Аааа... вот как.
Сейчас продумываю вариант, как реализовать UseCase, приведенный ниже... Кажется, в данном раскладе не важно, клиент или сервер; по крайней мере, искренне хочется в это верить))) но однозначно можно сказать, в JavaScript такое представление кода конвертировать будет очень проблематично, поэтому при "упаковке" кода в такой вид на клиенте должна быть Java, ну а дальше вопрос движка, умеющего "Съедать" такие конструкции.

Этот код - примерный набросок того, что мне хотелось бы иметь в качестве описателя логики.




Наверное, это больше на серверный вариант похоже...

Petro123-=*ShamaN*=-Кажется, в данном раскладе не важно, клиент или сервер; по крайней мере, искренне хочется в это верить)))

====== прикольно)). У MS с его сильверлайтом уже не получилось. Может у вас получится))

на клиенте должна быть Java,

==== это уже не веб проект(



Petro123, а вот у них получилось:
http://www.sibvisions.com/en/jvxmdemo

Я не знаю, почему у MS не получилось)) У МС обычно вообще не получается)))

А по поводу "не вэб-проект", это да, совсем не вэб

Petro123,

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

Вы прикрепили карртинку swing-приложения, там еще есть отрендеренный интерфейс под чистый вэб (похоже на ExtJS), flex и тот же swing, завернутый в апплет. А в репозитории лежит порт рендерера для vaadina.

Возвращаясь к вопросу исполнения кода, на клиенте или на сервере, уместно отметить тип клиента - исполняемый он или терминальный.
В исполняемом виде трудно представить, как java код будет выполняться на клиенте без jvm, и как вы верно подметили, это уже не вэб. В терминальном исполнении на клиенте имеется только представление и реакция на действия пользоваля отрабатввается на сервере, в данном контексте клиентский код на серевере может вполне себе использовать все прелести jvm и здесь не требуется транслировпть наши формы тз java в javascript (aka gwt).

Я думаю, что тема в топике исчерпала себя и можно заканчивать дискуссию. Библиотеки я использовать не буду, ибо написать свой обработчик 'тонких' задекрированных программистом клиентских классов дело не сложное. Основная работа, организовать контракт взаимодействия системного кровня с прикладным. Всем спасибо))

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" (попрошу без критики - это пока всего лишь рабочий черновик)

А это то, как выглядит внешне

А это "прикладной" код ( работа с контейнером данных не вынесена в API, поэтому пришлось "разврапить" таблицу и написать то, чего тут быть не должно )






+ композиция в XML