Технология JSP -- друг или враг?

Brett McLaughlin
Enhydra Strategist, Lutris Technologies
October 2000

Автор - опытный разработчик java и приверженец технологии Enhydra, убеждает разработчиков рассматривать альтернативы JavaServer Pages (JSP) servlets при выборе средства разработки веб приложений. Технология JSP это часть платформы J2EE компании Sun призвана решить проблему визуального отображения данных. Реально, JSP не совсем отвечает всем чаяниям разработчиков. На данный момент существует несколько различных подходов к решению проблемы презентации данных и вы можете выбирать. Эта статья проводит анализ программирования на JSP и рассматривает возможные альтернативы.

Технологии презентации данных призваны трансформировать простые данные в привлекательный для использования вид. Технология JavaServer Pages (JSP) компании Sun является частью платформы J2EE и ей сейчас уделяется огромное внимание. Эта технология имеет свои достоинства и недостатки, поэтому разработчикам очень важно их знать и осознавать, что они не ограничены только этой одной технологией. На данный момент доступно множество презентационных технологий. В этой статье в начале рассматриваются проблемы, которые призваны решить презентационные технологии, а затем исследуются сильные и слабые стороны технологии JSP. И в конце приводятся некоторые альтернативы этой технологии.

Немного истории
Перед тем как углубляться в рассказ о презентационных технологиях стоит рассмотреть причины, по которым эти технологии стали необходимы. Всего лишь 10 лет назад термин тонкий клиент был новшеством. Мы жили в мире десктоп приложений, 286 процессоров и 14-ти дюймовых мониторов. И вот, ситуация изменилась. Теперь мой десктоп нечего не делает кроме работы с веб браузером, в то время как серверы Sun, IBM, HP, Compaq и т.д. занимаются вычислениями и бизнес логикой. А этот монитор? Заменен на плоский 21 или 25-ти дюймовый экран. Зачем? Чтобы мы могли видеть и полностью использовать все возможности HTML, который служит интерфейсом к этим мощным приложениям. Никого не удовлетворяет простой интерфейс, теперь мы привыкли к роскошной графике, удобному управлению и т.д.

Предпосылка
Но и сегодня, десятилетие спустя этих приложений Windows, мы все еще сталкиваемся с огромными изменениями в презентационном подходе. Те кто раньше программировал на Visual Basic и C теперь пытаются найти себя работая с back-end systems или приложениями только для Windows, или они начинают работать с языками поддерживающими веб технологии, такими как Java. В наше время приложение которое не поддерживает по крайней мере две из трех новых технологий, таких как HTML, XML, и WML - считается ущербным. И конечно это означает, что мы должны обращать большое внимание разработке веб презентационного уровня.

Но, использования Internet технологий и всех тех языков программирования которые мы имеем, таких как Java, C, Perl, Pascal, Ada и т.д. не облегчает нашу задачу. Масса различных проблем возникает, когда возникает необходимость сгенерировать необходимый язык разметки для клиента. С увеличением возможностей браузеров (например DHTML и Javascript), увеличением количества и качества используемой графики и средств, позволяющих создавать интерфейс пользователя используя стандартный HTML требования к таким интерфейсам возрастают быстрее чем наша способность их разрабатывать. И это заставляет нас обратить внимание на презентационные технологии

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

Сегрегация и интеграция
Первоначальная задача презентационных технологий это возможность разделения контента и его представления. В других словах, бизнес логика (написанная на некотором языке программирования, таком как C или Java) не должна генерировать данные для определенного представления. Данные, или контент, возвращаются без какого-то презентационного форматирования. А вот уже презентационная технология затем производит необходимое форматирование или презентацию. Результат - это смесь данных, графики, различного форматирования, цветов и т.д.

Посмотрите на примеры в листинге 1 и листинге 2 чтобы понять разницу между просто данными и контента созданного презентационной технологией.

Листинг 1 показывает только данные, которые могут использоваться различными путями.

Листинг 1. Просто данные

Russell Crowe
Tom Hanks
Meg Ryan
Mary Stuart Masterson
Alec Baldwin
Ashley Judd
Keanu Reeves

Листинг 2, показывает эти же данные, но обработанные презентационной технологией и готовые к просмотру в HTML браузере.

Листинг 2. Представление данных

<HTML>
<HEAD>
 <TITLE>Search Results: Actors</TITLE>
</HEAD>
<BODY>
 <H2 ALIGN="center">Search Results: Actors</H2>
 <CENTER>
  <HR WIDTH="85%">   
  <TABLE WIDTH="50%" CELLPADDING="3" CELLSPACING="3" BORDER="1"
         BGCOLOR="#FFFFCC">
    <TR BGCOLOR="#FFCCCC">
      <TH WIDTH="50%" ALIGN="center">Last Name</TH>
      <TH WIDTH="50%" ALIGN="center">First Name</TH>
    </TR>
    <TR>
      <TD WIDTH="50%">Baldwin</TD>
      <TD WIDTH="50%">Alec</TD>
    </TR>
    <TR>
      <TD WIDTH="50%">Crowe</TD>
      <TD WIDTH="50%">Russell</TD>
    </TR>
    <TR>
      <TD WIDTH="50%">Hanks</TD>
      <TD WIDTH="50%">Tom</TD>
    </TR>
    <TR>
      <TD WIDTH="50%">Judd</TD>
      <TD WIDTH="50%">Ashley</TD>
    </TR>
    <TR>
      <TD WIDTH="50%">Masterson</TD>
      <TD WIDTH="50%">Mary Stuart</TD>
    </TR>
    <TR>
      <TD WIDTH="50%">Reeves</TD>
      <TD WIDTH="50%">Keanu</TD>
    </TR>
    <TR>
      <TD WIDTH="50%">Ryan</TD>
      <TD WIDTH="50%">Meg</TD>
    </TR>
  </TABLE>
 </CENTER>
</BODY>
</HTML>

В то время как, данные в Листинге 1 просты и понятны для любого, контент в Листинге 2 очень специфичен и предназначен пря просмотра в браузере. Трудно отделить только данные и использовать их в других целях.

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

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

В простейщем случае, художник предоставляет графическую раскладку, а разработчик свой код и вводит эту раскладку в презентационную технологию. Приложение стартует, и контент, словно по мановенью волшебной палочки, превращается в пользовательский интерфейс. Конечно, как нам всем известно, разработка на этом не кончается, возникает необходимость в следующих версиях кода, изменения пользовательского интерфейса, изменения бизнес процессов и т.д. Именно здесь мы можем проверить надежность этой презентационной технологии. Довольно просто можно изменить контент, но достаточно сложно изменить работу художника. А изменения в презентационном уровне достаточно часты (все мы жертвы отделов маркетинга, которые заставляют нас менять то одно, то другое). Итак, возникает проблема: что дизайнеры должны изменить, чтобы сделать свою работу? Тот графический расклад, что они отдали разработчику? Наверное нет, так как эта страница наверняка уже имеет custom tags или встроенный код (JSP страницы, template engines), преобразованные в Java сервлеты или вообще в нечто неузнаваемое.

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

Обещания технологии JSP
Теперь обратимся к JSP. Основная задача технологии JSP обеспечить дизайнера и разработчика такой презентационной технологией, которая удовлетворит все их нужды. Технология JSP это часть платформы J2EE, которая имеет сильнейшую поддержку со стороны компании Sun среди всех остальных java технологий. Чтобы убедиться в этом, попробуйте поискать слово 'JSP' на amason.com, вы найдете большее количество книг посвященных этой технологии, чем любой другой java технологии. Перед тем как углубиться в специфические проблемы JSP вы должны ясно понимать, что JSP должно обеспечивать.

Данные и представление
Среди другого, утверждается, что JSP разделяет данные и их представление, по крайней мере это видно из тех задач, что опубликованы как цели JSP. Разработчик JSP освобожден от необходимости прямо писать подобный код out.println("<HTML><HEAD><TITLE>" + pageInfo.getTitle() + "</TITLE></HEAD>"); в своих сервлетах. Эта смесь из жестко заданного контента с изменяющимися переменными накладывает ужасное бремя на разработчика сервлетов. И это затрудняет разработчика делать даже минимальные изменения.

Технология JSP решает эту проблему путем возможности конвертации обычных HTML страниц (а затем и WML или других языков разметки) в java сервлет, избавляя от необходимости иметь дело out.println(). И это позволяет вам вставлять необходимые переменные в страницу, которые будут работать при запросе.

В JSP странице отрывок кода HTML, показанный на Листинге 2 может выглядеть как показано на Листинге 3.

Листинг 3. JSP страница состаящая из данных и презентационной технологии

<%@ page import="com.ibm.display.PageUtils" %>
<%@ page import="com.ibm.display.PageInfo" %>

<%
PageInfo pageInfo = (PageInfo)session.getAttribute("PAGE_DATA")
%>

<HTML>
<HEAD>
 <TITLE>
  <%=pageInfo.getTitle()%>
 </TITLE>
</HEAD>
<BODY>

<!-- Other HTML content -->

</BODY>
</HTML>

Судя по этому, JSP (по крайней мере в его начальном дизайне) удовлетворяет главному принципу презентационных технологий: что данные должны быть отделены от презентации.

Код и раскладка
Второе, что находится в списке особенностей JSP может вызвать некоторое беспокойство. JSP позволяет вам вставлять Java код прямо в страницу. Чтобы понять почему это сделано, вспомним, что когда разрабатывалась спецификация JSP, противостояние компаний Sun и Microsoft было очень огромно, отчасти и от того, что технология Active Server Pages (ASP) компании Microsoft была успешна на рынке. Схожесть имен JavaServer Pages и Active Server Pages - неслучайна. И была необходимость хотя бы повторить возможности ASP, поэтому авторы JSP сделали возможным добавление Java кода в код разметки.

Как пример кода Java добавленного к разметке, можно привести часть JSP в Листинге 4, которая динамически добавляет строки из Vectora актеров.

Листинг 4. Код Java вставленный в язык разметки страницы.

<%@ page import="com.ibm.display.PageUtils" %>
<%@ page import="com.ibm.display.PageInfo" %>
<%@ page import="com.ibm.people.Actor" %>
<%@ page import="java.util.Iterator" %>
<%@ page import="java.util.Vector" %>
<%
PageInfo pageInfo = (PageInfo)session.getAttribute("PAGE_DATA")
Vector actors = pageInfo.getActors()
%>

<HTML>
<HEAD>
 <TITLE>
  <%=pageInfo.getTitle()%>
 </TITLE>
</HEAD>
<BODY>

<H2 ALIGN="center">Search Results: Actors</H2>
 <CENTER>
  <HR WIDTH="85%">   
  <TABLE WIDTH="50%" CELLPADDING="3" CELLSPACING="3" BORDER="1"
         BGCOLOR="#FFFFCC">

<%
 for (Iterator i = actors.iterator(); i.hasNext()) {
  Actor actor = (Actor)i.next();
%>
    <TR BGCOLOR="#FFCCCC">
      <TH WIDTH="50%" ALIGN="center">
       <%=actor.getLastName()%>
      </TH>
      <TH WIDTH="50%" ALIGN="center">
       <%=actor.getFirstName()%>
      </TH>
    </TR>
<%
 }
%>
  </TABLE>
 </CENTER>

</BODY>
</HTML>

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

Дизайнер и разработчик
Конечная (и замечательная) цель технологии JSP, на которую стоит обратить внимание это попытка четко разграничить роли в процессе разработки приложения. Якобы отделяя данные от представления, JSP четко разграничивает дизайнера и разработчика. Дизайнер создает разметку, используя только стандартные HTML, WML или другой подходящий язык, а разработчик пишет код. Конечно, многие дизайнеры сегодня изучают Javascript, поэтому нет ничего удивительного в том, что многие из этих дизайнеров начинают изучать JSP. Часто вместо работы только над разметкой, они полностью разрабатывают JSP страницу и отдают ее разработчику. Затем уже разработчик помещает эту страницу как часть веб приложения. Проблема здесь в том, что многие дизайнеры не изучают программирование JSP, а они должны иметь возможность работать в такой обстановке.

Проблемы
Я объяснил какие задачи должна решать хорошая презентационная технология и какие проблемы похоже существуют в JSP. Теперь я готов продолжить, несмотря на то, что технология JSP построена на хороших идеях, она представляет некоторые проблемы. Перед тем, как вы будете ее использовать в своих приложениях, вы хотя бы должны хорошо представлять себе некоторые особенности.

Вы должны понимать, что несмотря на то, что API поставляется в составе J2EE платформы, никто не заставляет вас его использовать. Звучит глупо, но некоторые разработчики пытаются использовать JSP или EJB или JMS API, только потому, что считают, что их приложение не будет настоящим "J2EE applications" если их не использовать. Дело в том, что платформа поставляется с большим количеством API, чем реально необходимо определенному приложению. Если вы имеете проблемы с технологией JSP, вы не обязаны ее использовать! Посмотрите на все достоинства и недостатки перед тем, как решить использовать JSP в своем приложении. Давайте посмотрим на некоторые из этих недостатков.

Переносимость и использование одного языка
Технология JSP рассчитана на использование определенного языка. Это не должно вас сильно беспокоить. Язык Java для enterprise приложений (по крайней мере по моему мнению) это единственный правильный выбор. В любом случае сейчас нет языконезависимых решений. Конечно на данном этапе я не учитываю платформу Microsoft .NET, только время покажет сможет ли эта платформа стать действительно языконезависимой (я более чем сомневаюсь в этом).

Однако, использование JSP ограничивает вас использованием только языка Java, по крайней мере для презентации и контента. Тогда как, CORBA может быть использована для бизнес логики, использование JSP требует знакомство с сервлетами и основами языка Java. Так как большинство разработчиков приходят в разработку JSP с помошью J2EE, это не является большой проблемой.

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

Размывание линии между контентом и презентацией
JSP позволяет вставлять Java код в язык разметки страниц, и это очень опасная возможность позволяющая данным смешиваться с презентацией. Более того, бизнес логика часто работает именно в JSP страницах, как показано на Листинге 5.

Листинг 5. JSP страница, содержащая бизнес логику.

<%@ page import="com.ibm.display.PageUtils" %>
<%@ page import="com.ibm.display.PageInfo" %>
<%@ page import="com.ibm.logic.AdminUtils" %>
<%@ page import="com.ibm.people.Actor" %>
<%@ page import="java.util.Iterator" %>
<%@ page import="java.util.Vector" %>

<%
PageInfo pageInfo = (PageInfo)session.getAttribute("PAGE_DATA")
%>

<HTML>
<HEAD>
 <TITLE>
  <%=pageInfo.getTitle()%>
 </TITLE>
</HEAD>
<BODY>
 <H2 ALIGN="center">Search Results: Actors</H2>
 <CENTER>
  <HR WIDTH="85%">   
  <TABLE WIDTH="50%" CELLPADDING="3" CELLSPACING="3" BORDER="1"
         BGCOLOR="#FFFFCC">

<%

// Based on user's permissions,
   //perform search differently (business logic!)
 Vector actors = pageInfo.getActors()
 if (pageInfo.getUserInfo().hasPermission("ADMINISTRATOR")) {
   actors = AdminUtils.getActors(pageInfo.getSearchCriteria());
 } else {
   actors = pageInfo.getActors();
 }

 for (Iterator i = actors.iterator(); i.hasNext()) {
  Actor actor = (Actor)i.next();
%>
    <TR BGCOLOR="#FFCCCC">
      <TH WIDTH="50%" ALIGN="center">
       <%=actor.getLastName()%>
      </TH>
      <TH WIDTH="50%" ALIGN="center">
       <%=actor.getFirstName()%>
      </TH>
    </TR>
<%
 }
%>
  </TABLE>
 </CENTER>
</BODY>
</HTML>

Приверженцы JSP быстро ответят на это, что JSP tag libraries могут решить эту проблему. Tag libraries позволяют добавлять custom tags (например, <AUTHORS />) в JSP страницу, которые во время работы преобразуются в необходимый код.

Использование custom tag и соответствующей tag library позволяет нашему примеру конвертироваться в код приведенный в Листинге 6.

Листинг 6. Custom tag и tag library встроенные в страницу.

<CENTER>
  <TABLE WIDTH="50%" CELLPADDING="3" CELLSPACING="3" BORDER="1"
         BGCOLOR="#FFFFCC">

 <ACTORS />

  </TABLE>
 </CENTER>

Во время выполнения, код соответствующий этому тагу будет выполнен и корректные результаты будут вставлены в страницу. Но это не решает всей проблемы. Аргумент против технологии JSP не в том, что данные и презентация могут быть разделены, а в том, что они должны быть разделены. До тех пор пока JSP позволяют вставлять код, очень удобно (особенно когда совсем не хватает времени на разработку) делать последние изменения в самом коде JSP, чем транcформировать этот код в tag library. Если это вас не задевает, подумайте почему язык Java стал таким популярным, несмотря на C и С++: в Java запрещены многие возможности, которые вызывали наибольшие проблемы в С, такие как сложение указателей. Вы конечно скажете, что вы не использовали сложение указателей в C или, что ни один хороший программист никогда не будет вставлять код в JSP, но мы ведь реально знаем, как все происходит на практике. Язык Java лучший потому, что он гарантирует, что такие проблемы никогда не возникнут. Но JSP с этой точки зрения похожа на С, который позволяет вести некачественную разработку.

Дополнительный тест технологии JSP в достижении ее целей, это посмотреть действительно ли возможно достижение этих целей на практике; хотя несправедливо утверждать, что в JSP это совершенно недостижимо. Большинство template engine, таких как FreeMarker и WebMacro, имеют сходную возможность, обычно с аналогичным Perl языку. Но такие технологии как Enhydra XMLC не позволяют такого. Вместо этого, эти технологии получают на вход только язык разметки страниц и генерируют необходимые Java методы. Это полностью меняет программу: вместо того, чтобы страница (технология JSP) вызывала методы бизнес логики приложения, само приложение (Enhydra) использует методы, чтобы влиять на отображение страницы. В случае с Enhydra, XMLC конвертирует страницу в DOM дерево и использует свойства DOM HTML для изменения значений "полей". (Для более подробной информации о Enhydra XMLC, смотрите Ресурсы.)

Дело в том, что технология JSP может соответствовать необходимым требованиям, более даже чем XMLC, но только при условии использования tag libraries. Но основная тенденция спецификации Sun такова, чтобы обеспечить обратную совместимость или по крайней мере поддерживать ее в течении длительного времени. Текущая версия спецификации JSP 1.1 позволяет встраивать код, поэтому стоит ожидать использование этой возможности течении определенного времени. Перед тем, как заняться программированием JSP обратите внимание на ту большую разницу, между идеалом, полным отделением данных от презентации, и тем, как это обеспечить. Это будет наилучшим разделением между вашим пользовательским интерфейсом и тем кодом, который исполняется в вашем приложении.

Однозадачность и многозадачность
В идеале, как мы обсуждали ранее, дизайнер должен иметь возможность работать с одной задачей, разрабатывая графический дизайн, а разработчик должен сфокусироваться на коде. Но дизайнер должен иметь возможность работать со страницей и после того как она конвертирована в пригодный для использования в приложении формат. В случае с JSP, это будет добавление JavaBeans, вставки кода и добавления custom tag libraries в старницу. Проблема в том, что некоторые дизайнеры работают с редакторами HTML, такими как HoTMetaL, Macromedia Dreamweaver или FrontPage, которые не понимают встроенного кода или tag library, а это значит, что дизайнер сможет продуктивно работать только с частью страницы. Представьте себе трудности когда tag library или встроенный код генерируют данные в таблице или другие детали форматирования в странице. Дизайнер используя несовместимые HTML редакторы не сможет увидеть как выглядят все элементы вместе взятые. Когда дизайнер не может пересмотреть страницу после внесения кода разработчиком, вместо того чтобы разделить роли в разработке, JSP может вынудить их совместить обязанности: разработчик должен работать с несколькими задачами, быть разработчиком, дизайнером и т.д.

Вы не убеждены что это важно? Тогда попробуйте скачать J2EE Reference Implementation и загрузите одну из включенных туда JSP в WYSIWYG HTML редактор, такой как Dreamweaver. Страница заполняется массой желтых отметок, сигнализирующих о "неправильном" теге в разметке страницы. Хотя конечно, желтый цвет в JSP тагах и коде гораздо лучше, чем действительная ошибка в странице.

На сегодняшний день не существует WYSIWYG редакторов поддерживающих JSP и я не слышал о попытках создания каковых. В то время как template engine имеют такие же проблемы, многие продукты основанные на Java, такие как моя любимая Enhydra позволяют вам предоставлять разметку страницы на вход презентационной технологии. В этом случае дизайнер может делать изменения так часто как ему хочется и передавать разметку странице на вход презентационной технологии, которая конвертирует ее в необходимый формат, при этом не нужно будет делать никаких изменений в коде (обычно). Результат на лицо, дизайнер займется дизайном, а разработчик разработкой.

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

HTML и XML
Один из наиболее больших недостатков JSP, на который обычно мало обращают внимание это несовместимость с XML. Вернее, учитывая господство HTML JSP страницы не обязаны быть XHTML совместимыми. XTML это стандарт World Wide Web Consortium (W3C), который призван заменить HTML 4.0., XHTML определяет таги HTML как правильно сформированный XML документ. Например, таг <br> должен быть сконвертирован в <br/> для этого. (Вы можете посмотреть XML спецификацию и статью на developerWorks о XHTML, смотрите раздел Ресурсы) Схожие правила прилагаются и к тагу image, и в XHTML 1.1 большинство фонтов и другой стилевой информации размещено в CSS стилях. Таким образом, большинство стандартных HTML документов может быть легко преобразовано в XHTML 1.0, а эт значит, что они могут быть прочитаны любым XML совместимым парсером, таким как Apache Xerces, и этими данными можно легко манипулировать.

"И что толку?" вы спросите. Толк в том, что XML становится глобальным стандартом для коммуникации интер и интра приложений. Работа с данными в формате XML позволяет любому другому приложению, которое имеет средства работы с XML, эффективно использовать данные вашего приложения. Представьте себе возможность взаимодействовать с процессингом кретитных карточек для работы e-commerce просто путем конвертации ваших данных в формат XML! Очень часто, вам необходимо обмениваться данными с другими компаниями. Распространенный случай это портал, который получает данные из многих источников (например погоду, котировки акций, новости). Между тем, JSP страницы с их смешанным кодом и custom tag libraries не могут успешно функционировать в этой обстановке.

Редко JSP страницы это well-formed XML документ, даже не смотря на соответствие XHTML, языку разметки который не поддерживает различные JSP custom tag. Но еще более важно, то, что встроенный java код не является разметкой и он будет вызывать ошибки при попытки разбора другим приложением.

Давайте посмотрим на еще одну сторону JSP. Так как клиент должен получать данные от приложения, они должны быть стандартным HTML (или WML, VoXML и т.д.) Но многие приложения, которые получают эти данные используют определенные формы кеширования, так как сетевые запросы достаточно дороги. В этом случае скешированная страница возвращает не совсем свежие данные. Хотя вероятно вы бы предпочли получать данные в XML, особенно статические. И в этом случае JSP не может помочь; JSP страница должна быть выполнена, для избавления от встроенного кода и tag libraries.

Давайте проверим: может ли какая-либо другая презентационная технология сделать это? Ответ - да. Признанный лидер в этой области это проект Apache Cocoon, который основывается на XML и применении XSLT стилей (которые могут быть применены и динамически и статически). Потому что XML Server Pages (называемые XSP в проекте Cocoon) являются XML документами, они всегда XML совместимы. Другие технологии, такие как Tea и Enhydra XMLC, которые позволяют получать на вход язык разметки страниц тоже позволяют это, хотя и не требуют. В их случае пользователь может использовать XTHML или HTML. Но это лучше чем JSP, где well-formed XML не может быть выполнен статически.

Заключение
Я надеюсь, что немного приоткрыл вам глаза на достоинства и недостатки технологии JSP и что теперь вы будете смотреть на JSP, как на одну из альтернатив среди многих других презентационных технологий. Также, вы возможно будете немного более скептичны относительно всей модели программирования J2EE. Если вы и в дальнейшем планируете использовать эту платформу, стоит посмотреть на альтернативы JSP, такие как Apache Cocoon, Enhydra или различные templating engines.

Наконец, имейте в виду, что несмотря на все доводы, эта статья не рекомендует вам использовать JSP или нет. Я пытаюсь подтолкнуть вас исследовать все технологии, чтобы быть уверенным, что они как раз, то, что вам необходимо. Подходы в программировании как примеры: иногда они полезны, иногда не несут ничего стоящего. Оглянитесь вокруг, найдите то, что наиболее подходит для вас и сделайте правильный выбор, вместо необдуманного.

До встречи на просторах Web!

Ресурсы

• Текущая спецификация JSP.
• Загляните в будущее и посмотрите, что вас там ожидает - JSP 1.2.
• Беспокоитесь о совместимости с XML? Вы можете найти всю необходимую информацию о XML в спецификации и в статье Molly Holzschlag для developerWorks
• Познакомьтесь с представлением о стилях в XML на W3C Style Center.
• Хотите работать с J2EE и получать больше чем от JSP, при этом чтобы этот продукт был open source? Прочитайте про Enhydra.
• Вырвитесь из cвоего окружения и посмотрите на Apache Cocoon, open source альтернативу для работы с динамическим контекстом используя XSLT.
• Если вы не желаете расстоваться с java, вам могут помочь template engines! Два наиболее популярные это WebMacro и FreeMarker.

О авторе
Brett McLaughlin работает как Enhydra strategist в Lutris Technologies и специализируется в разработке распределенных систем. Он автор книги Java and XML (O'Reilly). Он работает с такими технологиями, как Java servlets, Enterprise JavaBeans technology, XML и приложениями business-to-business. Вместе с Jason Hunter он основал проект JDOM, который обеспечивает доступное API для работы с XML из Java приложений. Также он активный разработчик в проектах Apache Cocoon project, EJBoss EJB сервер и соучередитель проекта Apache Turbine. Вы можете написать Brett по адресу: brett@newInstance.com

Оригинал этой статьи доступен по следующему адресу:
http://www-106.ibm.com/developerworks/library/w-friend.html?dwzone=java

Заключение редактора.

В заключение мне хотелось бы пояснить, зачем я перевел эту статью и поместил ее в эту колонку, ведь эта статья практически советует отказаться от использования JSP?

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

Brett McLaughlin очень известный и опытный разработчик Java, именно поэтому его мнение было мне более интересным, чем просто обычные "религиозные войны" сторонников различных технологий. Особенно учитывая то, что он совершенно доступно и логично описал проблемы технологии JSP и более того, описал пути их решения (например использование custom tag и совместимость с XTHML). Именно это и было интересно мне, как JSP разработчику. Как можно правильно пользоваться этой технологией, чтобы избежать трудностей в дальнейшем.

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

Как говорится - "Осведомлен значит вооружен", поэтому я надеюсь что эта статья осведомит вас о существующих проблемах в JSP и вы уже будете во всеоружии.

Искренне ваш,
Вячеслав Педак