Товарищи, взываю вашему кругозору! Есть ли фреймворки для построения интерфейсов, содержащие в себе:
- 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).

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