Полезное для программистов:

Фриланс
Новости
Статьи
   
Рубрики:

Error. Page cannot be displayed. Please contact your service provider for more details. (15)


Velocity ч. 1

Поиск:
1. Ты помнишь, как все начиналось...

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

Код

OutputStream out = response.getOutputStream();
out.println("<htm>");
out.println("<head><title></title> <link type=\"text/css\" rel=\"stylesheet\" href=\"/css/style.css\" /></head>");
out.println("<body bgcolor=\"green\">");

// bla-blah-blah



И когда разработчики получили в свои руки технологию, которая позволяла им (в теории) разделять модель, вью и контроллер, то они решили, что настало полное и всеобщее щастье, и стали дружно все лабать на 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 код, только вместо конкретных строк фигурируют конструкции вида:

Код

<title>$article_title</title>
<div class="header">
 <p>Автор: <a href="$author_url">$author_name</a>
 <p>Отправлено: $article_date_сreated
</div>
<div class="text">
$article_text
</div>


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

Код

<title>$article.title</title>
<div class="header">
 <p>Автор: <a href="$article.author.url">$article.author.name</a>
 <p>Отправлено: $article.dateCreated
</div>
<div class="text">
$article.text
</div>


Вы не находите, что это элегантно, просто, удобно, читабельно, сопровождаемо - это, наконец, просто красиво! И, в отличие от JSP, это промоутит правильный дизайн с самого начала. Почему? Потому что такой подход мягко и ненавязчиво принуждает вас думать о вашем приложении в терминах объектов, которые наиболее естественным образом описывают вашу предметную область - потому что это именно то, что вы будете передавать вашим страницам, и чем эти страницы будут оперировать. Вы скажете, да это же просто бины! Бины, да не совсем.

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

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

Код

public static boolean mergeTemplate(java.lang.String templateName,
                                   Context context,
                                   java.io.Writer writer)


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

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

Код

String artid = request.getParameter("artid");
Article article = yourResourseLocator.getArticle(artid);

Context context = new VelocityContext();
context.put("article", article);


И фсе! Слейте созданный таким образом контекст с описанным ранее шаблоном, и у вас получится отличная веб страница!

Я не буду рассказывать о различных конструкциях Velocity, предназначенных для облегчения вам жизни: set, if-else, foreach, include, macro и других - поверьте, у них очень простой синтаксис, и они хорошо документированы. Давайте лучше поговорим о более высоких вещах - например, об инверсии управления.

4. Немного об инверсии

Я не буду долго разливаться мыслю по древу о том, что такое инверсия управления. Если на пальцах, это такая организация системы, при которой ты смотришь на вещи и думаешь в терминах понятий иных, нежели в другом подходе. Например, event-driven подход к программированию гуя - это инверсный подход по сравнению с тем, когда ты всю логику программируешь в классе окна, ждешь всяких событий и как-то на них реагируешь.

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

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

Создатели JSP как спецификации этого абсолютно не понимали, а вслед за ними не понимают этого и миллионы разработчиков, последовавшие за ними. Мне горько и обидно это видеть, что, собственно, и побудило меня сесть и написать эту статью.

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

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

До новых встреч в эфире! :)
Автор: Stampede
Сайт: http://real-english.ru






Просмотров: 4067

 

 

Новые статьи:


Популярные:
  1. Как сделать цикличным проигрывание MIDI-файла?
  2. Создание AVI файла из рисунков
  3. Как устройство "отключить в данной конфигурации"?
  4. Kто в данный момент присоединен через Сеть?
  5. Как узнать количество доступной памяти?
  6. Как реализовать в RichEdit разноцветный текст?
  7. Как скрыть свое приложение от ProcessViewer
  8. Как программно нажать/скрыть/показ кнопку "Start"?
  9. Модуль работы с ресурсами в PE файлах
10. Функции вызова диалоговых окон выбора
11. Проверка граматики средствами Word'а из Delphi.
12. Модуль для упрощенного вызова сообщений
13. Функции для записи и чтение своих данных в, ЕХЕ- файле
14. Рекурсивный просмотр директорий
15. Network Traffic Monitor
16. Разные модули
17. Универсальная функция для обращения к любым экспортируем функциям DLL
18. Библиотека от VladS
19. Протектор для UPX'а
20. Еще об ICQ, сообщения по контакт листу?
21. Использование открытых интерфейсов
22. Теория и практика использования RTTI
23. Работа с TApplication
24. Примеры использования Drag and Drop для различных визуальных компонентов
25. Что такое порт? Правила для работы с портами
26. Симфония на клавиатуре
27. Загрузка DLL
28. Исправление автоинкремента
29. Взаимодействие с чужими окнами
30. Проверить дубляжи в столбце


 

 

 
 
На главную