Что такое JSP?

Технология Java Server Pages (tm) (JSP) позволяет разработчикам и дизайнерам web-приложений быстро разрабатывать и легко сопровождать web-страницы с динамическим наполнением информацией. Но описание практически каждой технологии подобного назначения (ASP, PHP, Net.Data) сопровождают подобные слова -- быстро и легко ...

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

Сначала простое перечисление:

• действительно высокая межплатформенная переносимость; использование универсального языка высокого уровня Java в качестве скриптового;
• JSP -- это не какое-то отдельно стоящее средство для решения достаточно узкого круга задач, пусть и достаточно мощное, а ещё одно в ряде целой плеяды технологий, объединяемых Java;
• реальная возможность разделить задачи написания бизнес-логики web-приложения и пользовательского интерфейса, что позволяет разрабатывать и сопровождать различные части проекта независимо;

Технология JSP является прямым расширением ещё одной Java-технологии -- Servlets (tm) а также тесно связана с технологией Java Beans (tm) и использует XML-подобные теги (tags) и скриптлеты (scriptlets), написанные на языке программирования Java для введения логики создания динамического наполнения web-страницы, при этом HTML или XML-теги передаются клиентской стороне напрямую. Количество тегов достаточно невелико, что упрощает начальное освоение данной технологии; впрочем, для простых вещей та же Net.Data или PHP тоже весьма просты. Как водится, рассмотрим примитивный случай класса Hello World!

Подключение Java-программы к реляционной СУБД с помощью JDBC выполняется в три этапа:

1. Установка связи между Java-программой и диспетчером базы данных.
2. Передача SQL-команды в базу данных с помощью объекта Statement.
3. Чтение полученных результатов из базы данных и использование их в программе.

Рассмотрим эти три этапа.

Работа с классом DriverManager

Пакет JDBC предназначен для работы с разнообразными диспетчерами СУБД от различных разработчиков. Для подключения к базе данных среда выполнения Java должна загрузить соответствующий драйвер указанной базы данных. Загрузка и выгрузка таких драйверов осуществляется с помощью класса DriverManager.

На рисунке показана схема подключения Java-программы к базе данных. Класс DriverManager имеет структуру данных, которая содержит как сами драйверы в виде объектов Driver, так и информацию о них.

Загрузка драйверов

Драйверы JDBC обычно создаются поставщиками СУБД. Их работа заключается в обработке JDBC-подключений и команд, поступающих от Java-приложения, и в генерации машинно-зависимых вызовов по отношению к базе данных.

Далеко не все поставщики СУБД предлагают драйверы JDBC, но как правило ими всегда поставляются драйвера ODBC (Open Database Connectivity), которые удовлетворяют стандарту Microsoft. При работе с СУБД на платформе Windows поставщик используемой СУБД почти всегда предлагает собственный драйвер ODBC. По этому проблем с подключением Java-приложения к базе данных в среде Windows обычно не возникает, чего, к сожалению, нельзя сказать о других платформах.

Предварительная загрузка драйвера

Загрузка драйвера может производиться как из программы, так и из командной строки.

Для загрузки драйвера-моста JDBC-ODBC из командной строки необходимо ввести следующую команду:

Java -Djdbc.drivers=sun.odbc.JdbcOdbcDriver MyApplication

Для загрузки драйвера-моста JDBC-ODBC из программы:

try
{
 Class theDriver = sun.odbc.JdbcOdbcDriver.class;
}
catch(ClassNotFoundException e)
{
 System.err.println("Драйвер JDBC/ODBC не найден");
}

Использование класса Connection

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

Connection myConnection = DriverManager.getConnection(
"jdbc:odbc:mydataSource",
"username",
"password");

После получения запроса getConnection() диспетчер драйверов анализирует значение адреса URL для JDBC и, в свою очередь, передаёт его каждому зарегистрированному драйверу. Затем подключение будет установлено с помощью того драйвера, который первым опознает данный адрес URL для JDBC и сообщит о готовности к подключению. Если ни один из драйверов не сможет опознать URL для JDBC, диспетчер драйверов инициирует обработку исключительной ситуации SQLException с выдачей сообщения об отсутствии подходящего драйвера (No suitable driver).

Объект Statement

Объект Statement предназначен для хранения SQL-команд. При пересылке объекта Statement базе данных с помощью установленного подключения СУБД запустит заданную SQL-команду и возвратит результат её выполнения в виде объекта ResultSet.

Методы объекта statement заключаются внутри конструкции try{…} catch.

Для извлечения результатов запроса в виде объекта ResultSet следует использовать приведённый код:

ResultSet theSet = theStatement.executeQuery("SELECT * FROM *");

или

ResultSet theSet;
if(theStatement.execute("SELECT * FROM *")) 
theSet = theStatement.getResultSet();

Условная компиляция достаточно полезная вещь, с этим, наверное, никто спорить не будет. Иметь возможность собирать разные версии приложения без изменений исходных текстов очень удобно. Условная компиляция есть в С/С++, в VB и еще наверно не в одном языке программирования. Но ее нет почему-то в Java. Может этому есть разумное объяснение, а может и нет. В любом случае лучше иметь этот инструмент в языке, а уж разработчики сами решат, пользоваться им или нет.

Одним из способов отладки Java (да вообще-то любых) программ, как известно, является добавление в код функций трассировки:

void f(...) {

        try {

            System.out.println("job started");

            some_job();

            System.out.println("job OK");

        } catch(...) {

            System.out.println("job FAILED");

        }

    }

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

Зачем нужно конфигурирование?

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

Есть и другая крайность - когда практически всё выносится в настройки. Такие программы напоминают разлитую жидкость, а чтобы заставить её работать надо прочитать талмуд описания и настроить несколько сотен параметров, к тому же часто взаимосвязанных противоестественным образом.

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

---

Что именно стоит настраивать.

Вот типичные примеры данных, которые часто стоит вынести в настройки:

• Всевозможные каталоги. Например - пути до файлов данных, каталоги импорта/экспорта.
• Сетевые настройки. Имена серверов, IP-адреса, порты, имена и пароли для автоматического доступа.
• Настройки баз данных. Имена JDBC-драйверов, URL базы данных, SQL-запросы, зависимые от используемой БД.
• Настройки внешнего вида. Настройки Swing-овского Look & Feel-а, используемые шрифты, размеры, цвета, настройки горячих клавиш.
• Прочее... Любые другие вещи, которые могут менятся от пользователя к пользователю.

Например, довольно часто встречаемая ситуация - настройка соединения с БД. Начинающие программисты часто пишут нечто подобное:

Class.forName("sun.jdbc.odbc.JdbcOdbcDriver");

Connection con = DriverManager.
 getConnection("jdbc:odbc:MyDatabase",user,password);

Таким образом программа привязывается к конкретному JDBC драйверу. Использовать другой драйвер, например заменить мост на RMI-прокси или, в случае Oracle, OCI на Thin без перекомпиляции уже нельзя.

---

Способы хранения настроек.

В объектном программировании всё представляется в виде объектов. Настройки лучше всего при этом рассматривать как свойства определённых объектов, которые хранятся в файлах конфигураций. То, каким образом эти настройки считываются и записываются тесно взаимосвязано с форматом файлов и выбраной стратегией администрирования. Рассмотрим идеальный вариант:

1. Настраиваемый объект не должен содержать знаний о формате файлов и способе чтения/записи. Это позволило бы, в случае необходимости, заменить один способ другим.
2. Большинство настроек должны выполняться при помощи программы (подпункт меню или отдельная программа настройки). Это сильно облегчает жизнь человека, который занимается администрированием. У большинства "юниксоидов" это может вызвать непонимание :-), но редактированием текстовых файлов в современном мире во многих случаях не обойтись.
3. Должно быть установлено разумное умолчание для отсутствующих параметров. Другими словами - необходимо, чтобы большинству пользователей для запуска программы нужно было бы сделать минимум настроек. Как правило это оставляет благоприятное первое впечатление о программе, а часто именно оно - самое важное.

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

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

Разумное же умолчание для параметров часто просто невозможно представить. Например, что поставить в качестве имени SMTP-сервера? В случае Unix-систем можно попробовать поставить localhost, но для Windows-мира это редко кому подойдёт.

Рассмотрим наиболее распространённые варианты:

Введение

Некоторые проблемы настолько сложны, что нужно быть очень умным и очень хорошо информированным, чтобы не быть уверенным в их решении. Лоренс Дж. Питер Peter's Almanac

Кодировки

Когда я только начинал программировать на языке C, первой моей программой (не считая HelloWorld) была программа перекодировки текстовых файлов из основной кодировки ГОСТ-а (помните такую? :-) в альтернативную. Было это в далёком 1991-ом году. С тех пор многое изменилось, но за прошедшие 10 лет подобные программки свою актуальность, к сожалению, не потеряли. Слишком много уже накоплено данных в разнообразных кодировках и слишком много используется программ, которые умеют работать только с одной. Для русского языка существует не менее десятка различных кодировок, что делает проблему ещё более запутанной.

Откуда же взялись все эти кодировки и для чего они нужны? Компьютеры по своей природе могут работать только с числами. Для того чтобы хранить буквы в памяти компьютера надо поставить в соответствие каждой букве некое число (примерно такой же принцип использовался и до появления компьютеров - вспомните про ту же азбуку Морзе). Причём число желательно поменьше - чем меньше двоичных разрядов будет задействовано, тем эффективнее можно будет использовать память. Вот это соответствие набора символов и чисел собственно и есть кодировка. Желание любой ценой сэкономить память, а так же разобщённость разных групп компьютерщиков и привела к нынешнему положению дел. Самым распространённым способом кодирования сейчас является использование для одного символа одного байта (8 бит), что определяет общее кол-во символов в 256. Набор первых 128 символов стандартизован (набор ASCII) и является одинаковыми во всех распространённых кодировках (те кодировки, где это не так уже практически вышли из употребления). Англицкие буковки и символы пунктуации находятся в этом диапазоне, что и определяет их поразительную живучесть в компьютерных системах :-). Другие языки находятся не в столь счастливом положении - им всем приходится ютиться в оставшихся 128 числах.

Unicode

В конце 80-х многие осознали необходимость создания единого стандарта на кодирование символов, что и привело к появлению Unicode. Unicode - это попытка раз и навсегда зафиксировать конкретное число за конкретным символом. Понятно, что в 256 символов тут не уложишься при всём желании. Довольно долгое время казалось, что уж 2-х то байт (65536 символов) должно хватить. Ан нет - последняя версия стандарта Unicode (3.1) определяет уже 94140 символов. Для такого кол-ва символов, наверное, уже придётся использовать 4 байта (4294967296 символов). Может быть и хватит на некоторое время... :-)

В набор символов Unicode входят всевозможные буквы со всякими чёрточками и припендюльками, греческие, математические, иероглифы, символы псевдографики и пр. и пр. В том числе и так любимые нами символы кириллицы (диапазон значений 0x0400-0x04ff). Так что с этой стороны никакой дискриминации нет.

Если Вам интересны конкретные кода символов, для их просмотра удобно использовать программу "Таблица символов" из WinNT. Вот, например, диапазон кириллицы:

Если у Вас другая OS или Вас интересует официальное толкование, то полную раскладку символов (charts) можно найти на официальном сайте Unicode (http://www.unicode.org/charts/web.html).