Требования:
1) Разделение кода\представления(дизайнерские шаблоны)
2) Шаблоны должны быть "активными", т.е. циклы в них можно было крутить (типа smarty в php)
3) Шаблоны могли бы иметь подшаблоны (не просто html, а тоже с подставляемыми переменными) типа include header ()
4) "Человеческие" url с параметрами GET
Это главные требования
+ Желателен "компонентный" подход и простота использования
Здравствуйте, Аноним, Вы писали:
А>Требования: А>1) Разделение кода\представления(дизайнерские шаблоны) А>2) Шаблоны должны быть "активными", т.е. циклы в них можно было крутить (типа smarty в php) А>3) Шаблоны могли бы иметь подшаблоны (не просто html, а тоже с подставляемыми переменными) типа include header () А>4) "Человеческие" url с параметрами GET А>Это главные требования А>+ Желателен "компонентный" подход и простота использования А>Есть ли что-то подобное в природе?
А>Требования: А>1) Разделение кода\представления(дизайнерские шаблоны) А>2) Шаблоны должны быть "активными", т.е. циклы в них можно было крутить (типа smarty в php) А>3) Шаблоны могли бы иметь подшаблоны (не просто html, а тоже с подставляемыми переменными) типа include header ()
Это есть везде.
А>4) "Человеческие" url с параметрами GET А>Это главные требования А>+ Желателен "компонентный" подход и простота использования
Это во многих решается. Но не всегда просто.
А>Есть ли что-то подобное в природе?
Wicket, JSF, Spring MVC, Tapestry, JBoss Seam и многие, многие другие.
Здравствуйте, Blazkowicz, Вы писали:
А>4) "Человеческие" url с параметрами GET А>>Есть ли что-то подобное в природе? B>Wicket, JSF, Spring MVC, Tapestry, JBoss Seam и многие, многие другие.
Интересно а как в JSF реализуются "Человеческие" url с параметрами GET?
И Seam это разве не framework для middleware, который облегчает работу с JSF но не является сам по себе web framework?
Здравствуйте, ak-47, Вы писали:
A4>Интересно а как в JSF реализуются "Человеческие" url с параметрами GET?
А причем здесь GET? GET и friendly url не очень совместимые вещи.
A4>И Seam это разве не framework для middleware, который облегчает работу с JSF но не является сам по себе web framework?
После того как seam заявили о поддержке различных решений для View, они уже почти что Web Framework.
Sping ведь сам по себе тоже не web framework. A Spring MVC? Вот и с Seam по идее что-то похожее.
Здравствуйте, Blazkowicz, Вы писали:
B>А причем здесь GET? GET и friendly url не очень совместимые вещи.
JSF делает POST для любого действия. И JSF не HttpRequest driven framework. Поправь меня если я не прав. И насколько я понимаю GET и URL — это тесно связанные вещи . Я не рассматриваю тривиальный GET без параметров.
Но как организовать Bookmarking в JSF для меня остается загадкой. Ведь то что хочет тредстартер — friendly url — является частной проблемой Bookmarking проблемы Если есть какие-либо ссылки чтобы почитать как это сделать буду премного благодарен.
-ГуглЬ ничего вразумительного не выдал кроме того что проблема в JSF такая имеет место быть.
Здравствуйте, ak-47, Вы писали:
A4>JSF делает POST для любого действия. И JSF не HttpRequest driven framework. Поправь меня если я не прав. И насколько я понимаю GET и URL — это тесно связанные вещи . Я не рассматриваю тривиальный GET без параметров.
Я тебя все равно не понимаю. GET параметризация как раз и не является user friendly. JSF все равно в качестве базы использует сервлеты. Тобишь HttpServletRequest.
A4>Но как организовать Bookmarking в JSF для меня остается загадкой. Ведь то что хочет тредстартер — friendly url — является частной проблемой Bookmarking проблемы Если есть какие-либо ссылки чтобы почитать как это сделать буду премного благодарен.
У меня нет. JSF не практикую.
A4>-ГуглЬ ничего вразумительного не выдал кроме того что проблема в JSF такая имеет место быть.
Не врубаюсь http://www.google.com.ua/search?hl=ru&q=Friendly+url+in+JSF
Первая же ссылка — достаточно подробные материал http://balusc.blogspot.com/2007/11/friendly-urls-in-jsf.html
. Да весьма симпатично, спасибо. Правда как я понял по хорошему надо ждать 2-й версии
Еще лучше дождаться 3-й версии, только вот дождется ли заказчик :)
Здравствуйте, Blazkowicz, Вы писали:
B>GET параметризация как раз и не является user friendly.
А что же тогда является user friendly URL?
B>JSF не практикую.
А что практикуешь если не секрет? Wicket? GWT? Tapestry?
B>Не врубаюсь B>http://balusc.blogspot.com/2007/11/friendly-urls-in-jsf.html
Да согласен я тупанул, поздно было. Нашел эту ссылку сразу после поста.
Посыпаю голову пеплом.
<Аноним>,
А>Требования: А>1) Разделение кода\представления(дизайнерские шаблоны) А>2) Шаблоны должны быть "активными", т.е. циклы в них можно было крутить (типа smarty в php) А>3) Шаблоны могли бы иметь подшаблоны (не просто html, а тоже с подставляемыми переменными) типа include header () А>4) "Человеческие" url с параметрами GET А>Это главные требования А>+ Желателен "компонентный" подход и простота использования
А>Есть ли что-то подобное в природе?
Здравствуйте, ak-47, Вы писали: A4>Интересно а как в JSF реализуются "Человеческие" url с параметрами GET?
Не правильно написано, потому и спор пошел. GET — это HTTP-метод, который подразумевают передачу параметров серверу в строке адреса. Противоположно POST-методы, который подразумевает передачу параметров серверу отдельным полем запроса. Поэтому проблема закладок на данный момент может быть решена только с помощью метода GET. А вот передача ?Key=value&key1=value1 это скорее из HTML-спецификации (но я точно не уверен).
Кстати, чем плох адрес
Здравствуйте, LeonidV, Вы писали:
LV>Не правильно написано, потому и спор пошел. GET — это HTTP-метод, который подразумевают передачу параметров серверу в строке адреса. Противоположно POST-методы, который подразумевает передачу параметров серверу отдельным полем запроса. Поэтому проблема закладок на данный момент может быть решена только с помощью метода GET. А вот передача ?Key=value&key1=value1 это скорее из HTML-спецификации (но я точно не уверен).
. Да весьма симпатично, спасибо. Правда как я понял по хорошему надо ждать 2-й версии LV>Еще лучше дождаться 3-й версии, только вот дождется ли заказчик
Apache Wicket 1.3 зарелизили уже. Все, можно пользоваться. =)
Имейте в виду, статья морально устарела.
А>Правда как я понял по хорошему надо ждать 2-й версии
Вы про Apache Wicket 1.3 что-ли? Ждать уже не надо. С документацией, правда, пока не очень хорошо. Разбираться придется по wicket-examples и исходникам.
Apache Wicket... ээээ... несколько отличается по архитектуре от Wicket 1.2. Первая книга у меня тоже есть. Но уже не все в ней правда.
Re: Посоветуйте java web-технологию
От:
Аноним
Дата:
01.02.08 09:43
Оценка:
А>Есть ли что-то подобное в природе?
Конечно. JSP
Сервлет обрабатывает форму и отправляет результат в JSP. Всё.
Для развития идеи можно взять Spring MVC.
Если не нравится JSP, можно прикрутить Velocity или любой другой движок шаблонов.
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.
"СССР — четыре слова и все лживые" — Вагрич Бахчанян
Нужно:
— Легкость в наращивании функционала в дальнейшем
— Легкость интеграции с AJAX и относительная безглючность работы с ним
— Относительная простота использования
— Легкость в осовоении для тех кто не знаком с FW по мере развития проекта и роста команды
— Разделение UI и Logic между web и java разработчиками
— Написание собственных компонент пока не планируется (но возможно)
— Легкость в создании Templates
— Прозрачная интеграция со Spring
Готовы рассмотреть др варианты (Tapestry5 (тк все еще RC) и Struts1.X не предлагать )
Спасибо заранее всем откликнувшемся на зов о помощи
А>- 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 тоже возможна.
Re[4]: Посоветуйте java web-технологию
От:
Аноним
Дата:
05.02.08 13:44
Оценка:
Здравствуйте, 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 файл который будем деплоить.
Ну, это документацию читать. Чтобы понимать.
Re[4]: Посоветуйте java web-технологию
От:
Аноним
Дата:
05.02.08 19:25
Оценка:
Здравствуйте, Igor.K, Вы писали:
IK>Вместо (MyFaces Tomahawk + Facelets) возьмите Seam Framwork. MyFaces Tomahawk отнимается
Будет Weblogic так что ИМХО Seam может просто не пойти из за 2 вещей:
1. Совсем непаханное поле — разбираться надо. В команде никто кроме слова такого ничего про него не знает. Да и даже если знали бы зачем он когда есть Spring который решает все поставленные пока задачи.
2. Не хочется тянуть EJB. Не любят их у нас. Несмотря на все заявленные ++
Так что выбираем только Web слой. С Бизнес слоем — Spring + Hibernate будет.
Re[6]: Посоветуйте java web-технологию
От:
Аноним
Дата:
05.02.08 20:16
Оценка:
Здравствуйте, 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
Плюс к этому, seam предоставляет набор своих web компонент, таких как, генерация pdf документов, проверки введенных значений на web форме, дополнительные web компоненты, которые позволяют работать с состояниями, вывод форматированного текста (свой "птичий" формат для построения CMS), формирование email сообщений.
"СССР — четыре слова и все лживые" — Вагрич Бахчанян
Re[6]: Посоветуйте java web-технологию
От:
Аноним
Дата:
06.02.08 20:00
Оценка:
Здравствуйте, 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, вообще, как к классу приложений. Правда, слава богу, ни с одной мне тесно работать не пришлось.
"СССР — четыре слова и все лживые" — Вагрич Бахчанян
. Я не рассматриваю тривиальный GET без параметров. 
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
, можешь пояснить что ты имел ввиду 'свой "птичий" формат для построения CMS' Если Seam нам даст уход от Documentuma хоть на пару шагов и мы сможем аргументировано доказать это, то принемся изучать SEAM всей командой лишь бы только не иметь дела с ЭТОЙ пакостью под названием Documentum 