Есть желание в новом проекте отказатся от отработанной схемы с POJO -> XML -> XSLT при построении view компонента.
Используем Spring MVC. Посоветуйте на что стоит обратить внимание? Velocity, Tiles, JSF, ... ?
Выбор столь обширен что глаза разъезжаются...
Здравствуйте, Replicator, Вы писали:
R>Есть желание в новом проекте отказатся от отработанной схемы с POJO -> XML -> XSLT при построении view компонента. R>Используем Spring MVC. Посоветуйте на что стоит обратить внимание? Velocity, Tiles, JSF, ... ? R>Выбор столь обширен что глаза разъезжаются...
L>А вообще вчера услышал мнение, что webworks рулит, тем более что со 2.2 тесно интегрированы со спрингом. Сам поставил на заметку.
Я фримаркер использую совместно со спрингом, очень даже доволен. На счет популярности — в спринговом сообществе он пользуется очень даже неплохим спросом К тому же после переезда с jsp использование custom tags во фримаркере довольно полезная вещь.
L>>А вообще вчера услышал мнение, что webworks рулит, тем более что со 2.2 тесно интегрированы со спрингом. Сам поставил на заметку.
L>Я фримаркер использую совместно со спрингом, очень даже доволен. На счет популярности — в спринговом сообществе он пользуется очень даже неплохим спросом К тому же после переезда с jsp использование custom tags во фримаркере довольно полезная вещь.
Я не спорю, я подшучиваю . А с webworks погорячился, бо это не view, а целый веб-tier, который можно использовать вместо SMVC.
Replicator пишет:
> Есть желание в новом проекте отказатся от отработанной схемы с POJO -> > XML -> XSLT при построении view компонента. > Используем Spring MVC. Посоветуйте на что стоит обратить внимание? > Velocity, Tiles, JSF, ... ? > Выбор столь обширен что глаза разъезжаются...
Выбор велик, но реально — все довольно похоже одно на другое.
Мы для себя выбрали Tapestry — довольно оригинальная технология
На ней например сделан не без известный theserverside
В чем преимущества
1. Главное преимущество — странички можно делать в обычном HTML
редакторе с помощью обычного ничего не знающего о Яве web
дизайнера. Т.е. мы делали так — садились и рисовали прототип сайта
т.е. делали HTML страницы — потом к ним присоединяли код но
java и HTML НИГДЕ не смешиваются.
Чем плох JSP и все что на нем основано — это в широком смысле
язык программирования, но язык не вполне полноценный. В Tapestry
у тебя HTML отдельно java отдельно. Но при этом они прекрасно
объединяются.
2. Объектный подход. Т.е. вся функциональность находится в Ява
классах их можно наследовать друг от друга, делать reusable
компоненты и т.д. Например я делаю класс BasePage от которого
наследую все классы стараниц моего сайта. Класс я аннотирую
требуется_авторизация=true и встраиваю в базовый класс код
который проверяет — авторизован ли пользователь и если нет,
то отсылает на страницу авторизации.
Для главной страницы сайта и для станицы авторизации я
перекрываю анотации требуется_авторизация=false — т.е. это
две страницы на которые можно зайти без авторизации. Все я уже не
могу случайно забыть и сделать страницу вход на которую возможен
без авторизации.
Иначе говоря Tapestry значительно более технологичная платформа.
Там есть такая штука как HiveMind — для посторения Control вешь
весьма продвинутая. Ну и так далее
--
WBR Денис Цыплаков /* jabber UID: denis.tsyplakov@jabber.ru */
Знающий не говорит, говорящий не знает
Кто-нибудь использовал эту связку в своих проектах? Скоро мне предстоит писать приложение (портал) на базе оракловского сервера и я подумал, что будет логично взять все от одного вендора, тем более, что vendor locking не грозит.
Orale серьезно поддерживает JSF, и у него есть своя, уже свободная, реализация — ADF. Кроме, того есть JDeveloper со встроенным редактором компонент, поэтому я выбрал именно JSF. Но хотелось бы узнать, что мне может дать совместное использование Facelets, и с чем его едят :) Если кто кинет ссылкой на статью с простыми примерами буду признателен.
T>Кто-нибудь использовал эту связку в своих проектах? Скоро мне предстоит писать приложение (портал) на базе оракловского сервера и я подумал, что будет логично взять все от одного вендора, тем более, что vendor locking не грозит. T>Orale серьезно поддерживает JSF, и у него есть своя, уже свободная, реализация — ADF. Кроме, того есть JDeveloper со встроенным редактором компонент, поэтому я выбрал именно JSF. Но хотелось бы узнать, что мне может дать совместное использование Facelets, и с чем его едят Если кто кинет ссылкой на статью с простыми примерами буду признателен.
Например добаляет возможность, о которой уже было сказано, как и в tapestry, работать в любом html-редакторе, отличную шаблонную систему..
вопрос уже обсуждался здесь
Здравствуйте, Денис Цыплаков, Вы писали:
ДЦ>Trean пишет:
>> JSF vs. Tapestry >> <http://www.theserverside.com/articles/article.tss?l=JSFTapestry>
ДЦ> Ну пожалуй надо добавить что разработка на JSF невозможна без ДЦ> IDE Поддерживающей JSF — т.е. возможна но очень сложна.
ДЦ> С другой стороны для Tapestry поддержки IDE вообще нет, но вроде ДЦ> как и нечего там поддерживать, палка-веревка — все просто.
ДЦ>-- ДЦ>WBR Денис Цыплаков /* jabber UID: denis.tsyplakov@jabber.ru */ ДЦ> Знающий не говорит, говорящий не знает
R>Есть желание в новом проекте отказатся от отработанной схемы с POJO -> XML -> XSLT при построении view компонента. R>Используем Spring MVC. Посоветуйте на что стоит обратить внимание? Velocity, Tiles, JSF, ... ? R>Выбор столь обширен что глаза разъезжаются...
Пока вот решили ознакомится с Tapestry.
В догонку — а нет ли технологии напоминающей XSLT, но работающую с деревом Java объектов в качестве источника?
То есть трансформация модели в XML по формальному описанию на языке как можно более близкому к XSLT/XPath.
Здравствуйте, Replicator, Вы писали:
R>В догонку — а нет ли технологии напоминающей XSLT, но работающую с деревом Java объектов в качестве источника? R>То есть трансформация модели в XML по формальному описанию на языке как можно более близкому к XSLT/XPath.
Replicator пишет:
> R>Есть желание в новом проекте отказатся от отработанной схемы с POJO -> > XML -> XSLT при построении view компонента. > R>Используем Spring MVC. Посоветуйте на что стоит обратить внимание? > Velocity, Tiles, JSF, ... ? > R>Выбор столь обширен что глаза разъезжаются... > > Пока вот решили ознакомится с Tapestry. > > В догонку — а нет ли технологии напоминающей XSLT, но работающую с > деревом Java объектов в качестве источника? > То есть трансформация модели в XML по формальному описанию на языке как > можно более близкому к XSLT/XPath.
Не встречал. Если вдруг что найдешь, напиши в конфу, мне например
тоже интересно. В принципе такую вещь легко сделат самому, но
Весь вопрос в языке. По большому (очень большому счету) например
Velocity это одна из таких технологий. В принципе любой Ява template
движок формально такой является. Но интуитивно мне кажется я понимаю
чего именно хочется. И хочется странного (с) Стругацкие
Можно попровать автоматом строить по Ява бин объектам XML c
с помощью reflection и аннотаций и уже к постоенному применять XSLT
т.к. основная проблема сдесь — не по чему строить — а язык
описывающий, как строить и лучше чем XSLT+XPath я на эту тему пока не
встречал. Но правда если так сделать — может немного медленно
получиться
Короче тема интересная, есть о чем подучать
--
WBR Денис Цыплаков /* jabber UID: denis.tsyplakov@jabber.ru */
Знающий не говорит, говорящий не знает
Здравствуйте, Денис Цыплаков, Вы писали:
ДЦ> Можно попровать автоматом строить по Ява бин объектам XML c ДЦ> с помощью reflection и аннотаций и уже к постоенному применять XSLT ДЦ> т.к. основная проблема сдесь — не по чему строить — а язык ДЦ> описывающий, как строить и лучше чем XSLT+XPath я на эту тему пока не ДЦ> встречал. Но правда если так сделать — может немного медленно ДЦ> получиться
Как вариант: реализовать javax.xml чтобы брать данные непосредственно из дерева объектов? Хотя субъективно переписать какой-нибудь XSLT движок должно быть эффективней.
А может JSP taglib с синтаксисом близким к xslt?
На счет того что будет медленно тут смотя с какой стороны глянуть. Трансофрмация из объекта в XML вроде должна быть затратнее чем reflection. Но с другой стороны навигация по XML вроде бы проще чем по дереву объектов.
ДЦ> Короче тема интересная, есть о чем подучать
Ещё встаёт вопрос об однозначном представлении дерева объектов в дерево XML. Ведь дерево объектов оно и не свосем дерево, а сеть.
T>Orale серьезно поддерживает JSF, и у него есть своя, уже свободная, реализация — ADF. Кроме, того есть JDeveloper со встроенным редактором компонент, поэтому я выбрал именно JSF. Но хотелось бы узнать, что мне может дать совместное использование Facelets, и с чем его едят Если кто кинет ссылкой на статью с простыми примерами буду признателен.
По пробовали в своем проекте ADF, сейчас старательно все что было написано на ADF переписываем на другие технологии. Возможно что просто не разобрались, но все слишком не понятно, так как большая часть кода генериться посредством JDeveloper, не понятные рассинхронизации объектов, ошибки и т.д. и т.д.
ДЦ> Можно попровать автоматом строить по Ява бин объектам XML c ДЦ> с помощью reflection и аннотаций и уже к постоенному применять XSLT
вот это промежуточное действо как раз хочется исключить...
ДЦ> т.к. основная проблема сдесь — не по чему строить — а язык ДЦ> описывающий, как строить и лучше чем XSLT+XPath я на эту тему пока не ДЦ> встречал.
вот я тоже эту связочку люблю. где то я определенно что то видел на тему XPath но для работы с объектами...
Blazkowicz пишет:
> ДЦ> Можно попровать автоматом строить по Ява бин объектам XML c > ДЦ> с помощью reflection и аннотаций и уже к постоенному применять XSLT > ДЦ> т.к. основная проблема сдесь — не по чему строить — а язык > ДЦ> описывающий, как строить и лучше чем XSLT+XPath я на эту тему пока не > ДЦ> встречал. Но правда если так сделать — может немного медленно > ДЦ> получиться > > Как вариант: реализовать javax.xml чтобы брать данные непосредственно из > дерева объектов? Хотя субъективно переписать какой-нибудь XSLT движок > должно быть эффективней.
Мне кажется это дюже смело. Заманчиво конечно. Но проще и быстрее
наверное сделать какую-нить быструю DOM оборачивалку для POJO
объектов. Хотя это тоже в какой-то степени реализация javax.xml
Да пожалуй если грамотно подойти — очень вкусная штука может
получиться. По идее нужны реализации Node, Element и т.п. которые
список аттрибутов и дочерних элементов берут из содержащегося в
них POJO объекта. Может получиться весьма изящно. Берешь дерево
объектов — говоришь что-то вроде
И дальше используешь doc как DOMSource для XSLT преобразования.
Можно добавить аннотации опционально подсказывающте как строить
документ по объекту. Ну там имена атрибутов, тегов и т.п.
> А может JSP taglib с синтаксисом близким к xslt?
За что не люблю JSP — технология простая, но нудная. Лучше таки XSLT
хотя тоже по подарок. Помню мы делали на XSLT преобразование которое
из XML с данными о расходах электроэнергии за период делало график
в формате SVG. Причем там сначала искались max/min значения,
определся дапазон дат для вменяемой раскладки подписей и т.д. Потом
строился график — отдельно активная, отдельно реактивная энергии.
Чудо это было килобайт на 60 плотного XSLT кода. И работало скажем
так не быстро. Хотя так сказат ьс технологической точки зрения XSLT
было удобно. Но больше я так делать не будут. Впрочем на JSP тоже не
буду
> На счет того что будет медленно тут смотя с какой стороны глянуть. > Трансофрмация из объекта в XML вроде должна быть затратнее чем > reflection. Но с другой стороны навигация по XML вроде бы проще чем по > дереву объектов.
Я имел ввиду XSLT преобразование — оно традиционно не быстро идет.
Сделать по дереву объектов XML, а лучше сразу DOM вобщем-то много
времени не займет. Особенно если кэшировать информацию о классах
> ДЦ> Короче тема интересная, есть о чем подучать > > Ещё встаёт вопрос об однозначном представлении дерева объектов в дерево > XML. Ведь дерево объектов оно и не свосем дерево, а сеть.
Ну тут довольно просто делается — наложить ограничение и при
генерации проверять, если что не так new Error(...
Это как раз не вопрос.
--
WBR Денис Цыплаков /* jabber UID: denis.tsyplakov@jabber.ru */
Знающий не говорит, говорящий не знает
Replicator пишет:
> ДЦ> Можно попровать автоматом строить по Ява бин объектам XML c > ДЦ> с помощью reflection и аннотаций и уже к постоенному применять XSLT > > вот это промежуточное действо как раз хочется исключить...
Ну если XSLT то исключить не получится но можно свести к одной
строчке. См. пост выше по дереву.
> ДЦ> т.к. основная проблема сдесь — не по чему строить — а язык > ДЦ> описывающий, как строить и лучше чем XSLT+XPath я на эту тему пока не > ДЦ> встречал. > > вот я тоже эту связочку люблю. где то я определенно что то видел на тему > XPath но для работы с объектами...
Здесь то собака и зарулась — ну очень уж язык хорош.
--
WBR Денис Цыплаков /* jabber UID: denis.tsyplakov@jabber.ru */
Знающий не говорит, говорящий не знает
К тому же после переезда с jsp использование custom tags во фримаркере довольно полезная вещь.
