Архитектура Аудит Военная наука Иностранные языки Медицина Металлургия Метрология
Образование Политология Производство Психология Стандартизация Технологии


Применение библиотечных тегов



На рис. 4.18 приводится пример jsp-страницы, разработанной с применением tld-тегов: dossier, surname, lastname, submit.                                                

<?xml version="1.0" encoding="ISO-8859-1" ?> <%@ page language="java" contentType="text/html; charset=ISO-8859-1"      pageEncoding="ISO-8859-1"%> <%@ taglib uri = "stafftag.tld" prefix ="staff" %> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"           "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="Content-Type" content="text/html;                charset=ISO-8859-1" /> <title>Dossier</title> </head> <body>  <staff:dossier action= "PostExample" > <br /><staff:surname value="Smelov" /> <br /><staff:lastname value="Vladimir" /> <br /><staff:submit name ="press" /> </staff:dossier> </body> </html>

Тег <%@ taglib > описывает jsp-директиву taglib, которая указывает на месторасположение библиотеки тегов и устанавливает префикс (пространство имен) для tld-тегов. В нашем случае дескриптор библиотеки тегов должен находиться в корне директории WEB-INF приложения, а префикс имеет значение staff .  

 

 


 

10. Java EE: основные модели web-приложений на основе технологий Servlet и JSP.

 

Технология Java Server Pages ( JSP ) предназначена для создания специальной серверной компоненты web-приложения, называемой jsp-страницей и обладающей одновременно свойствам html-страницы и сервлета. В самом первом приближении jsp-страница – это html-странница с вкраплениями java-кода. Как и в случае с сервлетом для исполнения jsp-страницы требуется специальный контейнер (JSP Engine), который отвечает за разбор (parsing) страницы JSP и преобразование ее в сервлет, генерирующий при исполнении html-код. 

Применение технологии JSP, не отрицает, а скорее дополняет технологию Java Servlet. Два основных архитектурных похода при реализации приложеьний по технологии JSP имеют специальные названия: JSP Model 1 (рис. 4.1) и JSP Model 2 (рис. 4.2).

jsp-страница
JavaBean-объект
  Источники данных
Web-сервер

В первом архитектурном решении jsp-страница полностью отвечает за получение запроса клиента, его обработку, подготовку и отправку ответа. Для доступа к данным, как правило, используется объект JavaBean, который создается и инициализируется jsp-страницей. Методы этого объекта предназначены для формирования запроса к источнику данных (например, к серверу базы данных), а свойства для хранения данных запроса и результатов ответа.

сервлет
JavaBean-объект
  Источники данных
Web-сервер
jsp-страница

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

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

 


 

11. Java EE: основные системные объекты (контекст, сессия, запрос, ответ), назначение и жизненный цикл объектов. Атрибуты системных объектов и принципы их применения.

 



Контекст

Объект Context (контекст web-приложения) – структура, хранящая информацию о самом web-приложении, его компонентах и среде, в котором оно работает.

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

Наиболее часто web-программист сталкивается с необходимостью использовать параметры инициализации (статический элемент контекста) и атрибуты контекста (динамический элемент контекста).

Сеанс связи (сессия)

Протокол HTTP является stat less протоколом, т.е. протоколом, не сохраняющего информацию о своем состоянии. Это означает, что каждый запрос и ответ имеют свой жизненный цикл, никак не связанный с предшествующими им запросами и ответами. Поэтому управление сеансом связи с пользователем является важной и нетривиальной задачей.            

Объект Session (сеанс связи или сессия) реализует интерфейс HttpSession и  служит для представления пользователя, работающего с клиентской частью web-приложения. Объект сессии создается, как правило, web-контейнером и становится доступным в сервлете или JSP с помощью метода getSession объекта Request

Время существование сессии зависит от параметра Session timeout, который может быть установлен в дескрипторе развертывания или в конфигурационных файлах сервера и может быть изменено динамически, например, в сервлете. Этот параметр устанавливает максимальное время между запросами одного клиента. Превышение этого значения приводит к удалению объекта Session.

В принципе, объект сессии может разрушить и изнутри, выполнив метод invalidate интерфейса HttpSession.   

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

Запрос

При http-запросе информация передается от клиента к серверу в виде http-заголовков и тела сообщения запроса. Web-контейнер получив запрос создает объект типа HttpServletRequest, который затем передается методу service сервлета в качестве параметра или представляется как неявный объект request в JSP.   

Объект типа HttpServletRequest инкапсулирует базовый http- запрос и предоставляет методы позволяющие определить тип запроса, используемую кодировку, MIME-тип, ip-адрес клиента, номер порта и т. п., обработать параметры, атрибуты, заголовки, тело сообщения запроса. 

Ответ

Ответ – это объект типа HttpServletResponse, который инкапсулирует информацию, передаваемую от сервлета или JSP клиенту. В качестве клиента может выступать, как web-браузер, так и любой другой компонент web-приложения, поддерживающий http-протокол. Объект ответа создается web-контейнером после получения запроса. В сервлет ответ передается в виде второго параметра метода service, а в JSP он представлен в виде неявного объекта response.

Объект Request создается контейнером при получении http-запроса к компоненте web-приложения и инкапсулирует всю необходимую информацию о запросе клиента. Этот объект существует и доступен только в рамках обработчика запроса (в нашем случае сервлета или jsp-страницы). 

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

Объект Context создается контейнером при его инициализации на основе дескриптора развертывания приложения. Помимо общего контекста создаются контексты для каждого сервлета и jsp-страницы.  

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


 

12. Java EE: дескриптор развертывания web-приложения. Параметры инициализации web-приложения: назначение, принципы применения.

 

Дескриптор развертывания является важной частью web-приложения, предназначенный для хранения его основных параметров.

Дескриптор развертывания приложения представляет собой xml-файл, корневым элементом которого является тег <web-app>. Дескриптор приложения может содержать достаточно много различных и повторяющихся элементов. Порядок элементов внутри          <web-app> и их синтаксис определяется схемой XML, с которая, как это видно из параметров тега <web-app>, находится по адресу http :// java . sun . com / xml / ns / j 2 ee / web - app _2_5. xsd.

В самом простом случае дескриптор развертывания состоит только из одного тега <web-app>, внутри которого ничего нет. В нашем случае, имеется еще три тега: <display-name>, <welcome-file-list> и <welcome-file>.

Тег <display-name> не является обязательным, но если есть, то не может повторяться более одного раза. Этот тег предназначен для указания имени web-приложения, которое потом может быть использовано в графическом интерфейсе. Для этого имени не требуется уникальность и его значение не оказывает влияния на работу приложения.        

Тег <welcome-file-list> тоже не является обязательным и предназначен для указания списка стартовых страниц web-приложения. Имена файлов странниц указываются внутри тега <welcome-file-list> с помощью одного или более тегов <welcome-file>. В нашем примере в качестве стартовой страницы используется файл index.html. В общем случае, может быть указано несколько стартовых страниц для одного web-приложения. В этом случае поиск их осуществляется в указанном порядке. Если ни одного файла не было найдено, сервер возвращает сообщение об ошибке HTTP Status 404. Пусть, например, для вызова приложения ANaive используется адресная строка http://xxx:8080/ANaive, где xxx – разрешаемое символическое имя компьютера. Тогда первой отобразится страница index.html, т.к. именно она указана в списке стартовых страниц дескриптора развертывания. При отсутствии тега <welcome-file-list> (и соответственно тегов <welcome-file>) имена стартовых страниц Tomcat определяет с помощью списка в теге <welcome-file-list> конфигурационного файла Tomcat 6.0/conf/web.xml. На рис.2.8 отображен фрагмент этого файла, содержащий список стартовых страниц.        

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

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

· Метод init(), объявленный интерфейсом Servlet, принимает объект ServletConfig в качестве его параметра;

· Метод getServletConfig(), объявленный интерфейсом Servlet, возвращает объект ServletConfig.

Манера, в которой параметры инициализации предоставляются сервлету, зависит от сервера.

<?xml version="1.0" encoding="UTF-8"?>

<web-app xmlns="http://java.sun.com/xml/ns/javaee"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://java.sun.com/xml/ns/javaee

http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"

version="2.5">

<display-name>ANaive</display-name>

<welcome-file-list>

<welcome-file>index.html</welcome-file>

</welcome-file-list>

<servlet>

<servlet-name>Hhh</servlet-name>

<servlet-class>Hhh</servlet-class>

<init-param>

<param-name>fhtml</param-name>

<param-value>male.html</param-value>

</init-param>

</servlet>

</web-app>

Получить значение параметра инициализации в сервлете можно с помощью метода getInitParameter интерфейса Servlet. На рис. 3.35 приведен фрагмент сервлета, считывающего значение параметра fhtml.

public class Hhh extends HttpServlet implements Servlet {


Поделиться:



Последнее изменение этой страницы: 2019-04-19; Просмотров: 212; Нарушение авторского права страницы


lektsia.com 2007 - 2024 год. Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав! (0.036 с.)
Главная | Случайная страница | Обратная связь