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

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

Содержание

1. Выбор правильного механизма включения
2. Методика очистки буфера
3. Передача данных между страницами, обрабатывающими один и тот же запрос
4. Выбор между пересылкой и переадресацией
5. Выбор между компонентами Beans и обычными операциями
6. Использование пакетов для классов Bean-компонентов
7. Комбинирование переменных скрипта и переменных области применения
8. Установка свойств для значений нестрочных типов данных
9. Доступ к базе данных
10. Как узнать побольше?

1. Выбор правильного механизма включения
В целях формирования наиболее полного сообщения на поступивший запрос страница JSP может включать в себя фрагменты других файлов. Это можно использовать, например, для того чтобы хранить заголовок, сноски и навигационные ссылки в отдельном файле, чтобы включать их во все остальные страницы. Здесь могут использоваться два механизма включения: директива включения и действие включения. Для каждого частного случая выбирается один из них.

Директива включения (include directive) - <%@ include file="filename.inc" %> - в процессе трансляции (когда сервер конвертирует страницу) включает данные определённого файла. Основная страница и включаемый файл просто "сращиваются". Это означает, что переменные скрипта, объявленные в одном файле (с помощью элементов скрипта или рабочих элементов типа <jsp:useBean>) видны во всех файлах и должны иметь уникальные имена. Некоторые контейнеры обнаруживают изменения в файлах, включаемых с помощью директивы, но спецификация этого не требует. Таким образом, изменения которые вы вносите в файл во время работы системы, могут не сразу проявить себя. Иногда вам придётся обновлять главную JSP-страницу или удалять файл класса, сгенерированный для главной страницы, чтобы увидеть внесённые изменения.

Действие включения (include action), <jsp:include page="pagename.jsp" flush="true" />, в процессе обработки запроса, т.е. когда пользователь обращается к странице, включает сообщение-ответ, генерируемый указанной страницей (JSP-страницей или сервлетом). В отличие от директивы включения, в данном случае имя страницы может указываться как так называемое значение атрибута момента запроса (request-time attribute value), поэтому решение какую страницу включать может быть принято во время запроса к главной странице. Поскольку в этом случае включается генерируемый страницей ответ, а не содержание самой страницы, то переменные скрипта заявленные в одном файле уже не доступны для других файлов. Чтобы объект сталь доступен остальным страницам, вам придётся поместить его в одной из функциональных зон JSP: массиве запросов, сессий или самом приложении. Если вы вносите изменения во включаемую страницу, изменения отражаются немедленно.

Моим главным правилом выбора между этими двумя механизмами является следующее:

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

2. Методика очистки буфера
Сообщение HTTP-ответа содержит заголовки (header) и "тело" (body). Из заголовков браузер получает информацию о типе данных, содержащихся в "теле" сообщения (HTML-текст, изображение и т.п.), объёме данных, могут ли они кэшироваться или нет, и так далее. Заголовки также используются для установки cookies и указания браузеру для автоматического перехода на другую страницу (переадресация). Все заголовки должны поступить в браузер, до того как в него поступит "тело".

Чтобы у частей "тела" была возможность создаться (из статичного шаблонного текста или сгенерироваться динамично элементами JSP), до того как будут установлены заголовки, "тело" загружается в буфер. Вместо того чтобы отправлять в браузер данные по мере того, как "тело" формируется, контейнер JSP записывает весь статичный разметочный код и всё динамичное содержание, сгенерированное элементами JSP в буфер. В какой-то момент, например, когда буфер заполняется или страница заканчивается, контейнер отсылает все уже установленные заголовки и вслед за ними хранящееся в буфере содержание "тела". Если рассуждать терминами сервлетов, эта операция называется выполнением ответного действия. После того как это действие выполнено, вы уже не сможете переустановить заголовки, например, для cookies или инструкций переадресации. И ещё вы не сможете перенаправить запрос к другой странице.

В большинстве случаев это не вызывает особых проблем. По умолчанию размер буфера составляет 8КВ, что более чем достаточно для стандартной страницы. Хотя вы можете увеличить размер с помощью атрибута buffer директивы page. Но, если вы используете в своей странице действие включения, то вас может ожидать сюрприз. Из-за ограничений в порядке определения используемых действием <jsp:include> функций сервлета, буфер всегда "опорожняется" прежде, чем вы инициируете нужную страницу. Это значит, что установить заголовки или воспользоваться <jsp:forward> после действия <jsp:include> вы не сможете.

Неприятным побочным эффектом такой чистки может быть то, что ошибки выполнения программы, вызываемые JSP-элементами после действия <jsp:include> не всегда корректно докладываются, поскольку многие JSP-контейнеры используют для отображения страницы с сообщением об ошибке (error page) механизм пересылки (forward mechanism). Если вы увидите на странице с элементами <jsp:include> сообщение об ошибке типа "response already committed", я советую вам в этом случае использовать директиву включения (по крайней мере, до тех пор пока вы не установите причину проблемы).

3. Передача данных между страницами, обрабатывающими один и тот же запрос
Очень часто один и тот же запрос может обрабатываться несколькими JSP-страницами. Например, когда вы используете действие включения для включения стандартной навигационной панели во все страницы. Или, к примеру, когда вы используете одну страницу для обработки запроса (проверки вводимой информации или обращения к базе данных) и затем действие переадресации <jsp:forward page="pagename.jsp" />, чтобы заставить другую страницу сгенерировать ответное сообщение. Эти два способа применяются для передачи данных от одной странице к другой, при этом мы используем параметры и атрибуты запроса.

Прежде всего, страница, инициированная с помощью действий <jsp:include> или <jsp:forward>, получает доступ ко всем параметрам HTTP-запросов, поступивших к первой странице. Кроме того, вы можете указать новые параметры запроса с помощью вложенных действий <jsp:param>:

<jsp:forward page="login.jsp"> 
  
 <jsp:param name="errMsg" 
   value="The name 
or password is not valid" /> 
</jsp:forward>

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

Параметры запроса могут хранить только строковые значения. Если вам нужно передать объект, скажем, UserInfoBean с различными информативными свойствами, вам придётся передавать его как атрибут запроса (или как бин-компонент сессии или приложения, но об этом не сейчас). Атрибут запроса представляет собой то же, что и объект приложения, так что первая страница может создать это объект и установить все его свойства с помощью действий <jsp:useBean> и <jsp:setProperty>:

<jsp:useBean id="userInfo" scope="request"
    class="com.mycompany.UserInfoBean">
    <jsp:setProperty name="userInfo" property="*" 
/>
</jsp:useBean>
...
<jsp:forward page="nextpage.jsp" 
/>

Чтобы использовать такой бин-компонент в странице, инициируемой с помощью <jsp:forward> или <jsp:include>, вы должны также воспользоваться действием <jsp:useBean> и в инициируемой странице. Кроме того, бин, созданный первой страницей, может располагаться и ассоциироваться с определённым id. Затем он может использоваться сценарным кодом или другими действиями, к примеру, <jsp:getProperty>, в новой странице:

<jsp:useBean id="userInfo" scope="request" 
  class="com.mycompany.UserInfoBean" /> 
<jsp:getProperty name="userInfo" property="firstName" 
/>

4. Выбор между пересылкой (Forward) и переадресацией (Redirect)
Если вы захотите передать процесс управления от одной страницы другой, вы можете либо переслать его другой странице, как это было описано выше, либо переадресовать новой странице (с помощью метода sendRedirect() объекта, выступающего в качестве имплицитного ответа).

Между пересылкой и переадресацией существует серьёзная разница. Когда вы выполняете пересылку, нужная нам страница инициируется JSP-контейнером с помощью внутреннего вызова метода. Новая страница продолжает обрабатывать тот же самый запрос, а браузер даже не догадывается о том, что в этом процессе задействовано несколько страниц. Переадресация, в свою очередь, означает то, что первая страница требует от браузера сделать новый запрос к нужной странице. Таким образом, URL, указанный в браузере, будет заменён URL новой страницы, на которую нас переадресовали, чего не происходит при пересылке. Переадресация медленнее, чем пересылка, поскольку браузер вынужден повторять свой запрос. Второе отличие состоит в том, что объекты функциональной области запроса после переадресации становятся недоступными, так как вы создаёте новый запрос. Если вы хотите передать данные странице, на которую вы переадресованы, вам придётся использовать строку запроса и передать данные как параметры (или сохранить их как объекты функциональной зоны приложения).

Что в таком случае выбрать - пересылку или переадресацию? Я думаю так: пересылка всегда быстрее, поэтому предпочтение стоит отдать ей. Но, поскольку URL в браузере продолжает указывать на первую страницу даже после пересылки, я задаю себе вопрос: а что случиться, если пользователь перезагрузит страницу (или хотя бы изменит размер окна, что автоматически перезагружает страницу)? Если первая страница является страницей, которая обновляет какую-то часть информации, вроде добавления предмета в корзинку для покупок или ввода данных в базу данных, мне вовсе не нужно, чтобы она снова вызывалась при перезагрузке. Для отражения обработанного результата мне в этом случае больше подойдёт переадресация с сообщением о подтверждении.

5. Выбор между компонентами Beans и обычными операциями
В JSP 1.0 компоненты JavaBeans являлись единственным типом компонентов, которые можно было использовать для инкапсулирования Java-кода и инициации работы стандартных операционных элементов JSP типа <jsp:getProperty> и <jsp:setProperty>. В инструментальном компонентном наборе JSP 1.1 появились элементы обычных операций (custom action). Java-класс, получивший название обработчика меток (tag handler), реализует поведение обычных операций. В наиболее простом своём виде это обычный класс JavaBeans, имеющий методы обращения к свойствам, соответствующие элементам обычных операций, плюс несколько дополнительных методов, используемых контейнером для инициации самого обработчика (чтобы он мог выполнять свою функцию). Обработчики меток, которые должны обрабатывать содержание элементов или создавать объекты для переменных скрипта, требуют более кропотливой разработки, но пугаться этого не стоит. Приводить детальное описание в этой статье, наверное, не стоит. Все подробности можно найти в моей книге, где разработке обработчиков обычных операций посвящены две главы.

Опять же сделать выбор в пользу бин-компонента или обычной операции в процессе разработки достаточно сложно. Моим первым правилом здесь является следующий факт: бин служит прекрасным носителем информации, а обычная операция отлично справляется с обработкой этой информации. Операции могут использовать бин-компоненты в качество входных и выходных данных. К примеру, с помощью действия <jsp:setProperty> вы можете использовать бин для отлова форматированных входных данных, а затем обычную операцию для сохранения свойств бина в базе данных. То же самое в обратном порядке также является хорошим примером: вы извлекаете данные из базы с помощью обычной операции, которая превращает их в бин и делает доступными для страницы.

6. Использование пакетов для классов Bean-компонентов
Когда вы создаёте бин-компонент, который будет использоваться в JSP-странице, рекомендую сделать его частью указанного пакета. Java-класс, не использующий утверждение package, заканчивает свою работу в так называемом безымянном пакете (unnamed package). Класс сервлета, сгенерированный JSP-страницей, не смотря на это, обычно приписывается к указанному пакету. Если вы попытаетесь сослаться на класс в безымянном пакете из класса в указанном пакете, Java не сможет найти этот класс, пока вы не воспользуетесь утверждением импортирования для импорта класса. Для JSP-страницы это будет означать, что вы должны использовать и директиву page для импортирования класса, и действие <jsp:useBean>, чтобы сделать его доступным:

<%@ page import="UserInfoBean" %> 
<jsp:useBean id="userInfo" class="UserInfoBean" />

Если бин становится частью указанного пакета, то вам хватит одного действия <jsp:useBean>:

<jsp:useBean id="userInfo" 
  
class="com.mycompany.UserInfoBean" />

7. Комбинирование переменных скрипта и переменных функциональной области
Мой самый главный совет заключается в том, чтобы избегать вложения Java-кода в JSP-страницы. Наличие кода в элементах сценария может привести к проблемам с поиском синтаксических ошибок, а также сложностям с поддержкой и обслуживанием самого Web-приложения. Одной из специфических проблемных областей одновременного использования Java-скриплетов и операционных элементов JSP является ситуация, в которой переменные сценария и объекты, созданные операционными элементами в функциональной зоне JSP, взаимодействуют друг с другом. Или, вернее, не взаимодействуют. Рассмотрим следующий пример:

 <jsp:useBean id="userInfo" 
    
class="com.mycompany.UserInfoBean" >
 <jsp:setProperty name="userInfo" property="firstName" 
/>
 </jsp:useBean>
 <%
    userInfo = new 
com.mycompany.UserInfoBean();
 %>
 <jsp:getProperty 
name="userInfo" property="firstName" />

Экземпляр UserInfoBean, создаётся действием <jsp:useBean> в функциональной зоне (по умолчанию), а его свойство firstName придаётся значению, передаваемому в качестве параметра запроса с тем же именем. Это же <jsp:useBean> также даёт возможность обращаться к бину как к переменной скрипта с таким же именем, что и у переменной функциональной зоны (в данном случае userInfo). Затем скриплет создаёт новый экземпляр класса UserInfoBean и приписывает его к сценарной переменной userInfo. И наконец, действие <jsp:getProperty> извлекает значение свойства firstName бин-компонента. Но которым из экземпляров UserInfoBean пользуется действие <jsp:getProperty>? Отвечаю: тем, который доступен из функциональной зоны страницы. Действие <jsp:getProperty> или любой другой операционный элемент не могут использовать переменную скрипта. Доступными для них будут только объекты, расположенные в одной их стандартных функциональных зон JSP: странице, запросе, сессии и приложении. Если вам нужно использовать элементы скрипта для создания объектов, которым вы хотите затем предоставить доступ к действиям, вы должны будете поместить их в соответствующую зону:

... 

<%
  
userInfo = new com.mycompany.UserInfoBean();
 pageContext.setAttribute("userInfo", userInfo);
%> 
<jsp:getProperty 
name="userInfo"
   property="firstName" 
/>

В этом примере метод setAttribute() используется для замены объекта из функциональной зоны страницы экземпляром, созданным скриплетом. Таким образом, действие <jsp:getProperty> и находит этот новый экземпляр.

8. Установка свойств для значений нестрочных типов данных
Свойства бин-компонентов, как вы наверное знаете, представлены методами доступа: методом установки (setter) для прописных свойств и методом извлечения (getter) для читаемых свойств. Информативным типом свойства является одиночный аргумент метода установки и возвратный тип метода извлечения.

Действие <jsp:setProperty> обычно используется для установки свойства бина соответственно значению параметров запроса. Параметры запроса передаются в виде строки строк. Что же происходит, если свойства бин-компонента имеют типы, отличные от String? JSP-контейнер вполне успешно конвертирует строковые значения в традиционные для Java информативные типы, как это показано в таблице ниже:

Тип свойства	Метод конверсии
`boolean` или `Boolean`	`Boolean.valueOf(String)`
`byte` или `Byte`	`Byte.valueOf(String)`
`char` или `Character`	`String.charAt(int)`
`double` или `Double`	`Double.valueOf(String)`
`int` или `Integer`	`Integer.valueOf(String)`
`float` или `Float`	`Float.valueOf(String)`
`long` или `Long`	`Long.valueOf(String)`

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

<jsp:setProperty name="userInfo" property="empDate" 

   value='<%= new 
      java.util.Date(request.getParameter("empDate")) %>' 
/>

Обращаем ваше внимание, что данный пример использует неразрешённый конструктор Date и незащищён от ошибок (он не работает, если параметр empDate пропущен или не содержит правильно созданную дату). Я воспользовался им исключительно для иллюстрации возможности установки атрибута или типа данных, не имеющего поддерживаемого JSP правила конверсии, как класс Date, использованный здесь.

Правила для свойств бина, устанавливаемых с помощью <jsp:setProperty> и описанные выше, также применимы и к атрибутам обычных операций.

9. Доступ к базе данных
Один из наиболее часто задаваемых вопросов о работе почтовика JSP-INTEREST от Sun Microsystem касается проблемы доступа к базе данных из JSP-страницы. К сожалению, описание этой процедуры также выходит за рамки данной статьи. Но несколько пояснений я всё же дать могу.

JSP - это Java. И значит, как и во всех Java-программах, для доступа к базам вам нужно использовать JDBC. О самом JDBC вы можете прочитать в JDBC API.

Я бы рекомендовал не выкладывать код доступа к базе данных непосредственно в JSP-страницу. Вместо этого создайте бин-компонент или обычное действие, которые и будут выполнять чёрную работу. В моей книге приводится перечень обычных действий для доступа к базе данных, которыми вы можете воспользоваться, а также множество примеров их применения (см. пункт 10 данной статьи). Для сложных приложений вам, возможно, понадобится сервлет, способный обращаться к базе и пересылать запрос к JSP-странице, которая занимается простой обработкой и отображением результата. Такая модель обычно называется Model-View-Controller (MVC) или Model 2 (термин, введённый в предварительном релизе спецификации JSP). Примеры для этой модели тоже есть в моей книге. Кроме того, дополнительную информацию о MVC можно почерпнуть из материалов Apache Struts project.

Доступ к базе данных традиционно достаточно ресурсоёмкая процедура. Вам нужно использовать накопитель соединений (connection pool), также описанный в книге, чтобы грамотно распределять связи с базой между всеми запросами. Ещё одним способом экономии ресурсов является кэширование результатов запросов к базе данных, если это возможно. В большинстве случаев информация, хранимая в базе данных, меняется не очень часто. Для такой разновидности данных вы можете скачать информацию однажды и сохранить её как объект функциональной зоны приложения, к которому имеют доступ все пользователи. Если вдруг эта информация обновилась, просто замените этот объект новой версией. Другим способом кэширования редко обновляющихся данный может быть объект сессионной функциональной зоны. Пользователь видит объект таким, каким он был в начале сеанса. Изменения, произошедшие в процессе сеанса, ему не видны. Если вы захотите воспользоваться этой стратегией, зразу позаботьтесь о том, чтобы размер памяти, отведённой под кэш (одна копия на один сеанс), достаточен, чтобы обеспечить необходимый вам результат. Обычно оно того стоит при условии, что у вашего сервера хватит памяти, чтобы справиться с перепадами.

Если вы решите использовать кэш, не берите в качестве кэш-объекта сам объект ResultSet из JDBC. Он тесно привязан к специфическим видам соединений, в силу чего конфликтует с накопителем. Вместо этого скопируйте данные из ResultSet в специальный бин вашего приложения, к примеру, в Vector или что-нибудь такое.

10. Как узнать побольше?
Надеюсь в этой статье я смог познакомить вас с наиболее нужными в разработке JSP-приложений вещами. Но, естественно, это не всё, что вам нужно знать об этой технологии. Для этого я рекомендую вам прочесть мою книгу JavaServer Pages (O'Reilly). К тому же, большое количество информации можно почерпнуть из Интернета. Лучшим источником в этом отношении является Sun's JSP page. Здесь вы сможете найти спецификацию JSP, статьи и туториалы, написанные Sun, а так же море полезных ссылок на сайты и продукты, относящиеся к работе с JSP.

Об авторе
Hans Bergsten работает программистом уже более двадцати лет. Своё первое приложение для базы данных он создал за несколько лет до того, как SQL стал общепринятым языком баз данных. Он занялся изучением Java сразу, как только появились первые публикации в 1995 году. В 1997 Ханс создал компанию Gefion software для воплощения своих идей по проблемам разработки сетевых, платформенно-независимых программных систем. В это время были созданы LiteWebServer и JSP-библиотека InstantOnline . Ханс принимал участие в работах исследовательских групп Java Servlet API и JavaServer Pages (JSP), а также внёс свой вклад в разработку версий Apache Tomcat для обеих спецификаций, будучи членом Проектного Коммитета Apache Jakarta. Кроме того, что он является автором JavaServer Pages (O'Reilly), он регулярно пишет статьи для сайтов и журналов и является одним из авторов известного Professional Java Server Programming (Wrox).

HTML 5: пять вещей вызывающих особый интер....

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

Элемент управления ListView был представлен в .Net Framework 3.5 как замена устаревшему GridView. Новый элемент имеет более расширенный функционал, чем его предшественник, но в тоже время лишен некоторых внутренних механизмов, что впрочем целиком следствие из расширенной универсальности ListView. Среди отличий ListView и GridView можно назвать и гибкую настройку разметки, что позволяет выводить данные не только в табличном виде, но и вообще в любом каком пожелает программист. Благодаря шаблонам ItemTemplate, EditItemTemplate, InsertItemTeplate можно настроить внешний вид при любом из состояний ListView: редактировании или выборе элемента.

Компания Стимулсофт предоставляет для разработчиков мощный набор инструментов для создания отчетов для Microsoft Visual Studio .Net 2005 и 2008; эти инструменты доступны как для Windows Forms, так и для Web Forms. Это генератор отчетов Stimulsoft Reports.Net. Генератор отчетов Stimulsoft Reports.Net имеет ряд особенностей: простая работа с дизайнером отчетов, полная поддержка экспорта в PDF, Word, Excel и многие другие форматы. Crystal Report и Microsoft Reporting Service – очень хорошие программные продукты для повседневной работы, но, если Вам необходимо создать отчеты с поддержкой кросс-табов, drill down, Ajax, штрих-кодов и возможностью подключения одновременно более одного источника данных, то Stimulsoft Reports.Net поможет Вам сэкономить массу времени. Также, данный генератор отчетов позволяет пользователям создавать свои собственные отчеты любой сложности. И все эти особенности делают Stimulsoft Reports.Net хорошим выбором в сфере программных продуктов для Business Intelligence.