Все статьи

1 Ситуация2 Задача3 Требования4 Решение 4.1 Структура 4.2 Участники и обязательства 4.2.1 FilterManager 4.2.2 FilterChain 4.2.3 FilterOne, FilterTwo, FilterThree 4.2.4 Target 4.3 Стратегии 4.3.1 Стратегия Custom Filter 4.3.2 Стратегия Standard Filter 4.3.3 Стратегия Base Filter 4.3.4 Стратегия Template Filter5 Результаты6 Родственные паттерны


J2EE – большая и сложная спецификация, охватывающая, тем не менее, далеко не все нюансы реализации. Кроме того, многие реализации серверов приложений содержат возможности, выходящие за рамки спецификации. Разработка под конкретный сервер приложений вольно или невольно приводит к тому, что код приложения включает участки, зависимые от этого сервера. Это создает немало проблем при попытке переноса приложения под другой сервер. Spring переносим между разными серверами приложений, и поддерживает WebLogic, Tomcat, Resin, JBoss, WebSphere и другие серверы приложений.


Теперь перейдем к рассмотрению методик работы с SQL-запросами в jstl. Скажу честно и прямо, этот подход ужасен (полагаю, вы все в курсе, что смешивать логику и визуализацию глупо). Хотя этими тегами я иногда пользуюсь для маленьких, секретненьких (никогда ни кому не показываемых) проектиков.


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


Эта статья является логическим развитием материалов посвященных средствам отображения информации (слой View в ставшей уже классической связке Model-View-Controller). Чтобы вы понимали место, которое занимают JSTL и Velocity нужно рассказать о Страшной Ошибке постигшей разработчиков jsp. Как вы наверняка слышали, много-много лет назад java-программисты хотевшие создать веб-приложение не имели в своем распоряжении ничего кроме сервлетов. Сервлет это был класс со специальным методом (doGet или doPost), который вызывался из браузера и должен был сгенерировать html-страницу. Очевидно, что сначала нужно было на основании пришедших от клиента данных (параметры ссылки или содержимое полей формы) выполнить расчет какой-то информации, подготовить набор переменных, массивов, списков и, второй шаг, каким-то образом надо это визуализировать, т.е. перемещать html-теги и те самые подготовленные данные. И было это ужасно:


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


Есть такая замечательная фирма ibm и делает она базу данных cloudscape (вот ее адрес http://www.ibm.com/software/data/cloudscape/). Вообще-то, ibm купила разработчиков cloudscape еще лет 5-ть назад, но сути дела это не меняет. Т.к. база для мира java очень хорошая, и я ей пользовался некоторое время назад.


Если вы переходите в Java с опытом на C++ или C, первое, что бросается в глаза — это настойчивые заявления о том, что здесь "нет указателей". Звучит почти как обещание спокойной жизни: никаких головных болей с разыменованием, утечками памяти и segmentation fault. Но потом вы начинаете писать код и сталкиваетесь с парадоксом: объекты ведут себя как-то... странно. Передаешь объект в метод, меняешь его поля внутри, и изменения сохраняются. Создаешь две переменные, присваиваешь одну другой, и они начинают ссылаться на один и тот же участок памяти. Здравствуй, знакомое чувство!