 |
|
Модераторы: LSD, AntonSaburov |
 
|
|
Набираем Velocity 
| batigoal |
|
|||
 Нелетучий Мыш  Профиль Группа: Участник Клуба Сообщений: 6423 Регистрация: 28.12.2004 Где: Санктъ-Петербургъ Репутация: 16 Всего: 151 |
А разве на JSTL этого нельзя сделать?
-------------------- "Чтобы правильно задать вопрос, нужно знать большую часть ответа" (Р. Шекли) ЖоржЖЖ |
|||
|
||||
Загрузка ...
| Stampede |
|
|||
 Гносеолог Профиль Группа: Участник Клуба Сообщений: 963 Регистрация: 25.4.2005 Где: Calgary, Alberta, Canada Репутация: 66 Всего: 144 |
Я могу (и хочу) много-много написать о том, почему Velocity раз так в восемьдесят пять лучше JSP, но мы сейчас уезжаем на длинные выходные в Банфф, так что вернусь не раньше понедельника. А тем, у кого есть неясности/сомнения, советую пока что погуглевать по слову IoC - inversion of control. Дело в том, что IoC - это не самый очевидный (и часто опускаемый в обсуждениях) аспект использования Velocity, но на мой взгляд это самое важное. До понедельника! |
|||
|
||||
| simanyay |
|
|||
 Антон Ковалёв Профиль Группа: Участник Сообщений: 2053 Регистрация: 22.8.2002 Репутация: 2 Всего: 36 |
Ждём-с с нетерпением  Гуглим до понедельника. -------------------- «It's better to be a pirate than to join the Navy» — Steve Jobs. |
|||
|
||||
| Chinook |
|
|||
|
Новичок Профиль Группа: Участник Сообщений: 8 Регистрация: 21.5.2005 Где: Vancouver, BC, Ca nada Репутация: нет Всего: нет |
Это как-то очень слабо напоминает HTML, и выучить это html-девелоперу никак не легче, чем библиотеки тегов, которые намного больше похожи на HTML. IMHO. |
|||
|
||||
| Stampede |
|
||||||||||
|
Гносеолог Профиль Группа: Участник Клуба Сообщений: 963 Регистрация: 25.4.2005 Где: Calgary, Alberta, Canada Репутация: 66 Всего: 144 |
Ну. поехали...
1. Ты помнишь, как все начиналось... Начну я не с Velocity, а начну я издалека, с JSP. Изначально технология JSP задумывалась как дополнение к сервлетам, и должна была стать нашим ответом Чемберлену, то бишь мелкософту с их ASP. И была она в общем неплохой технологией, по крайней мере по сравнению с временами, когда разработчикам приходилось писать код вроде
И когда разработчики получили в свои руки технологию, которая позволяла им (в теории) разделять модель, вью и контроллер, то они решили, что настало полное и всеобщее щастье, и стали дружно все лабать на JSP. О новой технологии тут же раструбили по всем жабным изданиям, понавыпускали книжек, и пошло-поехало. Как же, ведь Sun опубликовал стандарт, под который можно писать веб приложения, которые будут исполняться в любом контейнере! Слава открытым спецификациям! Даешь конкурентный рынок контейнеров! Эйфория от появления новой технологии была настолько сильной, а пиар - таким массированным, что в массовом сознании очень быстро сложился стереотип: J2EE веб приложение == Servlets + JSP. Но за фанфарами остался незамеченным один маленький факт: что JSP - это отнюдь не единственная и совсем не обязательно самая лучшая технология для генерации динамических веб страниц. 2. Не все то золото, что кричит Например, очень скоро выяснилось, что код JSP в реальном сложном приложении получается малость тово, запутанный. Да так, что подчас вообще хрен разберешь, что на ней делается. Потому что бины бинами (модель), а во вью все равно приходится использовать кучу логики, в первую очередь условия и циклы. И хоть данную проблему с горем пополам все-таки решили путем введения библиотеки тегов, но код все равно остался громоздким, неудобочитаемым и плохо сопровождаемым - из-за обилия Java вставок. Присутствие большого числа Java-вставок на страницах - это, увы, непреложный медицинский факт , и происходит это по одной простой причине: потому что JSP это позволяет. Понимаете, технология JSP просто сама напрашивается, подставляется, чтобы ее хакнули (хакнули не во взломном, а в технологическом понимании). А программисты и рады стараться, без зазрения совести хакают ее во все дыры - а что, сама напросилась. Происходит это примерно так: возникает новое требование, скажем, добавить еще полей к таблице, или там поменять порядок сортировки, или еще что-нибудь. Если делать это по грамотному, то надо бы дописать классов, выделить что-то в общий интерфейс, кое-что срефакторить, ну и т. д. Делать это - в лом. Нафиг, когда можно прямо на странице написать методец. котрый по-быстрому пофиксит ситуацию. Часто ли такое происходит? Сплошь и рядом, особенно в ситуациях, когда готово должно было быть еще вчера. Как следствие, через какое-то время страницы оказываются просто завалены вставками - бестолково написанными, с массой дублированного кода, раскиданного по разным стрвницам. И не надо думать, что это происходит только на поздних этапах жизненного цикла приложения. Даже во время непосредственно разработки, на пути от прототипа к готовому продукту, все время возникают новые требования, всплывают разные нюансы и т. д. Так вот, самая большая беда JSP как технологии, на мой взгляд, это то, что она does not promote good design (не промоутит правильный дизайн?). На самом деле JSP вполне можно приспособить в качестве удовлетворительной вью технологии, и я вернусь к этой теме после разговора о Velocity. 3. И тут на сцене появляется... Правильно, вы угадали. Появляется Velocity, собственной персоной. Если точнее, то целая группа шаблонных движков: FreeMarker, WebMacro и т. д. Основная идея была позаимствована из скриптовых языков типа PHP: ты передаешь странице кучу параметров (например, через переменные окружения), а в коде страницы ссылаешься на них по имени. В результате у тебя получается относительно чистый HTML код, только вместо конкретных строк фигурируют конструкции вида:
Но дело не ограничивается одними строками. Благодаря наличию такой штуки как интроспекция, в жабных шаблонных движках появилась вожможность ссылаться на методы и переменные классов очень простым образом:
Вы не находите, что это элегантно, просто, удобно, читабельно, сопровождаемо - это, наконец, просто красиво! И, в отличие от JSP, это промоутит правильный дизайн с самого начала. Почему? Потому что такой подход мягко и ненавязчиво принуждает вас думать о вашем приложении в терминах объектов, которые наиболее естественным образом описывают вашу предметную область - потому что это именно то, что вы будете передавать вашим страницам, и чем эти страницы будут оперировать. Вы скажете, да это же просто бины! Бины, да не совсем. Например, на бины в JSP достаточно неудобно ссылаться. Кроме того, их надо явно описывать. Потом, сама модель использования бинов в JSP предполагает pull-характер их создания и инициализации, при этом бины сами ответственны за доступ к данным. То есть страница должна вытягивать данные, которые ей нужны, причем последовательность доступа к данным нередко определяется порядком, в котором элементы появляются на странице, что есть не всегда самый лучший или безопасный порядок. В противоположность этому, Velocity исповедует принципиально иной, push-подход, при котором сервлет (или его делегат - но об этом чуть позже), зная, что должно быть на странице, подготавливает всю необходимую информацию, и затем пихает все это в шаблон. Или, точнее, передает шабонному движку вместе с шаблоном для разрешения имен. В терминах Velocity это называется слиянием:
Вы, конечно, заметили, что одним из параметров передается Writer, но не придали этому значения. А значение придать - категорически необходимо. Потому что это показывает, что Velocity никоим образом не привязан к выводу в сокеты, и если говорить по большому счету, то и вообще к веб окружению. А это значит, что одни и те же страницы можно использовать для генерации чего угодно: писем, оффлайновых отчетов, SQL запросов - тут все ограничивается только вашей фантазией. Второй параметр, который передается движку, возможно, вас несколько озадачил: Context context. Не надо его бояться. Velocity контекст - это, грубо говоря, просто HashMap, в который вы суете объекты для страницы, а ключом к этим объектам служат имена, по которым вы ссылаетесь на них из шаблона. Код для запихивания выглядит очень просто:
И фсе! Слейте созданный таким образом контекст с описанным ранее шаблоном, и у вас получится отличная веб страница! Я не буду рассказывать о различных конструкциях Velocity, предназначенных для облегчения вам жизни: set, if-else, foreach, include, macro и других - поверьте, у них очень простой синтаксис, и они хорошо документированы. Давайте лучше поговорим о более высоких вещах - например, об инверсии управления. 4. Немного об инверсии Я не буду долго разливаться мыслю по древу о том, что такое инверсия управления. Если на пальцах, это такая организация системы, при которой ты смотришь на вещи и думаешь в терминах понятий иных, нежели в другом подходе. Например, event-driven подход к программированию гуя - это инверсный подход по сравнению с тем, когда ты всю логику программируешь в классе окна, ждешь всяких событий и как-то на них реагируешь. Так вот, Velocity, как уже говорилось, принуждает вас смотреть на вещи несколько отличным образом по сравнению с тем, к чему принуждала вас технология JSP, и в этом смысле может характеризоваться как инверсия управления. Но семантически у меня просто язык не поворачивается назвать инверсией то, что ставит вещи с головы обратно на ноги. Само слово инверсия содержит намек на какую-то шиворот-навыворотность. Но ведь Velocity не виновата, что JSP появилась первой и насадила стандарт веб-программистского мышления, который, если вдуматься, и был шиворот-навыворотным с позиций здравой логики. А здравый смысл говорит нам, что думать о системе надо в первую очередь в терминах того, что эта система должна хорошего делать, и лишь потом - о том, как присобачить ко всему этому веб интерфейс. То есть система бронирования авиабилетов должна хорошо бронировать авиабилеты, электронный аукцион - помогать совершать акты купли-продажи, а система документооборота - вести учет движения документов. Какой при этом у системы будет интерфейс - совершенно фиолетово: это может быть автоматический телефонный сервис, толстый клиент, веб интерфейс, межмашинный интерфейс в виде веб-сервисов, и т. д. Создатели JSP как спецификации этого абсолютно не понимали, а вслед за ними не понимают этого и миллионы разработчиков, последовавшие за ними. Мне горько и обидно это видеть, что, собственно, и побудило меня сесть и написать эту статью. Надеюсь, я смог донести основные положения, из которых складывается мое видение ситуации с веб разработкой, и то. какое место в нем занимает Velocity. В качестве примера того, как это видение получило практическую реализацию, можете взглянуть на мой сайт Английский без дураков. Надеюсь, наш разговор о Velocity не закончен, и после вашей конструктивной критики мы продолжим обсуждение. До новых встреч в эфире! |
||||||||||
|
|||||||||||
| Domestic Cat |
|
|||
 Эксперт Профиль Группа: Экс. модератор Сообщений: 5452 Регистрация: 3.5.2004 Где: Dallas, US Репутация: 13 Всего: 172 |
-------------------- |
|||
|
||||
| simanyay |
|
|||
|
Антон Ковалёв Профиль Группа: Участник Сообщений: 2053 Регистрация: 22.8.2002 Репутация: 2 Всего: 36 |
 Я понял зачем нужен Velocity! Буду юзать его в Jizer'e. Спасибо. -------------------- «It's better to be a pirate than to join the Navy» — Steve Jobs. |
|||
|
||||
| Souljah |
|
|||
|
Шустрый Профиль Группа: Участник Сообщений: 148 Регистрация: 24.12.2004 Репутация: 3 Всего: 7 |
тов. Stampede не в первый раз радует меня трезвостью мышления
поставьте плз + от моего имени, а то я еще не дорос до такого действа |
|||
|
||||
| batigoal |
|
|||
|
Нелетучий Мыш Профиль Группа: Участник Клуба Сообщений: 6423 Регистрация: 28.12.2004 Где: Санктъ-Петербургъ Репутация: 16 Всего: 151 |
Это всегда пожалуйста. -------------------- "Чтобы правильно задать вопрос, нужно знать большую часть ответа" (Р. Шекли) ЖоржЖЖ |
|||
|
||||
| pvo |
|
|||
|
Шустрый Профиль Группа: Участник Сообщений: 92 Регистрация: 7.10.2005 Где: Мск Репутация: 5 Всего: 7 |
Velocity штука конечно хорошая. Но есть у нее пара изрядных минусов:
1. С рекурсией проблемы. Если передать в шаблон объект с "деревянной" структурой, то построить результирующий документ без танцев с бубнами не получится. (в версии 1.3, по крайней мере) 2. Скорость. Как не крути, но она меньше, чем у jsp. Компилятор-то пока-что не дописан ...  |
|||
|
||||
| Stampede |
|
||||||
|
Гносеолог Профиль Группа: Участник Клуба Сообщений: 963 Регистрация: 25.4.2005 Где: Calgary, Alberta, Canada Репутация: 66 Всего: 144 |
Минусы, конечно, есть, но вот именно по поводу перечисленного - возражаю.
Что в данном случае понимается под рекурсией? Рекурсивный вызов макросов? Честно говоря, не знаю, не пробовал, но беглый поиск в гугле показывает, что с этим проблем быть не должно. Наоборот, там один чувак жалуется, что Velocity не ограничивает глубину рекурсии, из-за чего его программа иногда подвисает. Держите, говорит, меня семеро, а то если я разойдусь, так уж разойдусь Да, речь там идет о 1.4.
Я могу с цифрами в руках доказать, что разница как минимум несущественна, и что затраты времени на собственно рендеринг совершенно пустяковые. Помимо этого, я предлагаю поспорить на тему того, как общая архитектура веб приложения может быть значительно более критическим фактором в плане производительности, чем выбор той или иной технологии рендеринга. А про минусы я потом скажу отдельно |
||||||
|
|||||||
| Ортхэннер |
|
|||
 Новичок Профиль Группа: Участник Сообщений: 23 Регистрация: 29.1.2005 Где: Благовещенск Репутация: нет Всего: нет |
М-да. А вы вот объясните, господа, чем, кроме синтаксиса, отличается Velocity от JSPX+JSTL. А то я немного не понимаю. Дело в том, что, как показывает практика, вставлять галимый Java-код в JSPX-страницы, мягко говоря, обломно. Если и получится - прочитать это точно будет потом нельзя. Но получается зачастую не с первого раза и выглядит жутко. А вот с библиотеками тегов и EL'ем - очень красиво и очень просто.
|
|||
|
||||
| pvo |
|
|||
|
Шустрый Профиль Группа: Участник Сообщений: 92 Регистрация: 7.10.2005 Где: Мск Репутация: 5 Всего: 7 |
1. Гибкостью. Например, есть у нас Velocity & JSP шаблоны некоторой html страницы. В один прекрасный момент нам требуется отправить эту страницу по почте, причем не в процессе обслуживания запроса (ServletRequest не доступен). Что нужно будет делать в случае с jsp? \ В случае с велосити один и тот же код можно использовать и для генерации html, и для генерации email. 2. Обломно или не обломно добавлять java код в jsp страницы, но народ все равно упорно это делает. 3. Лаконичностью. ИМХО, понять шаблон velocity проще, нежели многие jsp шаблоны с использованием кучи кастом тегов ... |
|||
|
||||
| Guest |
|
|||
|
Unregistered |
То, что Velocity на порядок выше JSP - не вопрос!
JSP - это дань старым и корявым технологиям, типа PHP, ASP и прочия... Но они решают свою нишу задач, типа быстро нацарапать сайт из 10 страниц с несложным функционалом. Для серьезных вещей уровня предприятия, такие движки не самый лучший выбор. Тут на сцену выходит Velocity и другие фрамеворки,а вот сравнивать его с другими технологиями и имеет смысл! Например, ХМЛ+ХСЛТ! Мое мнение, он тут проигрывает.... |
|||
|
||||
| Ортхэннер |
|
||||
|
Новичок Профиль Группа: Участник Сообщений: 23 Регистрация: 29.1.2005 Где: Благовещенск Репутация: нет Всего: нет |
Да я вообще-то не про JSP, а про JSPX. Это несколько разные вещи с разным синтаксисом. И добавить код java в JSPX-страницу - задача довольно трудоёмкая. Ибо приходится все кавычки и знаки сравнения заменять соответствующими сущностями. Головняк ещё тот. К тому же, хоть убей, ты уже не сможешь задействовать выражения в атрибутах (типа <%=a%>). По поводу "кучи кастом тегов" - ну это скорее вопрос именования. Но вот первый пункт... принял. Это сообщение отредактировал(а) Ортхэннер - 8.11.2005, 06:20 |
||||
|
|||||
|
|
| Правила форума "Java" | |
|
|
Если Вам помогли, и атмосфера форума Вам понравилась, то заходите к нам чаще! С уважением, LSD, AntonSaburov, powerOn, tux. |
| 0 Пользователей читают эту тему (0 Гостей и 0 Скрытых Пользователей) | |
| 0 Пользователей: | |
| « Предыдущая тема | Java EE (J2EE) и Spring | Следующая тема » |
[ Время генерации скрипта: 0.1780 ] [ Использовано запросов: 22 ] [ GZIP включён ]
Реклама на сайте Информационное спонсорство
|
|
По вопросам размещения рекламы пишите на vladimir(sobaka)vingrad.ru
Отказ от ответственности Powered by Invision Power Board(R) 1.3 © 2003 IPS, Inc. |