Присматрияваюсь я к этому Velocity, и все никак не могу найти очевидных плюсов.
1 если вам претит код в JSP - то его можно запретить специальной дерективой + проверка при автоматической сборке приложения.
2 Интерграция с многими достаточно популярными фреймворками хромает очень сильно
3 Мне лично не поянтно, если используется сложная логика в оотбражении, к примеру циклы, условия и прочее, то шаблон все равно выглядит мягко скажем некрасиво.
4 Тут упоминалось что отдал шаблон дизайнеру и сказал какие тэги, а можно пойти и от обратного, дизайнер отдал тебе шаблон и ты заменил нужные фрагменты на тэги, плюс я не совсем понимаю как дизайнер будет описывать таблицы с навигацией.
5 Как ни крути но скорость скомпилированного JSP всетаки выше чем постоянный прогон через шаблон.

Я не спорю, что velocity полезная штука и находит свое применение. Но это к сожалению/счастью НЕ стандарт.
Недавно столкнулся с проектом использующим Velocity для генерации jsp страниц, которые потом еще раз обрабатывались видимо внутренним движком. Реализовано все было жутко, поэтому беда плохого кода/страниц это не беда технологии это беда программистов ее использующих. 

Сейчас я довольно долгое время уже пишу на JSF, не скажу что все устраивает, но по крайней мере мне нравится.
Velocity это все таки front-end, практически не затрагивающий серверную часть, многие как я понимаю, предпочитают использовать его вместе с Spring.

Хотелось бы тут увидеть не описание вроде такого: ооо какой это крутой/хороший/замечательный фреймворк.
А к примеру такое: на нем можно сделать такое и такое, зато к сожалению нельзя так то и так то.

Маленький камушек в огород jsp:
На jsp никогда не получишь точно-такого результата в html (посимвольно), как хотелось бы -- все равно какие-то пробелы, переносы строк на месте скриптов и т.п. мусор. При использовании jsf ситуация в этом смысле усугубляется. Понятное дело, что все более менее отлажено и браузеры допускают подобные вольности, они привыкли хавать и не такое, и при желании можно подчищать на выходе (хотя на практике этого никто не делает) но все же как то не кошерно..
На Velocity же получаешь именно то, что написал в шаблоне, в силу специфики технологии.

Маленький камушек в огород Velocity -  как у етой технологии с reusability?
По моему reusability ето главный  и определяющий плюс jsp/jsf над Velocity.

Можно полюбопытствовать, о какой reusability мы говорим? Между проектами, между страницами одного веб приложения или еще какой-то другой?

Так вот, смею заверить, что reusability вполне удовлетворительная, причем в распоряжении разрабатчика имеется целый ворох средств для ее достижения: от макросов и включаемых подшаблонов до самописных компонентов, которые сами умеют себя отрисовывать.

В то время как в JSP включение одних страниц в другие (а) менее гибкое, (б) более накладное, за счет инициации дополнительных циклов обработки запроса, и (в) исключает возможность сколько-нибудь вразумительной стратегии обработки ошибок внутренних страниц.

Так что см. эпиграф 

Stampede, спорить с Вами не возьмусь. Просто высказал мнение.

Участвовал в проетке, который создовался на базе Struts 1.3, и вйю часть была как раз на Velocity.
Не могу сказать что было плохо... 

А сейчас создаём достаточно болшое веб приложение на JSF - испольсуем Trinidad имплементацию, а так же кое что из Tomohawk.


Так вот... Думаю ето же приложение (что сейчас на JSF делаем) с велосити делалось бы раз так... Может в 5 дольше.
Ето одно. Следующее - писать используя Velocity гораздо приятней, по скольку, как упомянул Maksym, что напишеш, то и будет 

Гораздо красивей ХТМЛ получается. Всё под твоим контролем.


А какая именно reusability? В принципе обе упомяннутые. 

P.S А дом у меня не стеклянный ;)

Соглашусь, что проигрыш во времени разработки на раннем этапе возможен, не в 5 раз конечно, а раза в 1.5. Но, думаю, это с лихвой окупится в дальнейшем развитии и поддержке.

Делаю вьюхи на XSLT, решил попробовать велосоти! как у него с мультипоточностью или он  как XSLT?

A как же быть с custom tagami в velocity?   

Tony, custom tags - вообще довольно спорная штука.
Лично я считаю, что ои не обеспечивают "чистого" подхода.

Ну как же тогда решить типовые зада4и? Кастом таги спровляутся с этим на ура. Но вапрос я ставил именно про Velocity a не jsp

Где-то странице на второй Stampede планировал дать подробный перечень минусов Velocity, но по неизвестным причинам так и не выложил материал. Возможно ли в ближайшее время возместить этот недостаток?

Где должен лежать шаблон для того, чтобы его увидела прога из первого примера?
Я получаю это


Писано в Идее... шаблон лежит прямо рядом с классом... 

Как вообще сконфигурировать, чтоб шаблоны брались из нужного места....   уже прямой путь указываю -все равно тоже самое...

Добавлено через 8 минут и 8 секунд

Shaggie, вопрос твой видел, да все как-то руки не доходили. А тут пришлось вплотную повозиться с Velocity, вот и решил по горячим следам отписаться.

Итак, минусы... Во-первых, должен заметить: не такие уж это в общем и минусы, а так - где-то глючок, где-то бажок, где-то неудобство, где-то ограничение... Забегая вперед, сразу хочу сказать: ничего фатального там нет. Все можно обойти, порешать, извернуться. Но, конечно, лучше знать об этих "особенностях" заранее. Именно с этой целью: предупредить начинающего пользователя Velocity об имеющихся подводных граблях, я и пишу этот пост.

Пойдем по порядку.

1. Некорректное сравнение чисел разных типов

Действительно, водится такой грешок. Например, все литеральные целочисленные константы в шаблонах приводятся к типу Integer. Если мы попытаемся сравнить их с переменной типа long, то результат нас может маленько обесуражить:





Вопреки нашим ожиданиям, Velocity сообщит нам, что Нью Йорк - это деревня. А получается вот что: поскольку Long у них не сравнивается с Integer, то результатом сравнения будет false независимо от значений чисел. Спрашивается, что делать?

Ну, прежде всего об этой "фиче" нужно знать. Тогда ее можно легко обойти. Например, написав собственный универсальный компаратор:



И теперь, заранее положив экземпляр компаратора в контекст (например, под именем "cmp") и исправив условие:



мы получим желаемый результат. Телемаркет!

2. Редактирование макросов на лету

В Velocity есть такая удобная штука как автоподхват изменений, внесенных в файл с макросами. Контролируется это дело параметром velocimacro.library.autoreload. По умолчание стоит в true.

К сожалению, при некоторых условиях эта штука не срабатывает, и бывает очень непонятно, когда ты что-то изменил, жмешь рефрешь, а изменений-то и не видно. В результате приходится перезапускать приложение.

А дело, оказывается, в том, что если при парсинге макросов была встречена ошибка, то файл помечается как дефектный и на изменения больше не проверяется. Хотя вызовы макросов обрабатываются как ни в чем ни бывало! Хороша логика, да? Впрочем, кому щас легко...

Между тем выход прост: добиваться, чтобы ошибок в файле макросов не было. Для этого надо грамотно настроить логирование и время от время чекать сообщения об ошибках.


3. Рекурсивный вызов макросов

Увы, иногда бывает так, что все вроде работает хорошо, но ошибка при инициализации Velocity все-таки выскакивает, тем самым лишая нас возможности править макросы на лету (см. предыдущий пункт). Одна из печально известных ошибок такого рода - это парсинг макроса, содержащего рекурсию. В этом случае Velocity говорит нам: "too few arguments to macro".

Спрашивается, можно ли это починить? Ответ - ДА! Надо просто взять более свежую версию движка. Начиная с Velocity v1.5. эта дурацкая ошибка не будет вас беспокоить.


4. Экранирование спецсимволов

Иногда возникают ситуации, когда требуется записать строковую константу, в которой присутствуют кавычки или еще какие-нибудь спецсимволы. Вообще-то это происходит нечасто, потому что в большинстве случаев можно обойтись удобной фичей Velocity, позволяющей заключать строки на выбор в кавычки или в апострофы. Например:



Как видим, мы заключили строку в апострофы, и это позволило нам передать в некий макрос валидно оформленную HTML ссылку. Но я еще раз повторяю, это спасает не всегда. Как быть?

А запросто. Надо просто определить переменную, значением которой является нужный символ, и подставлять ее там где надо. Вот смотрите:



Для нашего удобства в состав Velocity Tools входит штука под названием EscapeTool. В нем предусмотрены методы, которые возвращают всякие полезные спецсимволы. Если положить его экземпляр в контекст (скажем, под именем "esc"), то вставлять кракозябры в текст становится достаточно просто. Например, вот так мы выведем значок доллара:



Ну и еще EscapeTool может эскейпить УРЛы, строки Java, JavaScript,  XML, вышивать крестиком и делать прочие полезные вещи.

И таких полезных тулов там еще очень много. Ну а если для ваших изысканных нужд в тулбоксе ничего не нашлось, всегда можно написать самому. Тем более что это совсем нетрудно.

Вот такой вот неполный, но, надеюсь, достаточно показательный перечень "минусов Velocity".

Удачи в избегании граблей! 

Это сообщение отредактировал(а) Stampede - 3.10.2007, 20:15

На минусы технологии этот перечень, действительно, не претендует.

Это сообщение отредактировал(а) batigoal - 3.10.2007, 20:17