Продолжаю описывать процесс создания веб-приложения используя сервлеты, jsp, мавен и томкат. , если необходимо.

Создаем сущности.

Создадим в пакете entities класс User, в котором создадим две приватные строковые переменные name и password. Создадим конструкторы (по умолчанию и такой, который бы принимал оба значения), геттеры/сеттеры, переопределим метод toString() на всякий случай, а так же методы equals() и hashCode(). public class User { private String name; private String password; public User() { } public User(String name, String password) { this.name = name; this.password = password; } public String getName() { return name; } public void setName(String name) { this.name = name; } public String getPassword() { return password; } public void setPassword(String password) { this.password = password; } @Override public String toString() { return "User{" + "name="" + name + "\"" + ", password="" + password + "\"" + "}"; } @Override public boolean equals(Object o) { if (this == o) return true; if (o == null || getClass() != o.getClass()) return false; User user = (User) o; if (name != null ? !name.equals(user.name) : user.name != null) return false; return password != null ? password.equals(user.password) : user.password == null; } @Override public int hashCode() { int result = name != null ? name.hashCode() : 0; result = 31 * result + (password != null ? password.hashCode() : 0); return result; } } Теперь можем приступить к созданию списка пользователей, куда мы будем наших пользователей добавлять, и откуда будем их забирать для отображения. Но есть проблема. Объекты наших сервлетов мы не создаем, их создает за нас томкат. Методы, которые мы переопределяем в них - тоже за нас уже определены и добавить параметр мы не можем. Как же тогда создать общий список, который бы виден был в обоих наших сервлетах? Если мы просто в каждом сервлете создадим свой объект списка - то получится, что добавлять пользователей мы будем в один список, а выводить список пользователей сервлетом ListServlet - совершенно другой. Получается, что нам нужен такой объект, который был бы общим для обоих сервлетов. Если говорить обобщенно, то нам нужен такой объект, который был бы общим для всех классов в нашей программе; единственный объект на всю программу. Надеюсь, вы что-то да слышали про шаблоны проектирования. И возможно для кого-то это первая реальная необходимость использования шаблона в своей программе. Можете поизвращаться и запилить какой-нибудь крутой синглтон, с двойными проверками и синхронизациями (да-да, у нас многопоточное приложение, так как сервлеты томкат запускает в разных потоках), но я буду использовать вариант с ранней инициализацией, так как в данном случае он вполне подходит.

Создание модели.

Создадим тогда класс (и реализуем в нем шаблон singleton) в пакете model, ну и назовем тоже вполне красочно Model. Создадим в нем приватный объект списка пользователей, и сделаем два метода: один для того, чтоб можно было добавить пользователя, а второй - пусть просто возвращает список строк (имен пользователей). Поскольку наш объект пользователя состоит из имени и пароля - то пароли пользователей мы "светить" не хотели бы, поэтому и возвращать будем только список их имен. public class Model { private static Model instance = new Model(); private List model; public static Model getInstance() { return instance; } private Model() { model = new ArrayList<>(); } public void add(User user) { model.add(user); } public List list() { return model.stream() .map(User::getName) .collect(Collectors.toList()); } }

Немного про mvc.

Раз уж вы слышали про singleton, значит возможно слышали и про другой шаблон проектирования - MVC (model-view-controller, или по-русски модель-представление-контроллер, или прям так как и на английском модель-вью-контроллер). Его суть в том, чтобы отделять бизнес-логику от представления. То-есть, отделять код, который определяет что делать от кода, который определяет как отображать . View (представление или просто вьюхи) как-раз и отвечает за то, в каком виде представлять какие-то данные. В нашем случае вьюхи - это наши jsp странички. Именно поэтому я их и положил в папочку с названием views. Модель - это собственно сами данные, с которыми работает программа. В нашем случае это пользователи (список пользователей). Ну а контроллеры - связующее звено между ними. Берут данные из модели и передают их во вьюхи, ну или получают от томката какие-то данные, обрабатывают их и передают модели. Бизнес-логика (то-есть что делать ) должна быть описана в них, а не в модели или во вьюхе. Таким образом, каждый занимается своим делом:

• модель хранит данные
• вьюхи рисуют красивое представление данных
• контроллеры занимаются обработкой данных

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

Создаем форму добавления пользователя.

Добавим в файл add.jsp форму, состоящую из двух текстовых инпутов (один обычный, другой типа пароль) и кнопки для отправки данных на сервер. Name: Password: Submit Здесь у формы указан атрибут method со значением post. Это говорит о том, что данные из этой формы полетят на сервер в виде POST-запроса. Атрибут action не указан, значит запрос этот полетит по тому же адресу, по которому мы перешли на эту страничку (/add). Таким образом наш сервлет, который привязан к этому адресу, при получении GET-запроса возвращает эту jsp с формой добавления пользователей, а если получит POST-запрос - значит эта форма отправила туда свои данные (которые мы в методе doPost() вытащим из объекта запроса, обработаем и передадим в модель на сохранение). Стоит обратить внимание, что у инпутов здесь указан параметр name (для поля с именем он имеет значение name, а для поля с паролем - pass). Это довольно важный момент. Так как чтобы получить из запроса (внутри сервлета уже) эти данные (имя и пароль которые будут введены) - мы будем использовать именно эти name и pass. Но об этом чуть позже. Сама кнопка отправки данных у меня сделана снова же в виде button, а не инпутом, как это обычно принято. Не знаю насколько такой вариант универсален, но у меня в хроме работает:)

Обработка POST-запроса сервлетом.

Вернемся к сервлету AddServlet. Мы уже знаем, что чтобы наш сервлет умел "ловить" GET-запросы - мы переопределили метод doGet() из класса HttpServlet. Чтобы научить наш сервлет ловить еще и POST-звапросы - мы переопределяем еще и метод doPost(). Он получает аналогичные объекты запроса и ответа от томката, с которыми мы и будем работать. Для начала вытащим из запроса параметры name и pass, которые отправила форма (если вы их в форме назвали по-другому - тогда именно те названия и пишете). После чего создадим объект нашего пользователя, используя полученные данные. Потом получим объект модели и добавим созданного пользователя в модель. @Override protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { String name = req.getParameter("name"); String password = req.getParameter("pass"); User user = new User(name, password); Model model = Model.getInstance(); model.add(user); }

Передача данных во вьюху.

Теперь перейдем к сервлету ListServlet. У нас тут уже реализован метод doGet(), который просто передает управление во вьюху list.jsp. Если у вас этого еще нет - сделайте по аналогии с таким же методом из сервлета AddServlet. Теперь было бы неплохо получить из модели список имен пользователей и передать их во вьюху, которая их там получит и красивенько отобразит. Для этого воспользуемся снова же объектом запроса, который мы получили от томката. К этому объекту мы можем добавить атрибут, дав ему какое-то имя ну и собственно сам объект, который бы мы хотели передать во вьюху. Благодаря тому, что при передаче процесса выполнения из сервлета во вьюху мы передаем туда эти же объекты запроса и ответа, что получил сам сервлет, то и добавив наш список имен к объекту запроса мы потом из этого объекта запроса во вьюхе сможем наш список имен пользователей и получить. С классом ListServlet мы закончили, поэтому привожу код всего класса package app.servlets; import app.model.Model; import javax.servlet.RequestDispatcher; import javax.servlet.ServletException; import javax.servlet.http.HttpServlet; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; import java.io.IOException; import java.util.List; public class ListServlet extends HttpServlet { @Override protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { Model model = Model.getInstance(); List names = model.list(); req.setAttribute("userNames", names); RequestDispatcher requestDispatcher = req.getRequestDispatcher("views/list.jsp"); requestDispatcher.forward(req, resp); } }

Выполнение java-кода в jsp файлах.

Теперь перейдем к файлу list.jsp. Этот файл выполнится только когда ListServlet передаст сюда процесс выполнения. Кроме того, мы в том сервлете уже подготовили список имен пользователей из модели и передали сюда в объекте запроса. Имея список имен мы можем пробежаться по нему циклом for и вывести каждое имя. Как я уже говорил, jsp файлы могут выполнять java-кода (в принципе, этим и отличаются от статичных html страничек). Для того, чтобы выполнить какой-то код - достаточно поставить в нужном нам месте конструкцию <% // java код %> Внутри такой конструкции мы получаем доступ к нескольким переменным: request - наш объект запроса, который мы передали из сервлета, где он назывался просто req responce - объект ответа, в сервлете назывался resp out - объект типа JspWriter (наследуется от обычного Writer), при помощи которого можем "писать" что-либо прямо в саму html страничку. Запись out.println("Hello world!") очень похожа на запись System.out.println("Hello world!"), но не стоит их путать! out.println() "пишет" в html страничку, а System.out.println - в системный вывод. Если вызвать внутри раздела с джава кодом jsp метод System.out.println() - то результаты увидите в консоли томката, а не на страничке, как возможно хотелось бы:) Про другие доступные объекты внутри jsp можно поискать . Используя объект request мы можем получить список имен, который передавали из сервлета (мы прикрепили соответствующий атрибут к этому объекту), а используя объект out - можем вывести эти имена. Сделаем это пока просто в виде html списка: <% List names = (List) request.getAttribute("userNames"); if (names != null && !names.isEmpty()) { for (String s: names) { out.println("" + s + ""); } } %> Если же хотим выводить список только в том случае, когда есть пользователи, а иначе выводить предупреждение, что пользователей пока нет - можем немного переписать этот участок: <% List names = (List) request.getAttribute("userNames"); if (names != null && !names.isEmpty()) { out.println(""); for (String s: names) { out.println("" + s + ""); } out.println(""); } else out.println("There are no users yet!"); %> Теперь, когда мы умеем передавать данные из сервлетов во вьюхи - можем немного улучшить наш AddServlet, чтобы выводилось уведомление об успешном добавлении пользователя. Для этого в методе doPost() после того, как добавили нового пользователя в модель - можем добавить имя этого пользователя в атрибуты объекта req и передать управление обратно во вьюху add.jsp. А в ней уже сделать участок с джава кодом, где проверять есть ли такой атрибут в запросе, и если да - то выводить сообщение, что пользователь успешно добавлен. После этих изменений полный код сервлета AddServlet будет выглядеть примерно так: package app.servlets; import app.entities.User; import app.model.Model; import javax.servlet.RequestDispatcher; import javax.servlet.ServletException; import javax.servlet.http.HttpServlet; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; import java.io.IOException; public class AddServlet extends HttpServlet { @Override protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { RequestDispatcher requestDispatcher = req.getRequestDispatcher("views/add.jsp"); requestDispatcher.forward(req, resp); } @Override protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { String name = req.getParameter("name"); String password = req.getParameter("pass"); User user = new User(name, password); Model model = Model.getInstance(); model.add(user); req.setAttribute("userName", name); doGet(req, resp); } } Тут в конце метода doPost() мы устанавливаем атрибут с именем добавленного в модель пользователя, после чего вызываем метод doGet(), в который передаем текущие запрос и ответ. А метод doGet() уже передает управление во вьюху, куда и отправляет объект запроса с прикрепленным именем добавленного пользователя в качестве атрибута. Осталось подправить саму add.jsp чтобы она выводила такое уведомление, если присутствует такой атрибут. Конечный вариант add.jsp <%@ page contentType="text/html;charset=UTF-8" language="java" %> Add new user Super app! <% if (request.getAttribute("userName") != null) { out.println("User "" + request.getAttribute("userName") + "" added!"); } %> Add user Name: Password: Submit Back to main Тело страницы состоит из div-a с шапкой, после чего div-контейнер для контента, в нем проверка существует ли атрибут с именем пользователя, потом div с формой добавления пользователей, ну и в конце футер с кнопкой возврата на главную страницу. Может показаться, что слишком много div-ов, но мы их потом используем, когда добавим стилей:) Ну и конечный вариант list.jsp <%@ page import="java.util.List" %> <%@ page contentType="text/html;charset=UTF-8" language="java" %> Users Super app! Users <% List names = (List) request.getAttribute("userNames"); if (names != null && !names.isEmpty()) { out.println(""); for (String s: names) { out.println("" + s + ""); } out.println(""); } else out.println("There are no users yet!"); %> Back to main Таким образом, мы имеем полностью рабочее веб приложение, которое умеет хранить и добавлять пользователей, а так же выводить список их имен. Осталось лишь приукрасить... :)

Добавление стилей. Используем фреймворк W3.CSS.

В данный момент наше приложение рабочее, но абсолютно вырвиглазное:) Нужно добавить фон, цвета текста и кнопок, стилизировать списки, сделать выравнивание, добавить отступов, в общем много чего. Если писать стили вручную - это может занять много времени и нервов. Поэтому я предлагаю воспользоваться CSS фреймворком W3.CSS . В нем уже есть готовые классы со стилями, осталось только расставить в нужных местах те css классы, которые мы хотим в этих местах применить. Для того, чтобы добавить их к себе на страницы во-первых нам надо подключить файл со стилями. Это можно сделать двумя способами: 1. пройтись по нашим страницам и в разделе head вставить прямую ссылку на файл со стилями Такой вариант подходит, если у вас постоянное подключение к интернету. Тогда при открытии ваших страниц на локальном сервере - стили подтянутся из интернета. 2. Если же вы хотите иметь все стили у себя локально и не быть зависимым от интернет-соединения - можете просто скачать файл со стилями и поместить его где-нибудь внутри папочки web (например web/styles/w3.css), после чего пройтись по всем нашим страничкам (index.html, add.jsp, list.jsp) и вписать внутри раздела head ссылку на этот файл со стилями После этого просто пройтись по тегам и подописывать им те стили, которые вам понравятся. Я не буду останавливаться на этом подробно, а сразу дам свои готовые варианты трех моих файлов с раставленными классами стилей. index.html Super app! Super app! List users Add user add.jsp <%@ page contentType="text/html;charset=UTF-8" language="java" %> Add new user Super app! <% if (request.getAttribute("userName") != null) { out.println("\n" + " ×\n" + " User "" + request.getAttribute("userName") + "" added!\n" + ""); } %> Add user Name: Password: Submit Back to main list.jsp <%@ page import="java.util.List" %> <%@ page contentType="text/html;charset=UTF-8" language="java" %> Users list Super app! Users <% List names = (List) request.getAttribute("userNames"); if (names != null && !names.isEmpty()) { out.println(""); for (String s: names) { out.println("" + s + ""); } out.println(""); } else out.println("\n" + " ×\n" + " There are no users yet!\n" + ""); %> Back to main Вот и все:) Если у вас остались какие-то вопросы или есть какие-то замечания, или же наоборот что-то не получается - оставьте комментарий. Ну и парочку скриншотов приложу что из этого всего получилось.

И напоследок. Если будет желание попрактиковаться с этим проектом - можете попробовать:

• сделать сервлет и jsp для удаления пользователя и еще пару для изменения/редактирования существующего пользователя. Получится настоящее CrUD веб приложение:) на сервлетах))
• заменить список (List) на работу с базой данных, чтоб добавленные пользователи не пропадали после перезапуска сервера:)

Удачи! Example и JSTL Example . Отметим, что Tomcat – название программного сервера , варианта сервера apache , который автоматически конфигурируется и запускается при выполнении примеров, а example означает "пример". Большим достоинством среды NetBeans является то, что оригиналы всех примеров, открываемых в NetBeans, остаются в неприкосновенности – автоматически создаются копии примеров. Поэтому даже если вы внесете исправления в исходный код проекта с примером, это не повлечет изменений в новом проекте с таким же примером.

Для правильной работы серверных примеров требуется, чтобы на компьютере была установлена работа с Интернет . Реально выходить в Интернет не надо, идет соединение http://localhost:8084// . Но после запуска другого серверного приложения идет соединение по тому же адресу, поэтому документ берется из буфера – и показывается документ, созданный предыдущим приложением. Для показа правильного документа требуется нажать в браузере кнопку "обновить" , и в случае автономной работы в появившемся диалоге, предлагающем выбрать режим работы, выбрать "Подключиться" . Реального соединения с Интернет для адреса http://localhost:8084// не будет – все коммуникации станут проходить локально.

Первый из примеров иллюстрирует базовые конструкции JSP , его можно просмотреть, создав проект File/New Project…/ Samples/J2EE1.4/ Web /Tomcat JSP Example .

Второй пример – надстройка над JSP , специальный набор тегов JSP , разработанный группой экспертов для облегчения разработки серверных приложений . Пример можно просмотреть, создав проект File/New Project…/ Samples/J2EE1.4/Web / JSTL Example .

Порядок примеров в мастере создания приложений прямо противоположный рассматриваемому нами - сначала предлагается использовать JSTL как наиболее развитое средство, затем – JSP как средство более низкого уровня, и только затем Servlet – как средство еще более низкого уровня. Мы используем при рассмотрении обратный порядок, так как JSP использует сервлеты , а JSTL является надстройкой над JSP .

Рассмотрим подробнее первый пример.

Как и в предыдущем случае, при нажатии на гиперссылку "Execute" выполняется соответствующий пример – в данном случае запускается страница JSP . А при нажатии гиперссылки Source показывается HTML -страница с примерным видом исходного кода.

Страницы JSP представляют обычные HTML -документы, но имеющие расширение имени файла . jsp , а не. html или.htm . Это – заготовка HTML -документа, который будет показан пользователю-клиенту. При создании клиентского HTML -документа в этой заготовке выражения в фигурных скобках после знака доллара вычисляются, а в HTML -документ подставляется строковое представление результата.

Например, выражение вида ${1 + 2} выдаст в соответствующее место документа символ 3. Последовательность \$ означает, что выражение ${…} не вычисляется, а рассматривается как строка.

Имеется ряд встроенных в JSP тегов (объектов Java ):

• request – запрос. Тип объекта - класс, реализующий интерфейс javax. servlet .http.HttpServletRequest .
• response – ответ на запрос. Тип объекта - класс, реализующий интерфейс javax. servlet .http.HttpServletResponce .
• pageContext – контекст страницы JSP . Обеспечивает доступ к пространству имен и элементам страницы (тегам, атрибутам). Тип объекта - класс javax. servlet . jsp .PageContext .
• session – сессия (сеанс связи клиента с сервером). Тип объекта - класс, реализующий интерфейс javax. servlet .http.HttpSession
• application – приложение. Тип объекта - класс, реализующий интерфейс javax. servlet .ServletContext
• out – выходной поток. Тип объекта - класс javax. servlet . jsp .JspWriter
• config – объект конфигурации сервлета для текущей страницы. Тип объекта - класс, реализующий интерфейс javax. servlet .ServletConfig
• page – объект, обрабатывающий запрос для данной страницы. Тип объекта - класс Object .

Данные объекты применяются в виде

<%@ имяОбъекта параметр1=значение1 параметр2=значение2 ... %>

Пример их использования:

<%@ page session=true import="java.util.*" %>

Имеется возможность задания сценариев (интерпретируемого кода) с помощью специальных определений вида

<%@ код %>

Где код - сценарий Java для работы с документом или вычислений. Например,

<% for(int i=0; i

В частности, разрешается задавать собственные теги вида

<%@ имяБиблиотеки prefix="имяОбъекта" uri="путь к библиотеке" %>

После чего разрешается использовать теги вида < имяОбъекта:оператор>

Так делается в примере использования оператора out в JSTL Example . Используется пользовательский объект c (сокращение от customer - " покупатель "), задаваемый как prefix ="c", и оператор out , заданный в библиотеке taglib по адресу uri ="http://java.sun.com/jsp/jstl/core ":

<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>

Отметим, что соответствующие библиотеки уже добавлены в проект. Для примера out это пакет org. apache .taglibs.standard.tag.el.core .

После запуска данного приложения в появившемся документе в списке Examples это первый пример - General Purpose Tags. При переходе по данной гиперссылке мы получаем пример

Рис. 10.6.

При нажатии на "шестеренки" получаем результат работы программы:

Рис. 10.7.

Соответствующий фрагмент исходного кода этого JSP -документа выглядит так:

no cell phone specified

В этом примере используется объект customer – " покупатель ", заданный в файле Customer . java , расположенном в пакете org. apache .taglibs.standard.examples. beans . То есть самом первом в Source Packages пакете примера. А также объект customers – "покупатели", заданный в файле Customers. java , расположенном в том же пакете.

В классе customer заданы поля lastName , phoneHome, phoneCell и другие. А также ряд методов, которые также можно вызывать в сценарии. С помощью оператора forEach (заданного аналогично оператору out ) осуществляется перебор всех объектов customer , агрегированных в объект customers - список покупателей. А с помощью тега c:out осуществляется вывод необходимой информации в документ.

В JSP имеется огромное количество возможностей. Это тема для отдельной книги. В данном учебном пособии данная технология затронута совсем немного – просто в порядке информирования о ее существовании и некоторых возможностях.

Точно так же, для программирования в локальных и глобальных компьютерных сетях в пакете java . net имеется огромное количество средств разного уровня, описание которых требует отдельной книги. Это и Web -адресация (классы URL, HttpURLConnection, URI, JarURLConnection, URLClassLoader ), и IP-адресация (классы InetAddress, InetAddress4, InetAddress6, NetworkInterface), и управление соединениями через сокеты (классы Socket, SocketAddress, InetSocketAddress, ServerSocket, SocketPermission ). Классы NetPermission , Authentificator и PasswordAuthentification обеспечивают поддержку авторизации ( запрос и обработку имени и пароля).

Кроме упомянутых возможностей пакета java . net имеется

13.05.05 14.8K

Введение

Технология Java Server Pages (JSP) является составной частью единой технологии создания бизнес-приложений J2EE. JSP — это альтернативная методика разработки приложений, динамически генерирующих ответ на те или иные запросы клиента. Прежде чем JSP документ будет использован, специальная процедура преобразует его в соответствующий сервлет. В свою очередь, сервлет, как правило, пишется на языке Java и реализует определенный интерфейс. Далее, сервлет также не является самостоятельным приложением и функционирует, только будучи помещен в соответствующий web-контейнер. Web-контейнер обеспечивает обмен данными между сервлетом и клиентами, берет на себя выполнение таких функций, как создание программной среды для функционирующего сервлета, идентификацию и авторизацию клиентов, организацию сессии для каждого из них.

На настоящий момент реализована трансляция JSP страницы в сервлет, программный код которого пишется на языке Java. Однако авторы спецификации Java Server Pages оставляют возможность реализации JSP и на других языках программирования.

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

PrintWriter out = res.getWriter(); out.println(""); out.println(""); ... out.println(""); out.println(""); out.close();

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

Удобнее разделить динамическую и статическую части генерируемой web-страницы. Для создания динамической части по-прежнему будет использоваться Java или другой язык программирования. Статическую же часть имеет смысл оформить как текстовый документ — Java Server Page (JSP страницу), оформленную в соответствии с требованиями HTML, XML или другого стандарта разметки. Фактически, JSP страница можно рассматривать как шаблон или прообраз динамической страницы, которую остается дополнить динамическими элементами. Для описания динамической составляющей, в технологии JSP предусмотрено два основных механизма: компоненты JavaBean и библиотеки дополнительных тэгов. Как результат, технология JSP предполагает параллельную работу над приложением двух разных специалистов: программиста и ответственного за верстку документов (web мастера), которые отвечают, соответственно, за разработку динамической и статической частей документов, генерируемых в ответ на запросы клиентов.

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

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

JSP страница

Как правило, JSP страница хранится в отдельном файле с расширением.jsp. Большая часть содержимого JSP страницы преобразуется в сервлете в набор инструкций out.println(). Пример JSP страницы:

<%@ taglib uri="/exttags.tld" prefix="dscat" %> <%@ page import = "xbcat.util.*" %> All Customers <% Vector menu=pagescroll.getMenu(); if(pagescroll.page.size() > 0) { %>

<%= pagescroll.getTotalPages() %>

<% if(!pagescroll.isSinglePage()) { for(int i=0; i "><%= name %> <% } else { %> <%= name %> <% } } } %>

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

Директивы

Поскольку web контейнер, прежде чем использовать JSP страницу, предоставленную разработчиками бизнес-приложения, транслирует ее в соответствующий сервлет, имеет смысл предоставить возможность оставлять на JSP странице директивы, которые будут управлять процессом трансляции. Директивы имеют синтаксис

<%@ директива... %>

Рассмотрим некоторые из таких директив

Директива page. Декларирует ряд свойств JSP страницы. Синтаксис директивы:

<%@ page список_параметров %>

Опишем некоторые наиболее интересные параметры данной директивы:

• import — Как уже говорилось, JSP страница перед использованием должна быть преобразована в программный код — класс, соответствующего сервлета. В свою очередь, класс сервлета может обращаться к другим классам из стандартных библиотек Java или классам из других пакетов. По умолчанию, класс сервлета, получаемый после трансляции JSP страницы, может иметь связь с пакетами java.lang, java.servlet, java.servlet.jsp и java.servlet.http. Если для класса сервлета требуется обеспечить связь с другими пакетами, например, с xbcat.util как в приведенном выше примере JSP страницы, последнюю следует дополнить директивой page, имеющей атрибут import с названием соответствующего пакета.
• session — Если для связи с клиентом используется протокол HTTP, то для каждого сеанса по умолчанию создается объект session, позволяющий сохранять информацию об этом клиенте в интервале между его обращениями к серверу. С другой стороны, если атрибут session был указан со значением false, это позволяет отказаться от создания объекта сессии и использовать освободившиеся ресурсы сервера для решения других задач.
• buffer — Содержимое страницы, созданной в ответ на запрос клиента, сервлет передает в поток вывода out, откуда оно затем передается web контейнером непосредственно клиенту. Чтобы получить более оптимальный режим передачи, в этом потоке предусмотрен режим буферизации. При этом объем буфера по умолчанию составляет 8 килобайт. Параметр buffer директивы page позволяет либо задать другой объем буфера, либо вообще отказаться от режима буферизации, передав атрибуту значение «none».
• isThreadSafe — Согласно спецификации сервлетов, web контейнер по умолчанию позволяет одному и тому же экземпляру сервлета параллельно обрабатывать запросы сразу от нескольких клиентов. При этом каждому из запросов выделяется отдельный трэд. Между тем, в некоторых случаях бывает полезно запретить параллельную обработку запросов. (Соответствующий контроллер в web контейнере выстраивает приходящие запросы в очередь и передает их сервлету на обработку строго по одному.) Для этого достаточно использовать атрибут isThreadSafe, со значением false.
• pageEncoding — Позволяет разработчику приложения декларировать кодировку, которая должна использоваться в документе, передаваемом клиенту. По умолчанию считается, что страница имеет кодировку ISO-8859-1.
• contentType — В ответ на запрос клиента, JSP страница по умолчанию генерирует документ типа HTML. Вместе с тем, область применения технологии Java Server Pages гораздо шире, поскольку она позволяет генерировать любые другие типы текстовых документов: XML, WML, VRML и т.д. MIME-тип генерируемого документа декларируется атрибутом contentType. Как уже понятно, по умолчанию этот атрибут имеет значение «test/html». Вместе с типом документа, спецификация JSP позволяет в том же атрибуте указывать также кодировку генерируемого документа.

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

<%@ taglib uri="URI библиотеки тэгов" prefix="имя префикса" %>

где, uri — абсолютный или относительный адрес URI, уникальным образом идентифицирующий дескриптор библиотеки тэгов, связанных с указанным префиксом. Указанный префикс используется для идентификации соответствующих custom тэгов.

<%@ taglib uri="http://www.mycorp/supertags" prefix="super" %> ... ... ...

Процедуру создания custom тэгов мы рассмотрим позднее.

Директива include. Используется для помещения в JSP страницу текстов и программного кода из других источников. Подстановка выполняется в момент, трансляции JSP страницы в соответствующий сервлет. Пример использования директивы:

<%@ include file="menu.jsp" %>

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

Фрагмент программного кода на JSP странице (скрипт)

Скрипт, как и остальные элементы, привносит в конечный документ динамическую составляющую. Однако, в отличие от них, скрипт — программный код, помещенный непосредственно в текст JSP страницы. Скрипт может производить вычисления или манипулировать объектами, что позволяет наглядно связывать характеристики генерируемой страницы с параметрами запроса клиента и бизнес-правилами приложения. Элементы скриптов бывают трех типов: декларации, скриплеты и выражения.

Декларации

После преобразования JSP страницы в сервлет большая часть ее содержимого попадает в метод _jspService(), который вызывается всякий раз, когда появляется необходимость обработать заказ клиента. Декларация на JSP странице чаще всего используется для того, чтобы объявить дополнительные атрибуты и методы в классе сервлета, которые будут доступны при обработке любого запроса клиента. Декларации имеют синтаксис <%! … %> .

Примеры деклараций на JSP странице:

<%! int i; %> <%! int i = 0; %> <%! public String f(int i) { ... } %>

Скриплеты

Скриплет может содержать программный код и декларации локальных переменных, которые будут использованы для обработки запросов клиентов. Фактически, скриплет — это фрагмент программного кода из будущего сервлета, который в свое время будет помещен в метод _jspService(). Являясь частью сервлета, скриплет получает доступ к объекту response и, соответственно, может самостоятельно формировать определенную часть конечной динамической страницы. Однако чаще всего скриплеты используются не для этого, а для того, чтобы управлять объектами бизнес-логики и логикой приложения.

Скриплет имеет синтаксис <% … %> . Пример использования скриплетов в содержимом JSP страницы:

<% if (i == 0) { %> Good morning <% } else { %> Good afternoon <% } %>

Чтобы оценить наглядность и простоту этой конструкции, сравните ее с эквивалентным фрагментом программного кода в сервлете:

if (i == 0) { out.println("Good morning"); } else { out.println("Good afternoon"); }

Выражения

Часто страница, передаваемая клиенту, содержит результаты вычислений или обращений к тем или иным методам и атрибутам определенных классов. Любой из таких динамических элементов можно преобразовать в строку и представить на JSP странице с помощью вызова out.println в соответствующем скриплете:

<% UserProfile user = (UserProfile) session.getValue("Profile"); %> <% out.println(user.getFaxNumber()); %>

Вторую строку в приведенном примере удобнее и нагляднее представить в боле кратном виде, используя синтаксис выражения <%= … %> :

<%= user.getFaxNumber() %>

Другой пример использования выражения в теле JSP страницы:

<%! int i = 0; %> Hi, now the servlet processing <%= ++i %>th request.

JSP страницы и объекты

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

• page — Объект, чье время существования определяется как page, доступен в пределах только той JSP страницы, где он был создан. Все ссылки на этот объект должны быть освобождены сразу же после того, как запрос клиента был обработан.
• request — Объект, чье время существования определяется как request, доступен для всех страниц, связанных с обработкой данного запроса. В частности, если имеет место переадресация обработки на новую JSP страницу, данный объект будет доступен и на прежней, и на новой странице. Как и в предыдущем случае, ссылки на объект после обработки запроса должны быть освобождены.
• session — Объект с областью видимости session доступен для всех страниц, обрабатывающих запросы, связанные с определенной сессией (сеансом связи с конкретным клиентом). Ссылки на объекты, связанные с сессией, помещаются в объект session. По окончании сеанса связи ссылки должны быть освобождены.
• application — Наиболее общая область видимости. Объекты, имеющие область существования application, не привязаны к какой-либо отдельной странице или сеансу связи и доступны со всех JSP страниц данного приложения.

JSP страница всегда имеет доступ к определенному набору объектов, создаваемых web контейнером по умолчанию:

• request — Объект, содержащий запрос клиента. Относится к классу javax.servlet.ServletRequest или другому наследующему его классу. Например, для протокола HTTP это будет объект класса javax.servlet.http.HttpServletRequest. Область видимости объекта — request.
• response — Объект, в который сервлет будет помещать ответ на запрос пользователя. Относится к классу javax.servlet.ServletResponse или другому наследующему его классу. Например, для протокола HTTP это будет объект класса javax.servlet.http.HttpServletResponse. Область видимости объекта — request.
• pageContext — Объект, определяющий контекст JSP страницы. Область видимости объекта — page
• session — Объект, создаваемый контейнером для идентификации клиента, а также хранения персональных объектов. Создается контейнером для протокола HTTP и является экземпляром класса javax.servlet.http.HttpSession.
• application — Объект, связанный с конфигурацией сервлета, соответствующего данной JSP странице. Область видимости объекта — application.
• out — Объект, содержащий выходной поток сервлета. Информация, посылаемая в этот поток, будет передана клиенту. Объект является экземпляром класса javax.servlet.jsp.JspWriter. Например, большая часть статического шаблона на JSP странице, в идеале, должна быть записана в виде соответствующего набора команд out.println(). Область видимости объекта — page.
• config — Объект, связанный с конфигурацией сервлета. Является экземпляром класса javax.servlet.ServletConfig. Для JSP страницы область видимости объекта config — page.
• page — Объект, связанный с обработкой данной страницы. Область видимости — page

Элементы action

Независимо от того, какой тип будет иметь документ, генерируемый в ответ на запрос пользователя, в общем случае, JSP страница содержит текст и тэги. Очевидно, что последние соответствуют типу генерируемого документа: HTML, XML и т.д. Кроме того, в теле JSP страницы могут содержаться фрагменты программного кода на языке Java, которые должны войти в состав сервлета, получаемого после трансляции: декларации, скриплеты и выражения. Идея заключается в том, чтобы дополнить набор тэгов стандартной разметки специальными тэгами — элементами action, за которыми разработчик бизнес-приложения может скрыть часть программного кода, относящегося к приложению, либо некоторые дополнительные инструкции.

Заметим, что с точки зрения специалиста по верстке документов, элементы action являются такими же тэгами, как и все остальные, а потому допустимо их совместное использование с другими элементами:

Рассмотрим некоторые из этих элементов.

Стандартные элементы action

Стандартные элементы action выглядят как обычные тэги, название которых начинается с сочетания символов jsp:, например . Согласно терминологии XML, это означает, что стандартные элементы action в технологии JSP принадлежат пространству имен jsp.

jsp:useBean

Элемент jsp:useBean позволяет использовать на JSP странице объекты, соответствующие компонентам JavaBean. Элемент содержит параметр, который связывает с компонентом некий уникальный идентификатор. Последний затем будет использоваться при обращениях к этому объекту:

В данном примере создается объект класса com.myco. В дальнейшем, чтобы обратиться к нему, достаточно воспользоваться идентификатором «customer». Например:

<%= customer.getName() %>

По умолчанию, объекты, связанные с элементом JavaBean, по умолчанию имеют область видимости page. Разработчик JSP страницы может указать более продолжительное время существования объекта JavaBean, воспользовавшись при написании элемента jsp:useBean элементом scope. Возможные значения этого атрибута — page, request, session и application — мы обсуждали несколько ранее во время разговора об области видимости объектов, связанных с JSP страницей.

Мы не будем рассматривать остальные атрибуты элемента jsp:useBean. Приведем лишь еще один пример его использования:

Внутреннее устройство элементов JavaBean будет рассмотрено нами в отдельной статье.

jsp:setProperty и jsp:getProperty

Любой класс должен давать доступ к некоторым из своих атрибутов и методов. Отличие элемента JavaBean заключается в том, что доступ к атрибутам у него унифицирован и реализуется на JSP странице с помощью элементов jsp:setProperty и jsp:getProperty.

Элемент jsp:getProperty берет экземпляр Bean, извлекает значение указанного атрибута, преобразует его в случае необходимости в строку и помещает в поток данных, передаваемых клиенту. Например, согласно следующей записи

в генерируемый документ помещается значение свойства name из экземпляра Bean, имеющего идентификатор user.

Элемент jsp:setProperty, в отличие от предыдущего, не извлекает, а задает новое значение атрибута. Например:

Помимо явного задания новых значений, элемент jsp:setProperty позволяет заносить в атрибут объекта значение, извлеченное из запроса клиента. Например:

Данная запись означает, что среди данных, полученных от клиента, находится параметр login и его значение передается для помещения в атрибут name объекта Bean, имеющего идентификатор «user».

Наконец, когда названия полей в запросе клиента совпадают с названиями атрибутов объекта Bean, предусмотрен еще один вариант, когда разом осуществляется перенос всех значений. Например:

jsp:include

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

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

Пример использования элемента jsp:include:

jsp:forward

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

В следующем, более сложном примере динамическая страница завершается содержимым текстового файла, название которого берется из переменной someValue:

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

В первом случае, обработка запроса клиента и формирование в ответ динамической страницы производятся в рамках одной JSP страницы или сервлета. Последняя, в случае необходимости, может обращаться к объектам JavaBean или импортировать материал из внешних источников с помощью директивы include или элемента jsp:include.

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

Дополнительные наборы тэгов

Введение

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

Построение custom тэгов связано с написанием определенного программного кода. Технология JSP предусматривает размещение этого кода в отдельном программном модуле — библиотеке custom тэгов. Разработка подобных библиотек может быть поручена сторонним компаниям. Подключение JSP страницы к той или иной библиотеке custom тэгов осуществляется с помощью ранее описанной директивы taglib. Указанная директива связывает дескриптор соответствующей библиотеки с определенным префиксом, который, в свою очередь, идентифицирует в теле JSP страницы все custom тэги из данной библиотеки. Так, директива

<%@ taglib uri="/exttags.tld" prefix="dscat" %>

объявляет, что в JSP странице используется библиотека дополнительных тэгов, название каждого из которых начинается с префикса dscat. Например:

All Customers

Программный код данной библиотеки описывается дескриптором exttags.tld. Мы не будем здесь останавливаться на правилах написания дескриптора библиотеки, а рассмотрим лишь один из возможных примеров его реализации:

1.0 1.2 dscat pageheader ru.view.tag.PageHeader

Создание библиотеки custom тэгов

Custom тэги без обработки содержимого

Программный код для поддержки custom тэга — это специальным образом написанный экземпляр Java класса, который вызывается web контейнером всякий раз, когда требуется обработать JSP страницу, содержащую соответствующий тэг.

В простейшем случае, для поддержки custom тэга можно взять какой-либо из классов бизнес-приложения и дополнить его методами, соответствующими интерфейсу Tag. Если же внешних объектов использовать не надо, то в качестве базового класса можно использовать TagSupport. Эти и другие стандартные классы и интерфейсы находятся в пакете javax.servlet.jsp.tagext.

Пример класса, осуществляющего поддержку custom тэга:

public CopyrightTag extends TagSupport { public int doStartTag() throws Exception { pageContext.getOut().print("© Copyright, 2001"); return SKIP_BODY; } public int doEndTag() { return EVAL_PAGE; } }

Методы класса, который осуществляет обработку custom тэга, вызываются в определенной последовательности. Когда в JSP странице обработка доходит до открывающего custom тэга, для его обработки вызывается метод doStartTag(). Когда обработка доходит до соответствующего закрывающего тэга, вызывается метод doEndTag(). Для обработки той части JSP страницы, которая заключена между этими двумя тэгами, используются методы doInitBody() и doAfterBody().

Помимо того, что метод doStartTag() может осуществлять какую-либо обработку запроса, большое значение имеет возвращаемое им значение. Если это SKIP_BODY, то информация, заключенная между соответствующими открывающим и закрывающим тэгами, будет игнорироваться, а обработка JSP страницы сразу перейдет на закрывающий тэг. Чтобы содержимое custom тэга все же обрабатывалось, медот должен возвратить EVAL_BODY_INCLUDE. Аналогично, если метод doEndTag() возвратит значение SKIP_PAGE, то оставшаяся часть JSP страницы после закрывающего тэга будет проигнорирована. Чтобы не допустить этого, метод должен возвратить значение EVAL_PAGE.

В некоторых случаях бывает необходимо показать содержимое custom тэга не один, а несколько раз. В этом случае, класс, осуществляющий обработку тэга, должен реализовывать интерфейс IterationTag, либо использовать в качестве родителя класс TagSupport. Чтобы повторить вывод содержимого custom тэга еще раз, необходимо, чтобы методы doStartTag и doAfterBody возвращали EVAL_BODY_AGAIN.

Custom тэги с обработкой содержимого

Если требуется доступ к содержимому custom тэга, то соответствующий Java класс должен реализовывать интерфейс BodyTag или же наследовать класс BodyTagSupport. И в том, и в другом случае класс может реализовать методы doInitBody и doAfterBody.

Метод doInitBody вызывается сразу после того, как выявлено содержимое тэга, но до того, как оно будет обработано. Обычно этот метод используется когда необходимо выполнить инициализацию класса в зависимости от содержимого custom тэга.

Метод doAfterBody вызывается после того, как содержимое custom тэга было обработано. Как и в предыдущем разделе, метод doAfterBody может указывать, следует ли повторить обработку содержимого тэга еще раз. Если это необходимо, метод должен возвратить значение EVAL_BODY_BUFFERED. В противном случае он должен возвратить SKIP_BODY.

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

Непосредственно для доступа к содержимому custom тэга технологией предусмотрено два метода: getString и getReader.

Атрибуты в custom тэгах

Помимо информации в промежутке между открывающим и закрывающим тэгами, custom тэг может иметь некоторые атрибуты, которые также могут оказывать влияние на порядок обработки запроса клиента. Для каждого из таких атрибутов в классе, реализующем custom тэг, должен быть указан соответствующий атрибут, а также два метода get и set. Например, если custom тэг имеет вид

то реализующий этот custom тэг класс должен содержать следующий код:

из

Хорошо Плохо

В отличие от сервлетов, требующих компиляции java-файла для получения класса (файла *.class) jsp страница не требует компиляции и регистрации в дескрипторе поставки web.xml .

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

Пример Dynamic Web Project

Рассмотрим простой пример, в котором на JSP странице приветствия будут отображены текущая дата и время. Для разработки будет использована IDE Eclipse. На следующем скриншоте представлено определение типа проекта Dynamic Web Project .

Определим наименование проекта как HelloJSP и создадим в проекте файл index.jsp . Структура проекта представлена на следующем скриншоте.

Код дескриптора приложения web.xml

index.jsp

В дескрипторе приложения web.xml в качестве страницы приветствия определен JSP файл index.jsp .

Исходный код JSP страницы index.jsp

<%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%> <%@ page import="java.util.*, java.text.*" %> <%! String getFormattedDate() { SimpleDateFormat sdf = new SimpleDateFormat("dd.MM.yyyy hh:mm:ss"); return sdf.format(new Date()); } %>

Добро пожаловать!

Сегодня <%= getFormattedDate() %>

Страницы JSP имеют комбинированный синтаксис: объединение стандартного синтаксиса, соответствующего спецификации HTML, и синтаксиса JSP, определенного спецификацией Java Server Pages. Синтаксис JSP определяет правила записи страниц JSP, состоящих из стандартных тегов HTML и тегов JSP.

Страницы JSP, кроме HTML-тегов, содержат теги JSP следующих категорий:

JSP директивы

JSP директивы обеспечивают глобальную информацию, касающихся конкретных запросов, направляемых в сервер, и предоставляют информацию, необходимую на стадии трансляции. Директивы всегда помещаются в начале JSP-страницы до всех остальных тегов, чтобы parser (анализатор) JSP при разборе текста в самом начале выделил глобальные инструкции. Таким, образом, JSP Engine (среда исполнения JSP), анализируя код, создает из JSP сервлет. Директивы представляют собой сообщения контейнеру JSP.

Синтаксис JSP директив выглядит следующим образом:

<%@ директива имяАтрибута="значение" %>

Синтаксис задания директив на XML:

JSP директива может иметь несколько атрибутов. В этом случае директива может быть повторена для каждого из атрибутов. В то же время пары "имяАтрибута=значение" могут располагаться под одной директивой с пробелом в качестве разделителя.

Существует три типа директив:

• page (страница)
• taglib (библиотека тегов)
• include (включить)

JSP директива page

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

<%@ page buffer="none" isThreadSafe="yes" errorPage="/error.jsp" %>

Директива page объявляет, что данная страница JSP не использует буферизацию, что возможно одновременное обращение к данной странице JSP многих пользователей, и что поддерживается страница ошибок с именем error.jsp .

JSP директива page может содержать информацию о странице:

<%@ page info = "JSP Sample 1" %>

Список возможных атрибутов директивы page представлен в таблице.

Наименование атрибута	Значение	Описание
language	Строка	Определяет язык, используемый в скриптлетах файла JSP, выражениях или любых включаемых файлах, в том числе, в теле оттранслированного кода. По умолчанию принимается значение "java"
extends	Строка	Задает суперкласс для генерируемого сервлета. Этот атрибут следует использовать с большой осторожностью, поскольку возможно что сервер уже использует какой-нибудь суперкласс
import	Строка	Определение импортируемых пакетов., например: <%@ page import="java.util.* %>
Session	true или false	Значение true (принимается по умолчанию) свидетельствует о том, что заранее определенная переменная session (тип HttpSession) должна быть привязана к существующей сессии, если таковая имеется, в противном случае создается новая сессия, к которой осуществляется привязка. Значение false определяет что сессии не будут использоваться, и попытки обращения к переменной session приведут к возникновению ошибки при трансляции JSP страницы в сервлет
Buffer	none или размер буфера в кБ.	Задает размер буфера для JspWriter out. Значение принимаемое по умолчанию зависит от настроек сервера, и не должно превышать 8 кБ. Если значение равно none вывод происходит непосредственно в объект ServletResponse
autoFlush	true или false	Определяет, должен ли буфер освобождаться автоматически, когда он переполнен или произошла ошибка. По умолчанию значение true
isThreadSafe	true или false	Значение true (принимается по умолчанию) задает нормальный режим выполнения сервлета, когда множественные запросы обрабатываются одновременно с использованием одного экземпляра сервлета, исходя из соображения, что автор синхронизировал доступ к переменным этого экземпляра. Значение false ("ложь") сигнализирует о том, что сервлет должен наследовать SingleThreadModel (однопоточную модель), при которой последовательные или одновременные запросы обрабатываются отдельными экземплярами сервлета
info	Строка	Определяет строку информации о странице JSP, которая будет доступна с помощью метода Servlet.getServletInfo ()
errorPage	Строка	Значение атрибута представляет собой URL страницу, которая должна выводиться в случае возможных ошибок, вызывающих исключения
isErrorPage	true или false	Сигнализирует о том, может ли эта страница использоваться для обработки ошибок для других JSP страниц. По умолчанию принимается значение false
contentType	Строка	Определяет кодировку для страницы JSP и ответа, а также MIME-тип ответа JSP. Значение по умолчанию типа содержания - text/html , кодировки - ISO-8859-1. Например: contentType="text/html;charset=ISO-8859-1"
pageEncoding	Строка	Определяет кодировку символов страницы JSP. По умолчанию используется charset из атрибута contentType , если оно там определено. Если значение charset в атрибуте contentType не определено, значение pageEncoding устанавливается равным ISO-8859-1

JSP директива taglib

JSP директива taglib объявляет, что данная страница JSP использует библиотеку тегов, уникальным образом идентифицируя ее с помощью URI, и ставит в соответствие префикс тега, с помощью которого возможны действия в библиотеке. Если контейнер не может найти библиотеку тегов, возникает фатальная ошибка трансляции.

Директива taglib имеет следующий синтаксис:

<%@ taglib uri="URI включаемой библиотеки тегов " prefix="имяПрефикса " %>

Префикс "имяПрефикса " используется при обращении к библиотеке. Пример использования библиотеки тегов mytags :

<%@ taglib uri="http://www.taglib/mytags" prefix="customs" %> . . .

В данном примере библиотека тегов имеет URI-адрес "http://www.taglib/mytags" , в качестве префикса назначена строка customs , которая используется в странице JSP при обращении к элементам библиотеки тегов.

JSP директива include

JSP Директива include позволяет вставлять текст или код в процессе трансляции страницы JSP в сервлет. Синтаксис директивы include имеет следующий вид:

<%@ include file="Относительный URI включаемой страницы " %>

Директива include имеет один атрибут - file . Она включает текст специфицированного ресурса в файл JSP. Эту директиву можно использовать для размещения стандартного заголовка об авторских правах на каждой странице JSP:

<%@ include file="copyright.html" %>

Контейнер JSP получает доступ к включаемому файлу. Если включаемый файл изменился, контейнер может перекомпилировать страницу JSP. Директива include рассматривает ресурс, например, страницу JSP, как статический объект.

Заданный URI обычно интерпретируется относительно JSP страницы, на которой расположена ссылка, но, как и при использовании любых других относительных URI, можно задать системе положение интересующего ресурса относительно домашнего каталога WEB-сервера добавлением в начало URI символа "/". Содержимое подключаемого файла обрабатывается как обычный текст JSP и поэтому может включать такие элементы, как статический HTML, элементы скриптов, директивы и действия.

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

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

JSP директива declarations

JSP директива declarations предназначены для определения переменных и методов на языке скриптов, которые в дальнейшем используются на странице JSP. Синтаксис declarations имеет следующий вид:

<%! код Java %>

declarations располагаются в блоке объявлений, а вызываются в блоке выражений страницы JSP. Код в блоке объявлений обычно пишется на языке Java, однако серверы приложений могут использовать синтаксис и других скриптов. Объявления иногда используются для того, чтобы добавить дополнительную функциональность при работе с динамическими данными, получаемыми из свойств компонентов JavaBeans. Примеры объявлений представлены в таблице.

Declarations может содержать несколько строк, как например, в приведенном ниже коде вычисления значения функции fact (int n) , которая должна быть равна 1 при n меньше 2 и n! при положительном значении n;

<%! public static int fact (int n) { if (n <= 1) return 1; else return n * fact (n - 1); } %>

declarations не производят никакого вывода в стандартный выходной поток out . Переменные и методы, декларированные в объявлениях, инициализируются и становятся доступными для скриптлетов и других объявлений в момент инициализации страницы JSP.

Скриптлеты scriptlets

scriptlets включают различные фрагменты кода, написанного на языке скрипта, определенного в директиве language . Фрагменты кода должны соответствовать синтаксическим конструкциям языка скриптлетов , т.е., как правило, синтаксису языка Java. scriptlets имеют следующий синтаксис:

<% текст скриптлета %>

Эквивалентом синтаксиса скриптлета для XML является:

текст скриптлета

Если в тексте скриптлета необходимо использовать последовательность символов %> именно как сочетание символов, а не как тег - признак окончания скриптлета , вместо последовательности %> следует использовать следующее сочетание символов %\>.

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

<% if (Calendar.getInstance ().get (Calendar.AM_PM) == Calendar.AM) {%> Good Morning <% } else { %> Good Afternoon <% } %>

Необходимо отметить, что код внутри скриплета вставляется в том виде, как он записан, и весь статический HTML-текст (текст шаблона) до или после скриплета конвертируется при помощи оператора print . Это означает что скриплеты не обязательно должны содержать завершенные фрагменты на Java, и что оставленные открытыми блоки могут оказать влияние на статический HTML-текст вне скриплета .

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

<% String queryData = request.getQueryString (); out.println ("Дополнительные данные запроса: " + queryData); %>

Выражения expressions

Выражения expressions в странице JSP - это исполняемое выражение, написанное на языке скрипта, указанного в объявлении language (как правило Java). Результат выражения JSP, имеющий обязательный тип String, направляется в стандартный поток вывода out с помощью текущего объекта JspWriter . Если результат выражения не может быть приведен к типу String , возникает либо ошибка трансляции, если проблема была выявлена на этапе трансляции, либо возбуждается исключение ClassCastException , если несоответствие было выявлено в процессе выполнения запроса. Выражение имеет следующий синтаксис:

<%= текст выражения %>

альтернативный синтаксис для JSP expressions при использовании XML:

текст выражения

Порядок выполнения expressions на странице JSP слева-направо. Если выражение появляется более чем в одном атрибуте времени выполнения, то оно выполняется слева-направо в данном теге. Выражение должно быть полным выражением на определенном скрипте (как правило Java).

expressions выполняются во время работы протокола HTTP. Значение выражения преобразуется в строку и включается в соответствующую позицию файла JSP.

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

Текущее время: <%= new java.util.Date () %>

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

• request, HttpServletRequest;
• response, HttpServletResponse;
• session, HttpSession - ассоциируется с запросом, если таковой имеется;
• out, PrintWriter - буферизированный вариант типа JspWriter для отсылки данных клиенту.