18118

JSP (Java Server Pages )

Лекция

Информатика, кибернетика и программирование

Тема 3: JSP Java Server Pages Технологія Java Server Pages JSP є складовою частиною єдиної технології створення програм на основі технології J2EE з використанням webінтерфейсу. JSP це альтернативна технології Java Servlet методика розробки програм що динамічно генерують відповідь на ті або інш...

Украинкский

2013-07-06

97 KB

9 чел.

Тема 3: JSP (Java Server Pages )

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

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

Залежність між сервлетами програми і адресами URL на сервері задається в дескрипторі розміщення. Відносно технологія створення сервлетів, важливо відзначити той факт, що програмний код, що використовується для написання сервлетів, не завжди зручний для динамічної генерації текстових документів у відповідь на запит клієнта. Наприклад, фрагмент сервлета, в якому здійснюється генерація динамічної HTML сторінки, може виглядати таким чином:

PrintWriter out = res.getWriter();

out.println("<html>");

out.println("<body>");

...

out.println("</body>");

out.println("</html>");

out.close();

Як бачимо, кожному рядку HTML документа в сервлеті відповідає певний фрагмент програмного коду, що не сприяє простоті розробки і супроводу програм – код стає громіздким, зі змішаними частинами логіки програми і виведення.

Зручніше розділити динамічну і статичну частині web-сторінки, що генерується. Для створення динамічної частини як і раніше використовуватиметься Java або інша мова програмування. Статичну ж частину має сенс оформити як текстовий документ - Java Server Page (JSP сторінку), оформлену відповідно до вимог HTML або іншого стандарту розмітки. Фактично, 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.*"  %>

 

<dscat:pageheader>All Customers</dscat:pageheader>

<jsp:useBean id="pagescroll" class="ru.view.bean.ScrollPage" scope="session">

</jsp:useBean>

<jsp:setProperty name="pagescroll" property="PageSize" param="psize" />

<html><body>

<%

 Vector menu=pagescroll.getMenu();

 if( pagescroll.page.size() > 0 ){

%>

<table width="100%" border="0">

<tr>

<td>

 <%= pagescroll.getTotalPages() %>

</td>

<td align="right">

<% if(!pagescroll.isSinglePage()){

   for(int i=0; i<menu.size(); i++){

     String href = ((ScrollMenu)menu.elementAt(i)).m_Href;

     String name = ((ScrollMenu)menu.elementAt(i)).m_Name;

     if( href != null ){ %>

   <a href="<%= href %>"><%= name %></a>

<% } else { %>

   <%= name %>

<%    }

   }

 } %>

</td>

</tr>

</table></body></html>

Динамічна складова 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. Як вже зрозуміло, за змовчанням цей атрибут має значення "text/html".

Директива taglib. Дозволяє використовувати на JSP сторінках додаткові теги, створені або отримані з інших джерел розробником програми (custom теги). Синтаксис директиви:

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

де, uri - абсолютна або відносна адреса URI, що унікальним чином ідентифікує дескриптор бібліотеки тегів, пов'язаних з вказаним префіксом. Вказаний префікс використовується для ідентифікації відповідних custom тегів далі в тексті jsp.

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

...

<super:doMagic>...</super:doMagic>

...

Директива include. Використовується для поміщення в JSP сторінку текстів і програмного коду з інших джерел. Підстановка виконується в момент трансляції JSP сторінки у відповідний сервлет. Приклад використання директиви:

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

Відзначимо, що підстановка матеріалів із зовнішнього джерела може виконуватися також за допомогою спеціального тега <jsp:include>, який буде розглянутий пізніше. Відмінність даного тега від описуваної директиви полягає в тому, що підстановка здійснюється безпосередньо в процесі обробки клієнтського запиту, а тому може бути прив'язано до параметрів запиту.

Фрагмент програмного коду на 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 є такими ж тегами, як і всі інші, а тому допустимо їх сумісне використання з іншими елементами:

<jsp:setProperty name="results" property="row" value="<%= i+1 %>" />

Розглянемо деякі з цих елементів.

Стандартні елементи action

Стандартні елементи action виглядають як звичайні теги, назва яких починається з поєднання символів jsp:, наприклад <jsp:include ...>. Згідно термінології XML, це означає, що стандартні елементи action в технології JSP належать простору імен jsp.

jsp:useBean

Елемент jsp:useBean дозволяє використовувати на JSP сторінці об'єкти, відповідні компонентам JavaBean. Елемент <jsp:useBean> містить параметр, який пов'язує з компонентом якийсь унікальний ідентифікатор. Останній потім використовуватиметься при зверненнях до цього об'єкту:

<jsp:useBean id="customer" class="com.myco.Customer" />

У даному прикладі створюється об'єкт класу com.myco. Надалі, щоб звернутися до нього, досить скористатися ідентифікатором "customer". Наприклад:

<%= customer.getName() %>

За змовчанням, об'єкти, пов'язані з елементом JavaBean, мають область видимості page. Розробник JSP сторінки може вказати триваліший час існування об'єкту JavaBean, скориставшись при написанні елементу jsp:useBean елементом scope. Можливі значення цього атрибуту - page, request, session і application обговорювалися раніше.

jsp:setProperty і jsp:getProperty

Будь-який клас повинен давати доступ до деяких з своїх атрибутів і методів. Відмінність елементу JavaBean полягає в тому, що доступ до атрибутів у нього уніфікований і реалізується на JSP сторінці за допомогою елементів jsp:setProperty і jsp:getProperty.

Елемент jsp:getProperty бере екземпляр Bean, витягує значення вказаного атрибуту, перетворить його у разі потреби в рядок і поміщає в потік даних, передаваних клієнту. Наприклад, згідно наступного запису

<jsp:getProperty name="user" property="name" />

у документ, що генерується, поміщається значення властивості name з екземпляра Bean, що має ідентифікатор user.

Елемент jsp:setProperty, на відміну від попереднього, не витягує, а задає нове значення атрибуту. Наприклад:

<jsp:setProperty name="user" property="name" value="Victor" />

Крім явного задання нових значень, елемент jsp:setProperty дозволяє заносити в атрибут об'єкту значення, витягнуте із запиту клієнта. Наприклад:

<jsp:setProperty name="user" property="name" param="login" />

Даний запис означає, що серед даних, одержаних від клієнта, знаходиться параметр login і його значення передається для переміщення в атрибут name об'єкту Bean, що має ідентифікатор "user".

Нарешті, коли назви полів в запиті клієнта співпадають з назвами атрибутів об'єкту Bean, передбачений ще один варіант, коли разом здійснюється перенесення всіх значень. Наприклад:

<jsp:setProperty name="user" property="*" />

jsp:include

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

Відмінність директиви include від елементу jsp:include полягає в тому, що для неї матеріал, що включається, не може бути динамічним, а пошук і обробка можливих динамічних фрагментів здійснюється не окремо, а після включення, зі всією сторінкою.

Приклад використання елементу jsp:include:

<jsp:include page="/inc/menu.jsp" />

jsp:forward

Даний елемент дозволяє переадресувати подальше формування динамічної сторінки на іншу JSP сторінку, сервлет або використовувати для завершення наперед підготовлений текст. Наприклад:

<jsp:forward page="/inc/copyright.jsp" />

У наступному, складнішому прикладі динамічна сторінка завершується вмістом текстового файлу, назва якого береться із змінної someValue:

<% String whereTo = "/templates/" + someValue; %>

<jsp:forward page='<%= whereTo %>' />

На завершення слід зазначити, що є дві основні схеми обробки запитів клієнта.

У першому випадку, обробка запиту клієнта і формування у відповідь динамічної сторінки проводяться в рамках однієї 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. Наприклад:

<dscat:pageheader>All Customers</dscat:pageheader>

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

<?xml version="1.0" encoding="ISO-8859-1" ?>

<!DOCTYPE taglib

       PUBLIC "-//Sun Microsystems, Inc.//DTD JSP Tag Library 1.2//EN"

      "http://java.sun.com/dtd/web-jsptaglibrary_1_2.dtd">

<taglib>

 <tlib-version>1.0</tlib-version>

 <jsp-version>1.2</jsp-version>

 <shortname>dscat</shortname>

 <tag>

   <name>pageheader</name>

   <tag-class>ru.view.tag.PageHeader</tag-class>

 </tag>

</taglib>

Створення бібліотеки 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("<small>© Copyright, 2001</small>");

 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 тег має вигляд

<dscat:pageheader height="huge">

то клас, що реалізує цей custom тег, повинен містити наступний код:

protected String height = null;

public String getHeight() {

 return (this.height);

}

public void setHeight(String value){

 this.height = value;

}

Атрибути custom тега також необхідно декларувати в дескрипторі бібліотеки custom тегів.


 

А также другие работы, которые могут Вас заинтересовать

23390. ПОВЕРКА ЭЛЕКТРОННОГО АВТОМАТИЧЕСКОГО ПОТЕНЦИОМЕТРА 69.27 KB
  max=[Δ1;2max EkEн]100 Vприв.max=[E2E1max EkEн]100 γprmax=11.596 εprmax=6.
23391. Исследование метрологических характеристик средств измерений 171 KB
  Относительная погрешность = 05. № Показания приборов Сопротивление R Показания Абсолютная погрешность Относительная погрешность Прямой R' Обратный R'' Прямой Δ' Обратный Δ'' Прямой δ' Обратный δ'' 1 120 6752 6699 6696 053 056 000785 0008294 2 120 6752 6703 6704 049 048 0007257 0007109 3 120 6752 6696 6703 056 049 0008294 0007257 4 120 6752 6699 6704 053 048 000785 0007109 5 120 6752 6699 6705 053 047 000785 0006961 6 120 6752 6698 6704 054 048 0007998 0007109 7 120 6752 6701 6703 051 049 0007553...
23392. ПОВЕРКА ЭЛЕКТРОННОГО АВТОМАТИЧЕСКОГО ПОТЕНЦИОМЕТРА 72.92 KB
  max=[Δ1;2max EkEн]100 Vприв.max=[E2E1max EkEн]100 K=05 Условие: .
23393. Поверка электронного автоматического потенциометра калибратором измерителем ИКСУ-2000 67.73 KB
  Показания образцового прибораСо оС Показания поверяемого прибораСп оС Абсолютная погрешность поверяемого прибора Δ оС Относительная погрешность поверяемого прибора δ Приведённая погрешность поверяемого прибора δpr 0 05 05 025 40 38 2 5 1 80 78 2 25 1 120 1185 15 125 075 160 159 1 0625 05 200 1995 05 025 025 160 1595 05 03125 025 120 119 1 0833333 05 80 785 15 1875 075 40 39 1 25 05 0 05 05 025 Δ=CоСп δ= Δ Со100 δpr= Δ 200100 K=05; δprmax=1 Прибор не удовлетворяет классу точности Δ=fCo δ=fCo...
23394. Поверка автоматического электронного моста 284.18 KB
  моста Ом Абсолютная вариация V Ом прямой ход Rt1 обратный ход Rt2 прямой ход1 обратный ход2 0 46 4561 4556 039 044 005 40 5316 5278 5277 038 039 001 80 60463 5996 5995 0503 0513 001 120 6752 6697 6695 055 057 002 160 7452 7383 7395 069 057 012 200 8143 8075 808 068 063 005 1= Rt– Rt1 2= Rt – Rt2 ...
23395. Исследование метрологических характеристик средств измерений 165.5 KB
  Номер Показания Сопроти Прямой Обратный Прямой Обратный Прямой Обратный № С вление R ход R' ход R'' ход Δ' ход Δ'' ход δ' ход δ'' 1 120 6752 6699 6696 053 056 000785 0008294 2 120 6752 6703 6704 049 048 0007257 0007109 3 120 6752 6696 6703 056 049 0008294 0007257 4 120 6752 6699 6704 053 048 000785 0007109 5 120 6752 6699 6705 053 047 000785 0006961 6 120 6752 6698 6704 054 048 0007998 0007109 7 120 6752 6701 6703 051 049...
23396. ПОВЕРКА АВТОМАТИЧЕСКОГО ЭЛЕКТРОННОГО МОСТА 280.87 KB
  Показания Сопротивление Показания образцового Абсолютная погрешность Абсолютная прибора по градуировоч прибора Ом моста Ом вариация оС ной таблице Ом Прямой R1 Обратный R2 Прямой 1 Обратный 2 V Ом 0 46 4561 4556 039 044 005 40 5316 5278 5277 038 039 001 80 60463 5996 5995 0503 0513 001 120 6752 6697 6695 055 057 002 160 7452 7383 7395 069 057 012 200 8143 8075 808 068 063 05 1= Rt– Rt1 ...
23397. Моделювання систем в середовищі MATLAB + Simulink +Stateflow 540.5 KB
  НАВЧАЛЬНОМАТЕРІАЛЬНЕ ЗАБЕЗПЕЧЕННЯ наочні посібники схеми таблиці ТЗН та інше Діапроектор дидактичні слайди НАВЧАЛЬНІ МАТЕРІАЛИ Вступ Моделювання систем в середовищі MATLAB Simulink Stateflow Одной из перспективных концепций в явном или неявном виде реализуемой в настоящее время для решения задач анализа и разработки сложных систем является концепция создания универсальной моделирующей среды. Система моделирования реализующая эту концепцию должна отвечать следующим требованиям: четко выделенная модульность структуры;...
23398. Уніфікована мова моделювання UML 125 KB
  підпис прізвище €œ ____ €œ _____________ 2011 року ЛАБОРАТОРНЕ ЗАНЯТТЯ № 8 з навчальної дисципліни __моделювання комп’ютерних мереж напряму підготовки _______інформаційні технології________ освітньокваліфікаційного рівня ____cпеціаліст_____________ спеціальності _____ ком’пютерні системи та мережі_________ Тема Уніфікована мова моделювання UML повна назва лекції Лабораторне заняття №8 розроблено стар. ПЛАН ПРОВЕДЕННЯ ЗАНЯТТЯ ТА РОЗРАХУНОК ЧАСУ Вступ...