Каждый разработчик, использующий сегодня сервлеты, знает JSP, веб-технологию, изобретенную Sun Microsystems, и приложил много усилий для продвижения и развития технологии сервлетов. JSP отделяет HTML-код от сервлета, тем самым ускоряя разработку веб-приложений и обслуживание страниц. Фактически, официальный документ «Модель разработки приложений», опубликованный Sun, идет еще дальше: «Технологию JSP следует рассматривать как стандарт, а сервлеты в большинстве случаев можно рассматривать как дополнение» (раздел 1.9, 1999/12/15). Послушайте мнение версии).
Цель этой статьи — услышать оценку правдоподобности этого утверждения путем сравнения JSP с другой технологией, основанной на сервлетах: механизмами шаблонов.
Проблемы с непосредственным использованием сервлетов
Изначально сервлеты были изобретены, и весь мир увидел их превосходство. Динамические веб-страницы, основанные на сервлетах, могут выполняться быстро, легко переносить между несколькими серверами и идеально интегрироваться с внутренней базой данных. Сервлеты широко признаны предпочтительной платформой для веб-серверов.
Однако HTML-код, который обычно реализуется простым способом, теперь требует от программиста вызова out.println() для каждой строки HTML, что стало серьезной проблемой в реальных приложениях сервлетов. HTML-контент должен быть реализован с помощью кода, что является утомительной и трудоемкой задачей для больших HTML-страниц. Кроме того, людям, ответственным за веб-контент, пришлось нанимать разработчиков для внесения всех обновлений. По этой причине люди ищут лучшее решение.
JSP прибывает!
Появилась JSP 0.90. В этом методе вы встраиваете код Java в файл HTML, и сервер автоматически создает сервлет для страницы. JSP считается простым способом написания сервлетов. Весь HTML-код можно получить напрямую, без вызова out.println(), а лицо, ответственное за содержимое страницы, может напрямую изменять HTML-код, не рискуя нарушить код Java.
Однако когда художники страниц и разработчики работали над одним и тем же файлом, это было не идеально, а встраивание Java в HTML оказалось таким же неловким, как и встраивание HTML в Java. Читать беспорядочный код по-прежнему сложно.
В результате люди стали более зрелыми в использовании jsp и стали больше использовать JavaBeans. Компоненты содержат код бизнес-логики, необходимый для jsp. Большую часть кода JSP можно вынести и поместить в компонент, оставив лишь очень небольшой объем разметки для вызова компонента.
В последнее время люди начали думать, что страницы JSP в этом смысле действительно похожи на представления. Они становятся компонентом, используемым для отображения результатов клиентских запросов. Вот люди и подумают, а почему бы не отправить запрос напрямую на просмотр? Что произойдет, если целевое представление не подходит для запроса? В конце концов, многие запросы имеют несколько возможностей получить представление результатов. Например, один и тот же запрос может создать успешную страницу, отчет об ошибке базы данных или отчет об ошибке с отсутствующими параметрами. Один и тот же запрос может создать страницу на английском или испанском языке, в зависимости от языкового стандарта клиента. Почему клиент должен отправлять запрос непосредственно в представление? Почему клиент не должен отправлять запрос какому-то общему серверному компоненту и позволить серверу решать, что возвращает представление JSP?
Это привело многих людей к принятию того, что стало известно как « Модель 2". Это модель, основанная на модели-представлении-контроллере, определенная в JSP 0.92. В этом проекте запросы отправляются контроллеру сервлетов, который выполняет бизнес-логику и генерирует аналогичную «модель» данных для отображения. Затем эти данные передаются внутри «представления» JSP для отображения, благодаря чему страница JSP выглядит как обычный встроенный JavaBean. Соответствующую страницу JSP можно выбрать для отображения на основе внутренней логики сервлета, отвечающего за управление. Таким образом, файл JSP становится красивым представлением шаблона. Это еще одна разработка, которая по сей день хвалится другими разработчиками.
Введите механизм шаблонов
и используйте механизм шаблонов для замены JSP общего назначения. Последующий дизайн станет проще, синтаксис станет проще, сообщение об ошибке будет легче читать. , и инструменты станут более удобными для пользователя. Несколько компаний создали такие движки, самая известная, вероятно, WebMacro ( http://webmacro.org , от Semiotek), и их движок бесплатен.
Разработчики должны понимать, что выбор механизма шаблонов для замены JSP дает такие технические преимущества, которые также являются некоторыми недостатками jsp:
Проблема № 1: код Java слишком шаблонизирован
. Хотя это считается плохим дизайном, JSP все же пытается добавить Java. код на веб-страницу. Это чем-то похоже на то, что когда-то делал Java, который представлял собой упрощенную модификацию механизмов шаблонов C++, которая также упростила его за счет удаления исходного кода нижнего уровня в jsp. Механизмы шаблонов реализуют лучший дизайн.
Вопрос № 2: Требование кода Java
. На странице JSP необходимо написать код Java. Например, предположим, что страница определяет корневой контекст текущего веб-приложения и ведет на его домашнюю страницу.
Лучше всего использовать в JSP следующий код Java:
＜a href="＜%= request.getContextPath() %＞/index.html"＞Home page＜/a＞
Вы можете попытаться избежать кода Java и использовать тег
property="contextPath"/＞/index.html"＞HomePage＜/a＞
При использовании механизма шаблонов нет Java-кода и уродливого синтаксиса. Вот как это написано в WebMacro при тех же требованиях:
＜a href="$ Request.ContextPath ;/index.html">Домашняя страница
В WebMacro ContextPath используется как атрибут переменной $Request с использованием синтаксиса, подобного Perl. Другие механизмы шаблонов используют другие типы синтаксиса.
Рассматривая другой пример, предположим, что расширенному «представлению» необходимо установить файл cookie для записи цветовой конфигурации пользователя по умолчанию — эта задача, скорее всего, будет выполнена представлением, а не контроллером сервлета. В JSP должен быть такой код Java:
<% Cookie c = new Cookie("colorscheme", "blue"); response.addCookie(c); %>
В WebMacro нет кода Java:
#set $Cookie.colorscheme = «синий»
в качестве последнего иона, если вы хотите получить конфигурацию цвета в исходном файле cookie. Для JSP мы можем подумать о соответствующем классе инструментов, потому что было бы нелепо и сложно делать такие низкоуровневые вещи напрямую с помощью getCookies(). В JSP:
<% String Colorscheme = ServletUtils.getCookie(request, "colorscheme" %>
В WebMacro обычно нет необходимости использовать классы инструментов: $Cookie.colorscheme.Value. Какой синтаксис легче выучить художникам-графикам, пишущим JSP?
В JSP 1.1 появились пользовательские теги, которые позволяют произвольным HTML-тегам выполнять Java-код в фоновом режиме на страницах JSP. Это будет иметь некоторую ценность, но только при наличии широко известной, полнофункциональной, свободно доступной, стандартизированной библиотеки тегов. В настоящее время такой библиотеки тегов не существует.
Проблема №3: Простые задачи все еще утомляют.
Даже простые задачи, такие как включение верхних и нижних колонтитулов, все еще очень сложны в JSP. Предположим, что на все страницы необходимо включить шаблон «заголовок» и «нижний колонтитул», и каждый шаблон должен содержать заголовок текущей страницы в содержимом.
Лучший способ в JSP:
＜% String title = «Заголовок страницы» %＞;
＜%@ include file="/header.jsp" %＞
...содержание вашей страницы...
＜%@ include file="/footer.jsp" %＞
Дизайнеры страниц должны помнить, что нельзя пропускать точку с запятой в первой строке и определять заголовок как строку. Кроме того, /header.jsp и /footer.jsp должны находиться в корневом каталоге и быть полностью доступными файлами.
Включить верхние и нижние колонтитулы в WebMacro относительно просто:
#set $title = "Заголовок страницы"
#анализ "header.wm"
Ваш контент здесь
#parse "footer.wm"
Дизайнерам не нужно запоминать точки с запятой или определения заголовков, а файлы .wm можно поместить в настраиваемый путь поиска.
Проблема № 4: Очень толстые циклы.
Зацикливание в JSP затруднено. Здесь JSP используется для многократной распечатки имени каждого объекта ISP.
<%
Перечисление e = list.elements();
в то время как (e.hasMoreElements()) {
out.print("Следующее имя ");
out.println(((ISP)e.nextElement()).getName());
out.print("
");
}
%>
Возможно, когда-нибудь появятся пользовательские теги для выполнения этих циклов. То же самое касается и «если». Страницы JSP могут выглядеть как странный Java-код. И в то же время цикл веб-макроса прекрасен:
#foreach $isp в $isps {
Следующее имя — $isp.Name
}
При необходимости директиву #foreach можно легко заменить специальной директивой #foreach-backwards.
Если вы используете jsp, это может выглядеть так: (Вот возможный тег
Следующее имя — ＜jsp:getProperty name="isp" property="name"/＞ ＜br＞.
＜/foreach＞
Дизайнер, естественно, выберет первое.
Проблема №5: Бесполезные сообщения об ошибках
JSP часто содержат неожиданные сообщения об ошибках. Это связано с тем, что страница сначала преобразуется в сервлет, а затем компилируется. Хорошие инструменты JSP могут относительно повысить вероятность обнаружения места ошибки, но даже самые лучшие инструменты не могут сделать все сообщения об ошибках легко читаемыми. Из-за процесса преобразования некоторые ошибки может оказаться невозможным для обнаружения инструментом.
Например, предположим, что странице JSP необходимо создать заголовок, общий для всех страниц. В следующем коде нет ничего плохого:
＜% static String title = "Global title" %＞
Но Tomcat выдаст следующее сообщение об ошибке:
работа/%3A8080%2F/JC_0002ejspJC_jsp_1.java:70: Ожидается утверждение.
статический счетчик int = 0;
^
Эта информация предполагает, что приведенный выше скрипт помещен в метод _jspService(), и в этот метод нельзя помещать статические переменные. Синтаксис должен быть <%! %>. Дизайнерам страниц трудно прочитать эти сообщения об ошибках. Даже лучшие платформы не справляются в этом отношении. Даже удаление всего кода Java со страницы не решает проблему. Кроме того, что не так со следующим выражением?
<% кол-во %>
кот дает:
work/8080/_0002ftest_0002ejsptest_jsp_0.java:56: Количество классов не найдено в
объявление типа.
считать
^
work/8080/_0002ftest_0002ejsptest_jsp_0.java:59: Неверное объявление.
out.write("rn");
^
Другими словами, это просто пропущенная отметка. Должно быть <%= count %>.
Поскольку механизм шаблонов может быть сгенерирован непосредственно из файла шаблона без какого-либо существенного перевода в код, очень легко предоставить соответствующие отчеты об ошибках. По аналогии, когда команда языка C вводится в командную строку оболочки Unix, вы не хотите, чтобы оболочка создавала программу C для запуска команды, а вам просто нужно, чтобы оболочка просто интерпретировала команду и выполнила ее. и напрямую сообщать о любых ошибках.
Проблема №6: Для использования компилятора
JSP требуется, чтобы компилятор был установлен на веб-сервере. Это стало проблематичным, поскольку Sun отказалась отказаться от библиотекиtools.jar, содержащей их компилятор javac. Веб-сервер может включать компилятор стороннего производителя, например Jikes от IBM. Но такой компилятор не работает бесперебойно на всех платформах (написан на C++) и не способствует созданию веб-сервера на чистом Java. В JSP есть опция предварительной компиляции, которая помогает, хотя она и не идеальна.
Проблема №7: Пустая трата места
JSP потребляет дополнительную память и место на жестком диске. Для каждого JSP-файла размером 30 КБ на сервере должен быть создан соответствующий файл класса размером более 30 КБ. Эффективно удваивает пространство на жестком диске. Учитывая, что файл JSP может легко включить большой файл данных через <%@include> в любое время, эта проблема имеет очень практическое значение. При этом данные файла классов каждого JSP должны быть загружены в память сервера, а это означает, что память сервера должна навсегда сохранить все дерево документов JSP. Некоторые JVM имеют возможность перемещать данные файла классов из памяти, однако программист обычно не контролирует правила повторного объявления, и повторное объявление может быть не очень эффективным для больших сайтов; Для механизмов шаблонов экономится место, поскольку второй файл не создается. Механизмы шаблонов также предоставляют программистам полный контроль над кэшированием шаблонов в памяти.
Существуют также некоторые проблемы с использованием механизма шаблонов:
Проблема шаблона № 1: строго не определено.
Как должен работать механизм шаблонов, строго не определено. Однако по сравнению с JSP это на самом деле не очень важно. В отличие от JSP, механизмы шаблонов не предъявляют каких-либо особых требований к веб-серверу — любой сервер, поддерживающий сервлеты, может поддерживать механизмы шаблонов (включая серверы API 2.0, такие как Apache/JServ, они есть). не полностью поддерживать JSP)! Если здоровая конкуренция за лучший дизайн шаблонизатора могла бы привести к потрясающим инновациям, особенно с продвижением открытого исходного кода (позволяющим идеям продвигать и продвигать друг друга), то Today WebMacro будет похож на Perl Это не имеет строгого определения, но стандартом является продвижение организаций с открытым исходным кодом.
Проблема шаблонов № 2: не распознаны
Механизмы шаблонов малоизвестны. JSP занял огромный коммерческий рынок и глубоко укоренился в сердцах людей. Использование механизмов шаблонов g может быть лишь непонятной альтернативной технологией.
Проблема шаблонов № 3: не развернуты.
Механизмы шаблонов еще не настроены должным образом. Тестирование производительности и сравнение механизма шаблонов и JSP не проводятся. Теоретически, хорошо развернутая реализация механизма шаблонов должна соответствовать хорошо развернутому JSP, однако, учитывая, что третьи стороны сделали такой глубокий толчок для jsp, хорошо развернут только jsp;
Роль JSP
Конечно, JSP обязательно найдет свое место в будущем. Сходство JSP и ASP видно даже из названий, они отличаются всего одной буквой. Поэтому, если люди, использующие ASP, перейдут на Java, очень похожая среда JSP будет играть большую роль в продвижении этого. Роль поддержания соответствующих отношений с ASP также должна быть ключевым фактором для дизайнеров, запускающих JSP Arrived.
Однако здесь дело в том, что существует большая разница между тем, что приносит работникам переезд в новую среду, и тем, является ли это на самом деле лучшим способом использования этой среды.
JSP все больше показывает, что он становится одной из важнейших технологий Java и позволяет людям покинуть мир ASP — таким образом, Sun будет поддерживать это сильное экономическое обоснование, а сторонники технологий, связанных с Java, также окажут большую поддержку.
Однако это не лучшее решение для платформы Java. В результате решение Java будет выглядеть как решение без Java.