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

S>>Вы про Apache Wicket 1.3 что-ли? Ждать уже не надо. С документацией, правда, пока не очень хорошо. Разбираться придется по wicket-examples и исходникам.
LV>http://www.amazon.com/Pro-Wicket-Experts-Voice-Java/dp/1590597222/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1201781820&sr=8-1
LV>http://www.amazon.com/Wicket-Action-Martijn-Dashorst/dp/1932394982/ref=pd_bbs_sr_2?ie=UTF8&s=books&qid=1201781820&sr=8-2
LV>Первую читал — остался доволен. Правда Wicket так и не стал применять.

Apache Wicket... ээээ... несколько отличается по архитектуре от Wicket 1.2. Первая книга у меня тоже есть. Но уже не все в ней правда.

А>Есть ли что-то подобное в природе?
Конечно. JSP

Сервлет обрабатывает форму и отправляет результат в JSP. Всё.
Для развития идеи можно взять Spring MVC.
Если не нравится JSP, можно прикрутить Velocity или любой другой движок шаблонов.

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

A4>>-ГуглЬ ничего вразумительного не выдал кроме того что проблема в JSF такая имеет место быть.
B>Не врубаюсь
B>http://www.google.com.ua/search?hl=ru&q=Friendly+url+in+JSF
B>Первая же ссылка — достаточно подробные материал
B>http://balusc.blogspot.com/2007/11/friendly-urls-in-jsf.html

Ещё есть UrlRewriteFilter. Может подойдёт.

А>Есть ли что-то подобное в природе?

http://tapestry.apache.org/tapestry5 — думаю лучшее, что сегодня есть для веб-разработки в java. Чего только стоит динамический подхват изменений в классах страниц. Вот только релиза еще нет...

A4>Интересно а как в JSF реализуются "Человеческие" url с параметрами GET?
<h:outputLink> для формирования url с get параметрами, и связывание параметров, всех, не только get, со свойствами managed beans.
Seam сейчас вроде уже поддерживает совсем уже "человеческие" url:
http://in.relation.to/Bloggers/WhatsNewInSeam2

A4>И Seam это разве не framework для middleware, который облегчает работу с JSF но не является сам по себе web framework?
Он не только облегчает, но еще и расширяет добавляя свои компоненты, например, формирование pdf.

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

A4>>Интересно а как в JSF реализуются "Человеческие" url с параметрами GET?
IK><h:outputLink> для формирования url с get параметрами, и связывание параметров, всех, не только get, со свойствами managed beans.
IK>Seam сейчас вроде уже поддерживает совсем уже "человеческие" url:
IK>http://in.relation.to/Bloggers/WhatsNewInSeam2
Ссылка вот эта должна была быть:
http://in.relation.to/Bloggers/Seam201GA

A4>>И Seam это разве не framework для middleware, который облегчает работу с JSF но не является сам по себе web framework?
IK>Он не только облегчает, но еще и расширяет добавляя свои компоненты, например, формирование pdf.

Всем Здрасьте,

Помогите определиться с web-framework. Рассматриваются
— Wicket
— GWT
— JSF(MyFaces Tomahawk + Facelets)

Пока именно в такой последовательности.

Нужно:
— Легкость в наращивании функционала в дальнейшем
— Легкость интеграции с AJAX и относительная безглючность работы с ним
— Относительная простота использования
— Легкость в осовоении для тех кто не знаком с FW по мере развития проекта и роста команды
— Разделение UI и Logic между web и java разработчиками
— Написание собственных компонент пока не планируется (но возможно)
— Легкость в создании Templates
— Прозрачная интеграция со Spring

Готовы рассмотреть др варианты (Tapestry5 (тк все еще RC) и Struts1.X не предлагать )

Спасибо заранее всем откликнувшемся на зов о помощи

ЗЫ Сам склоняюсь к Wicket. Я обречен?

А>- JSF(MyFaces Tomahawk + Facelets)
Вместо (MyFaces Tomahawk + Facelets) возьмите Seam Framwork. MyFaces Tomahawk отнимается
Richfaces прибавляется плюс интеграция со Spring, и много много всего еще:
http://docs.jboss.com/seam/latest/reference/en/html/spring.html

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

А>Помогите определиться с web-framework. Рассматриваются
А>- Wicket
А>- GWT
А>- JSF(MyFaces Tomahawk + Facelets)

Не очень понятно как GWT в список затесался. Это же радикально другой framework. Там нет никаких шаблонов для реализации HTML страниц. Код выглядит как в desktop UI, код UI работает на клиентской стороне, ну и AJAX там повсеместно.
Wicket/JSF/Tapestry ещё более менее конкуренты

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

А>Помогите определиться с web-framework. Рассматриваются
А>- Wicket
А>- GWT
А>- JSF(MyFaces Tomahawk + Facelets)

Как справедливо заметил Blazkowicz, GWT — это совсем из другой оперы. Я с JSF не работаю, но за Wicket расскажу.

А>- Легкость в наращивании функционала в дальнейшем

Имеется в виду пригодность к рефакторингу? Поскольку в Wicket код и представление строго разделены, то тут проблем особых нет. Использование наследования и перегрузки на уровне темплейтов страниц и файлов ресурсов тоже помогает в строительстве систем, пригодных для рефакторинга.

Wicket все более приобретает модульную структуру. Докинув дополнительные библиотеки, вы можете получить дополнительную функциональность. Например, можно положить wicket-spring и wicket-spring-annot, в результате будет возможность интегрироваться со Spring, но можно и не делать этого.

А>- Легкость интеграции с AJAX и относительная безглючность работы с ним

Простейшие вещи реализуются левой ногой. Более сложные — думать надо. Wicket имеет свою поддержку Ajax плюс интегрируется с Prototype. В версии 1.2 не очень стабильно все работало. Например, мы как-то не смогли перевести приложение с 1.2.3 на 1.2.4 из-за глюков в Ajax-e. Кроме того, Firefox в своих логах очень нелестно высказывался о том, насколько хорошо разработчики Wicket знают CSS. Мелочь, а неприятно. Хотя нам и удавалось построить Ajax-приложение на Wicket, я бы не рекомендовал этот инструмент, лучше в сторону GWT глядеть. А вот для Web-приложения с Ajax-вставками вполне пойдет.

Насчет 1.3 пока ничего сказать не могу.

А>- Относительная простота использования

Научиться делать базовые вещи в Wicket очень просто. Но вот более сложные вещи таки заставят голову поломать.

А>- Легкость в осовоении для тех кто не знаком с FW по мере развития проекта и роста команды

В Wicket 1.3 не положили JavaDoc. Это странно и довольно неприятно, потому что исходники-то документированы. Про wicket-examples.war не забыли. По примерам много чего освоить можно. Книги и статьи по Wicket 1.1/1.2, с некоторыми оговорками, еще можно использовать для изучения 1.3.

А>- Разделение UI и Logic между web и java разработчиками

Здесь все просто отлично. Только не видел чтобы кто-то на практике такой подход использовал.

А>- Написание собственных компонент пока не планируется (но возможно)

Без проблем. Этого практически не избежать. Я бы порекомендовал с осторожностью юзать штатные сложные компоненты. Иногда проще написать их аналог, чтобы иметь больше контроля за кодом и разметкой.

А>- Легкость в создании Templates

Одна из самых важных вещей, которые мне понравились в Wicket — это то, что работать в темплейтах приходится с чистым HTML. У разработчика полная свобода действий.

А>- Прозрачная интеграция со Spring

Тут все просто отлично. Интеграция с Acegi тоже возможна.

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

B>Не очень понятно как GWT в список затесался. Это же радикально другой framework. Там нет никаких шаблонов для реализации HTML страниц. Код выглядит как в desktop UI, код UI работает на клиентской стороне, ну и AJAX там повсеместно.
B>Wicket/JSF/Tapestry ещё более менее конкуренты
Да согласен.
Порадовала интерактивность. Смотрели примеры. Приятно когда Web приложение откликается быстро на каждый чих изменения UI.
Непонятно пока как использовать тот высер который делает GWT после билда GWT модуля и WAR файл который будем деплоить.

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

А>Порадовала интерактивность. Смотрели примеры. Приятно когда Web приложение откликается быстро на каждый чих изменения UI.
Есть ещё Echo2 (и ворде бы даже Echo3). То же самое только pure Java. Поэтому подходит для интранета лучше, чем для всемирной сети. Хотя с современными каналами уже и не так актуально.

А>Непонятно пока как использовать тот высер который делает GWT после билда GWT модуля и WAR файл который будем деплоить.
Ну, это документацию читать. Чтобы понимать.

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

IK>Вместо (MyFaces Tomahawk + Facelets) возьмите Seam Framwork. MyFaces Tomahawk отнимается
Будет Weblogic так что ИМХО Seam может просто не пойти из за 2 вещей:

1. Совсем непаханное поле — разбираться надо. В команде никто кроме слова такого ничего про него не знает. Да и даже если знали бы зачем он когда есть Spring который решает все поставленные пока задачи.

2. Не хочется тянуть EJB. Не любят их у нас. Несмотря на все заявленные ++

Так что выбираем только Web слой. С Бизнес слоем — Spring + Hibernate будет.

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

А>>Непонятно пока как использовать тот высер который делает GWT после билда GWT модуля и WAR файл который будем деплоить.
B>Ну, это документацию читать. Чтобы понимать.
Это само собой.

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

А>Здравствуйте, Igor.K, Вы писали:

IK>>Вместо (MyFaces Tomahawk + Facelets) возьмите Seam Framwork. MyFaces Tomahawk отнимается
А>Будет Weblogic так что ИМХО Seam может просто не пойти из за 2 вещей:

А>1. Совсем непаханное поле — разбираться надо. В команде никто кроме слова такого ничего про него не знает. Да и даже если знали бы зачем он когда есть Spring который решает все поставленные пока задачи.
Это да, согласен, аргумент очень весомый.

А>2. Не хочется тянуть EJB. Не любят их у нас. Несмотря на все заявленные ++
А>Так что выбираем только Web слой. С Бизнес слоем — Spring + Hibernate будет.
Seam, кстати, только вокруг "web слоя" и вертится. И без EJB тоже работает, так же как и с EJB, это уж, как вам захочется. И с weblogic тоже работает. А для бизнес логики, это уж, или EJB, или JBoss jBPM, или, видимо, тот же, spring.
Web слой, как таковой, больше facelets + richfaces. Facelets, как раз позволяет работать связке верстальщик + web программист, исправляя, как раз, то за что JSF критиковали очень сильно. Richfaces — это AJAX framework, который наделяет AJAX свойствами JSF компоненты плюс предоставляет набор своих "чистых" AJAX компонент. Русские делают, кстати.
http://livedemo.exadel.com/richfaces-demo/index.jsp

Вместо Richfaces можно использовать icefaces
http://www.icefaces.org/main/demos/

Можно также интегрироваться с GWT.

Плюс к этому, seam предоставляет набор своих web компонент, таких как, генерация pdf документов, проверки введенных значений на web форме, дополнительные web компоненты, которые позволяют работать с состояниями, вывод форматированного текста (свой "птичий" формат для построения CMS), формирование email сообщений.

Ну, и плюс, очень активно развивается под руководством Gavin King (http://in.relation.to/Bloggers/Gavin), который нам Hibernate разработал.

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

IK>Web слой, как таковой, больше facelets + richfaces. Facelets, как раз позволяет работать связке верстальщик + web программист, исправляя, как раз, то за что JSF критиковали очень сильно. Richfaces — это AJAX framework, который наделяет AJAX свойствами JSF компоненты плюс предоставляет набор своих "чистых" AJAX компонент. Русские делают, кстати.
IK>http://livedemo.exadel.com/richfaces-demo/index.jsp
СПАСИБО пребольшое за ссылки. Порадовал Richfaces. Все дружно смотрим в его сторону. Пока все на уровне "HelloComponent" А что ты имел ввиду под "чистыми" AJAX компонентами?

IK>Можно также интегрироваться с GWT.
Если Richfaces нам подойдет то надобность в GWT просто отпадет. Пока тот набор компонент что есть устраивает.

IK>Плюс к этому, seam предоставляет набор своих web компонент, таких как, генерация pdf документов, проверки введенных значений на web форме, дополнительные web компоненты, которые позволяют работать с состояниями, вывод форматированного текста (свой "птичий" формат для построения CMS), формирование email сообщений.
Ну я так понимаю что в глубине используется iText или что-то типа него для генерации PDF и подобных доков. iText мы используем сам по себе так что это не аргумент для нас

А вот насчет СMS — мы собираемся прикручивать какашку под назвнием Documentum(простите меня все чьи чувства к этому ЧУДУ я оскорбил , можешь пояснить что ты имел ввиду 'свой "птичий" формат для построения CMS' Если Seam нам даст уход от Documentuma хоть на пару шагов и мы сможем аргументировано доказать это, то принемся изучать SEAM всей командой лишь бы только не иметь дела с ЭТОЙ пакостью под названием Documentum .

А>СПАСИБО пребольшое за ссылки. Порадовал Richfaces. Все дружно смотрим в его сторону. Пока все на уровне "HelloComponent" А что ты имел ввиду под "чистыми" AJAX компонентами?
Пожалуйста. Когда-то, в самом начале, Richfaces набор компонент был платным, вместе с ним, был базовый набор компонент, под называнием ajax4jsf, который распространялся как open source. Он имел одну замечательную особенность — механизм наделяющий "стандартные" jsf компоненты ajax особенностями. Потом Exadel заключила стратегическое соглашение с JBoss сделало richfaces тоже open source. Теперь ajax4jsf, просто, является частью richfaces. И разумеется, эта особенность никуда не делась.

А>Ну я так понимаю что в глубине используется iText или что-то типа него для генерации PDF и подобных доков. iText мы используем сам по себе так что это не аргумент для нас
Да, Вы совершенно правильно понимаете. Просто pdf уже формируется на основании jsf, а не использую "голый" iText в java программах. Несколько проще получается.

А>А вот насчет СMS — мы собираемся прикручивать какашку под назвнием Documentum(простите меня все чьи чувства к этому ЧУДУ я оскорбил , можешь пояснить что ты имел ввиду 'свой "птичий" формат для построения CMS' Если Seam нам даст уход от Documentuma хоть на пару шагов и мы сможем аргументировано доказать это, то принемся изучать SEAM всей командой лишь бы только не иметь дела с ЭТОЙ пакостью под названием Documentum .

То, что я имел ввиду, гораздо проще, это, все лишь, форматирование текста, оформленное с использованием "птичьих" символов для разметки:
http://docs.jboss.com/seam/1.1.5.GA/reference/en/html/text.html
Подобный язык применяется обычно в CMS или wiki, давая пользователю не использовать html разметку.

Хотя вы можете, наверно, попробовать использовать это как аргумент что бы не притаскивать Documentum. У меня, кстати, отвращение к CMS, вообще, как к классу приложений. Правда, слава богу, ни с одной мне тесно работать не пришлось.