День добрый!
Требуется быстро кодировать и ПРАВИТЬ web-интерферейс для приложений, написанных на Java и работающих на серверах приложений (Tomcat, GlassFish, ...).
Как одно из предложений — остановиться на технологии JSF 2.0.
Садиться и изучать ее можно, но хотел бы попросить помощь клуба в этом вопросе у тех, кто реально работает с web-GUI, JSF, ...

Вопросы вот какие:
1. обеспечит ли JSF 2.0:
— быстрое создание GUI и его правку по требованиям
— переиспользование кода и компонент внутри приложения
— возможность расширения библиотеки компонент GUI при недостатке стандартных
— достаточную производительность
2. на чем можно рисовать GUI для JSF-приложений
3. есть ли что лучше по означенным критериям, чем JSF 2.0 и в чем там рисуются GUI

Заранее спасибо.
Большое спасибо. )

Здравствуйте, Аноним, Вы писали:

JSF 2.0 это спецификация. Результат сильно зависит от того какую же вы реализацию выберите и какие компаненты будете использовать. PrimeFaces последнее время хвалят.
Я бы рекомендовал прислушатся к мненю уважаемого Джеймса Гослинга
www.google.com/search?q=James+Gosling+JSF

Посмотрите лучше GWT.

Здравствуйте, Blazkowicz, Вы писали:

B>JSF 2.0 это спецификация. Результат сильно зависит от того какую же вы реализацию выберите и какие компаненты будете использовать. PrimeFaces последнее время хвалят.
B>Я бы рекомендовал прислушатся к мненю уважаемого Джеймса Гослинга
B>www.google.com/search?q=James+Gosling+JSF

Целиком и полностью поддерживаю Джеймса.

B>Посмотрите лучше GWT.

А это смотря что за приложение.

Здравствуйте, GarryIV, Вы писали:

B>>Посмотрите лучше GWT.
GIV>А это смотря что за приложение.
Конечно. При такой массе альтернатив всегда есть что-то в чем-то лучше. Просто GWT выглядит для меня сейчас эдакой золотой серединой.
Хотя, зачастую, ExtJS не хуже, если цена для проекта не кусается. Но это уже оффтопик.
Ну, и Spring MVC на сервере, конечно же.

B>Я бы рекомендовал прислушатся к мненю уважаемого Джеймса Гослинга
Посмотрел, что сказал Джеймс, но там всего одна строка.) Технология действительно продолжает жить... и реализаций немало.

B>Посмотрите лучше GWT.
Хорошо. Вообще на мой взгляд у всего должны быть и плюсы и минусы.
Может не затруднит чуть поподробнее описать что нравится в GWT, что не нравится и почему все-же JSF не стоит выбирать.

Здравствуйте, Аноним, Вы писали:

А>Может не затруднит чуть поподробнее описать что нравится в GWT, что не нравится и почему все-же JSF не стоит выбирать.

gwt — библиотека для создания клиентского приложения с возможностью безгеморройного задания типизированных интерфейсов для общения с сервером. web2.0 вобщем

jsf — набор тегов с плюшками и жирной статефульнустью либо прям в страничке либо на серверной стороне. веб1.5 вобщем zkoss и то веселее по моему. вообще ощущение такое что весь смысл создания этой штуки был в том чтобы сделать мыше формошлепку для веба "как у микрософта".

Результат который видим после трансляции — куча непонятного нагенеренного java script и что здесь хорошего

Здравствуйте, dotidot, Вы писали:

D>gwt — библиотека для создания клиентского приложения с возможностью безгеморройного задания типизированных интерфейсов для общения с сервером. web2.0 вобщем

Здравствуйте, Аноним, Вы писали:

А>Результат который видим после трансляции — куча непонятного нагенеренного java script и что здесь хорошего

А ты небольсь и после компиляции любишь java байткод почитать?

Здравствуйте, Аноним, Вы писали:

А>Как одно из предложений — остановиться на технологии JSF 2.0.
А>1. обеспечит ли JSF 2.0:
А> — быстрое создание GUI и его правку по требованиям
Facelets в помощь
А> — переиспользование кода и компонент внутри приложения
Да можно, используя composite component
А> — возможность расширения библиотеки компонент GUI при недостатке стандартных
Написание своих компонентов это отдельная песня. Лучше изучить имеющиеся библиотеки и выбрать наиболее подходяшую по компонентам, их не так уж и много: IceFaces, RichFaces, PrimeFaces (обвертка вокруг YAHOO UI, поэтому часть стандартных аттрибутов могут и не поддерживать). При этом нужно обратить внимание полностью или не полностью компоненты поддерживают JSF2, наличие ленивой загрузки в таблицы.
А>2. на чем можно рисовать GUI для JSF-приложений
Они пишутся при помощи html тегов, css и java скрипта

Здравствуйте, Аноним, Вы писали:

B>>Посмотрите лучше GWT.
А>Хорошо. Вообще на мой взгляд у всего должны быть и плюсы и минусы.
А>Может не затруднит чуть поподробнее описать что нравится в GWT, что не нравится и почему все-же JSF не стоит выбирать.
JSF это изначально абстрактный язык описания интерфейсов. Это уже после релиза оказалось, что кроме как в Web его никто нигде особо применять не стремится.
Соответственно такой уровень абстрагированность даже от Web привел к переусложнению.
http://java.sun.com/j2ee/1.4/docs/tutorial/doc/JSFIntro10.html
Смотрим картинку Standard Request Processing Life Cycle
И что самое интересное, всё это приходится использовать для решения каких-то совершенно пустяковых задач.
Следующее это то что сам JSF на уровне HTML особой свободы не даёт. Facelets стали глотком свежего воздуха для разработчиков.
Выбрав JSF вам нужно будет ещё определится и с выбором его реализации. JEE подход спецификаций\реализаций здесь во всей красе.
Ну, моё личное. Меня от синтаксиса в стиле JSP Taglib воротит. Программирование на XML выходит.
Окромя PrimeFaces на JSF ничего приличного и в тоже время бесплатного пока не видел.


GWT тоже не убийца всех остальных фреймверков. Ему так же не хватает красивостей как в бесплатных компанентах JSF. Хотя SmartGWT и ExtGWT спасают.
С учетом того что весь JSF давно и успешно движется в AJAX, то в результае UI от GWT не особо отличается.
Кодить на много проще. Есть свои проблемы. Решаемые, но все же разражающие. И время компиляции и скорость запуска плагина для hosted mode. Да и внутри не всегда всё гладко.
Но зато чудесно работает со Spring MVC, в котором, при случае, можно и статическую JSP применить где надо.

Здравствуйте, Nicht, Вы писали:


Да не , не люблю всяких генераторов , html — должен быть — html, js — тоже js который написал сам и понимаешь что происходит внутри , можешь легко задебажить


N>А ты небольсь и после компиляции любишь java байткод почитать?

Здравствуйте, Аноним, Вы писали:

А>Может не затруднит чуть поподробнее описать что нравится в GWT, что не нравится и почему все-же JSF не стоит выбирать.
Очень нравится то что GWT работает в браузере и тамошний DOM\JS всегда доступны. Надо например Flash-график данными обновить раз плюнуть.
Брагодаря этому возникает и больше пространства для оптимизации. Больше логики в браузере, меньше запросов к серверу.

Здравствуйте, Аноним, Вы писали:

А>Да не , не люблю всяких генераторов , html — должен быть — html, js — тоже js который написал сам и понимаешь что происходит внутри , можешь легко задебажить
Замечание по делу. В этом случае ExtJS + Spring MVC. Тоже отличный вариант.
GWT, это первый пример на моей памяти где кодогенерация не стала серьезной проблемой. Хотя в ранних версиях были нюансы, но сейчас всё намного стабильнее.

А>>Да не , не люблю всяких генераторов , html — должен быть — html, js — тоже js который написал сам и понимаешь что происходит внутри , можешь легко задебажить

В этом случае нужно посмотреть в сторону wicket. Для средних проектов — очень даже хорошо подходит! html всегда можно легко открыть в любом редакторе или браузере

Здравствуйте, Blazkowicz, Вы писали:

B>Здравствуйте, Аноним, Вы писали:

B>>>Посмотрите лучше GWT.
А>>Хорошо. Вообще на мой взгляд у всего должны быть и плюсы и минусы.
А>>Может не затруднит чуть поподробнее описать что нравится в GWT, что не нравится и почему все-же JSF не стоит выбирать.
B>JSF это изначально абстрактный язык описания интерфейсов. Это уже после релиза оказалось, что кроме как в Web его никто нигде особо применять не стремится.
B>Соответственно такой уровень абстрагированность даже от Web привел к переусложнению.
B>http://java.sun.com/j2ee/1.4/docs/tutorial/doc/JSFIntro10.html
B>Смотрим картинку Standard Request Processing Life Cycle

Угу. Они там наабстрагировались до невозжности. Шаг влево\вправо и все. Помню надо было сделать простую вещь POST -> Создать сущность -> редирект на ее View page. Пришлось лезть в реализацию и корячить ее. Вроде как в 2.0 должны были это улучшить но все равно JSF с его дырявыми абстракциями must die.

Я бы рекомендовал вам забить на JSF и остальные серверные фреймворки для UI и научиться нормально верстать HTML5 и программировать на современном JS (например с jquery). Сами страницы соотв. писать на обычном JSP (плюс очень умеренное количество тегов) или FreeMarker.
От сервера вам реально требуется несколько богатых контроллеров (Spring WebMVC 3.0 — ок) для подготовки основных страниц, а остальное вы сможете сделать на REST/JSON, сфокусировавшись на безопасности и корректности данных. Такой подход к тому же идеален для командной работы, поскольку механизм взаимодействия между контроллерами и представлением примитивен, прозрачен и прямолинеен.
Модульность при этом реализуется довольно просто (ресурсы можно загружать из classpath, компоненты связывать с помощью Spring).

Посмотрев неспешно многие фрэймворки постепенно прихожу к выводу, что возможно тут есть смысл.
Во всех просмотренных фрэймворках есть какие-то плюсы и минусы — где производительность, где повышенная платность и закрытость определенных мест, где недостаток компонент и трудная расширяемость. И если стартовать на них можно действительно быстро, то потом не потребуется ли переписывать и перекручивать код?
В подходе с freemaker/jsp смущает только то, что надо все делать самому. Т.е. надо заниматься и разметкой и CSS и JS. А поддерживать и дорабатывать компоненты — это, я так понимаю, дополнительная и непростая работа.
Вопрос вот какой. Как вы расширяете библиотеку компонент и насколько все это трудоемко?
Например, меню, выборы дат, диалоги, всплывающие окна, ...
И не изменилось ли еще Ваше мнение с того поста? )

Здравствуйте, _star, Вы писали:

_>Посмотрев неспешно многие фрэймворки постепенно прихожу к выводу, что возможно тут есть смысл.
_>Во всех просмотренных фрэймворках есть какие-то плюсы и минусы — где производительность, где повышенная платность и закрытость определенных мест, где недостаток компонент и трудная расширяемость. И если стартовать на них можно действительно быстро, то потом не потребуется ли переписывать и перекручивать код?
_>В подходе с freemaker/jsp смущает только то, что надо все делать самому. Т.е. надо заниматься и разметкой и CSS и JS. А поддерживать и дорабатывать компоненты — это, я так понимаю, дополнительная и непростая работа.
_>Вопрос вот какой. Как вы расширяете библиотеку компонент и насколько все это трудоемко?
_>Например, меню, выборы дат, диалоги, всплывающие окна, ...
_>И не изменилось ли еще Ваше мнение с того поста? )

Фреймеверк подбирается под задачу. Универсального решения нет. Существует куча сайтов, где выбор дат и диалоги никому не нужны. Зато нужны невероятные дизайнерские навороты и не здоровые трюки на уровне CSS. В этом случае дизайнер с верстальщиком создают HTML и иже с ним. А вы спокойно его на тягиваете на MVC фреймверк.

Существует другой класс приложений. Когда вам летающие зайчики по всей странице нафиг не нужны. Зато страница под завязку забита полями для ввода, datepicker-ами и гридами. Вот тогда нужен компанентный фреймверк уровня GWT/JSF. Расширять и делать новые компаненты ни там ни там не просто. Но зачем это может понадобится, когда есть SmartGWT и PrimeFaces?

Обратно, есть варианты без использования Java для фронтенда: Flex, ExtJS.

D>вообще ощущение такое что весь смысл создания этой штуки был в том чтобы сделать мыше формошлепку для веба "как у микрософта".

вы говорите так как будто это плохо. для 98% интранет приложений работающих во внутренних 100Мб сетках предприятий это именно то что требуется. не нужно особо экономить на трафике, на объеме html странички, и не нужна валидация в w3c, зато нужна скорость, простота и легкость сопровождения

1. Цена
2. SmartGWT выглядит уж очень бизнес-ориентированно + с клавиатурой дружба (по примерам) не везде.
Хотелось бы что-то более современное и элегантное, поскольку с красивым и современным интерфейсом работа кажется приятней.