Большинство из них делятся на: тупые, совсем тупые, не для людей, с невероятно странной логикой, слишком сложные и запутанные.

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

Приведу пример, пусть ваш месячный доход (допустим зарплата) составляет 10 000 грн. Как правило, между получением этого дохода проходит месяц, что в системе можно легко настроить. Однако после внесения этой суммы в качестве регулярного дохода она будет поделена на 4 недели, что само по себе меньше! В итоге, в остатке у вас будет написана сумма ≈ 9333 исходя из которой будут рассчитаны все 4 конверта на месяц в перёд.

Лично меня такой подход в корне не устраивает. Я хочу видеть всю сумму, текущий остаток (хотя в последней версии это таки было интегрировано) и оперировать финансами не привязываясь к “конвертам”, а исходя из расчета финансов на месяц вперёд.

Вот несколько критериев:

• Мой расчетный период ровно месяц, а не неделя
• Даже если поступает доход в середине месяца он всё равно попадает на общий месячный баланс
• Если я формирую финансовую цель, значит я изначально знаю какую сумму откладывать ежемесячно. Я не откладывю “понедельно” по 478 грн. 66 коп.
• У меня есть регулярные траты (например оплата коммунальных услуг, интернет и т.д.), которые не привязаны конкретно к первой или второй неделе месяца. Эти траты просто существуют и сумма на них перманентно выделяется в самом начале (тут даже планировать нечего, эту сумму нужно просто вычесть!).

Исходя из всего этого, сформирую список требований к системе, которой бы я хотел пользоваться:

• Хочу заносить дневные траты автоматически. Например, просто сканируя чек своим мобильным телефоном.
• Подстройка логики учета финансов под отдельно взятую ситуацию.
• Возможность отклаывать на финансовые цели не привязываясь к дате. Захотел в начале месяца всю сумму, захотел 4 раза по разу в неделю – пожалуйста.
• Интеграция с платежными системами и с моей платежной карточкой.
• Работа параллельно с несколькими счетами.
• Настройка финансовых инструментов. Например есть у вас депозит приносящий определенный процент в месяц или акции или недвижимость. Было бы здорово подстроить под это отдельный счет, который будет автоматически пополняться.
• Различные виды отчетов. Детализация по категориями трат.
• Умный планировщик/помощник, помогающий оптимизировать траты.

И завернуть всё это в интуитивно понятный и удобный интерфейс.

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

В старой версии проекта использовался пресловутый JdbcTemplate и URL коннекта прописывался непосредство в XML конфиге Spring’а.

Однако, какой смысл использовать это неповоротливое, в плане масштабируемости решение, если мы переводим весь проект на могучий Glassfish, где есть удобная в настройке поддержка JNDI ресурсов и пулов, и даже контроль транзакционности “из коробки”.

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

applicationContext.xml:

Далее, необходимо объявить ссылку на указанный выше ресурс в веб дескрипторе, если мы хотим использовать пространство java:comp/env.

web.xml:

Последнее на уровне конфигурации, что прийдется сделать — это создать специальный дескриптор для Glassfish в папке WEB-INF.

sun-web.xml:

Далее конфигурируем Glassfish. Для этого понадобиться сделать 2 вещи.

Скачиваем MySQL Connector/J, распаковываем и копируем mysql-connector-java-x.x.x-bin.jar в папку домена Glassfish ./domain1/lib/ext.

Перезапускаем сервер.

Далее идём в консоль Glassfish по пути Resources->JDBC-> Connection Pools и создаём новый пул, при этом Resource Type выбираем javax.sql.DataSource, Database Vendor: MySQL соответственно. Жмём Next и на следующей страничке выбираем Datasource Classname: com.mysql.jdbc.jdbc2.optional.MysqlDataSource.

В параметрах указываем, User, Password, ServerName, Port. Это то, что необходимо указать обязательно и о чем пишется в любом QuickStart Guide.

Однако, о чем умалчивает документация — это о том, что также нужно руками прописать URL и Url, что представляет собой стандартную запись урлы коннекшены. По крайней мере, у меня всё заработало только после того, как я прописал эти параметры.

Последним шагом заходим в JDBC Resources и создаём новый ресурс с именем, которое соответствует указанному в конфиге sun-web.xml.

Рестартуем приложение из админ-консоли Glassfish, и вуа-ля, всё работает.

Существует такой термин — I.N.V.E.S.T.

Данная аббревиатура состоит из первых букв шести принципов, которым стоит придерживаться при создании новой User Story:

• Independent (Независимая)
  Каждая новая User Story должна быть максимально независима от других (на сколько это возможно). Зависимости между историями делают их планирование, приоритизацию и оценку более сложными. Чаще всего, зависимостей между User Story можно избежать засчет объединения историй в одну или же разбиения на более мелкие.
• Negotiable (Подверженная изменениям/обсуждению)
  Истории нужно обсуждать и изменять если это необходимо. “Карточка” с User Story — это всего лишь краткое описание истории, которое не содержит деталей. Детали, как правило, прорабатываются на стадии обсуждения. Однако, не стоит забывать, что избыточное количество деталей может ограничивать общение с заказчиком в процессе разработки.
• Valuable (Полезная)
  Каждая, отдельно взятая история, должна приносить определенную пользу (будь-то пользователь или заказчик). Самый надежный способ сделать историю полезной — это заставить заказчика написать её. Как только заказчик осознает, что User Story это не окончательный документ на подпись, и что User Story можно обсуждать и менять, он будет чувствовать себя комфортнее при её написании.
• Estimable (Поддающаяся временной оценке)
  Разработчики должны иметь возможность оценивать истории, тем самым позволяя расставить приоритеты на итерацию. Проблемы, которые могут помешать разработчикам выполнить оценку истории: отсутствие понимания бизнес процессов (в этом случае необходимо выделять больше времени на обсуждение историй); или же история слишком большая (в этом случае требуется разбиение на более мелкие истории).
• Small (Небольшая)
  Хорошая User Story должна быть проста в реализации, обычно представляющая не более 1-й человеко/недели реализации. История, для реализации которой требуется больше времени может содержать больше ошибок связанных с масштабированием и оценкой.
• Testable (Тестируемая)
  User Story должна поддаваться тестированию. Главное помнить, мы не разрабатываем ничего что нельзя протестировать. Если вы не можете протестировать историю, вы никогда не сможете сказать готова ли она.Пример истории не поддающейся тестированию: “Программа должны быть простая в использовании”.

Источник: http://agilesoftwaredevelopment.com

Не так давно я выложил первую версию своего плагина для работы с закладками Delicious.com для браузера Google Chrome. Неожиданно для меня плагин получил довольно большое одобрение со стороны пользователей Chrome, не смотря на то что первая версия была ни на что не похожа.

За три месяца плагин приобрел собственный логотип, который представляет собой смесь концепции логотипа Delicious.com и цветов логотипа Google Chrome, достаточно подходящее название, которое было предложено одним из пользователей, а также оброс более богатой функциональностью.

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

И так, что же нового:

• Поиск закладок теперь не case-sensitive
• Поиск закладок стал значительно быстрее и продвинутей
• Добавилась возможность фильтровать закладки по тэгам
• Исправлен дефект связанный ошибочным срабатыванием горячих клавиш
• Значительно улучшен интерфейс

Что одидается в следующей версии:

• Поддержка эккаунтов Yahoo ID!
• Выделенный текст на странице будет подставляться в описание закладки
• Просмотр тэгов отдельно для каждой закладки
• Будут добавлены favicon в списке отображения закладок

Официальный сайт: http://thedeliciouschrome.com

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

Вторая стадия – испытаний и опытов. С целью подтвердить явление проводится ряд экспериментов, в ходе которых накапливаются знания и необходимые научные обоснования для построения полной доказательной базы с целью объяснить явления с научной точки зрения.

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

А теперь давайте посмотрим на современные методологии разработки программного обеспечения с научной точки зрения. Становится очевидно, что Agile методологии находятся на второй стадии научного обоснования. Существует множество экспериментов, причем достаточно успешных, множество практик и теорий, однако не существует полного научного обоснования доказывающего эффективность этих подходов.

И конечной формулы нет. В сумме мы имеем набор гибких практик об эффективном взаимодействии людей в команде, но не процессов, в связи с чем доказать это не возможно. Agile – это больше о психологии, а не о практике разработки ПО.

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

А теперь о неприятном

Цель любой методологии (а в данном случае Agile), чем бы она не была обоснована – сократить риски и затраты на выполнение задачи с целью оптимизации производства любыми доступными средствами. И вот тут кроется большой подводный камень для разработчиков.

Понятие минимизации рисков достаточно обширное, однако давайте рассмотрим его с точки зрения обычного разработчика.

Понятие минимизации рисков для конечного(низшего) уровня в большой бизнес-иерархии, уровня разработки, сводится к “дроблению” технических задач до настолько мелких, что в конечном счете от одного взятого разработчика как единици рабочей сили в целом для процесса ничего не зависит.

Чем это грозит отдельно взятому разработчику? По сути ничем. Вы такой же исполнительный элемент в иерархии как и раньше. Только в случае Agile быть таким элементов немного веселее (что кстати по мнению автора также является частью “большого плана”). Если вы это понимаете – это уже часть прогресса и значит вы найдете достаточно сил для дальнейшего профессионального развития.

Если от прочтения предыдущего абзаца вам стало страшно (вы осознали свое место и вам стало не по себе) – расслабьтесь, сейчас будет еще неприятнее.

Фокус заключается в том, что будь вы менеджером (вас повысили?), вы будете точно также применять различные методологии для минимизации рисков и оптимизации расходов как это делали до вас, заботясь о конечном business value.

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

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

Не согласны? И правильно! Читайте далее.

Но не все так плохо

Все выше изложенные негативные стороны, для вас как для разработчика, применимы как правило к крупным компаниям и к крупным распределенным командам, где действительно крайней сложно следить за всем ходом процесса разработки. И как писалось выше, Agile для конечного разработчика призван служить лишь способом сделать этот процесс более приятным и подконтрольным (помните рассуждения о религии в фильме “Дух времени”?).

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

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

Technorati Tags:
agile, business process, management

Скачать можно здесь.

• SimpleFormController
• MethodNameResovler

Первое, что нужно сделать – это реализовать собственный GodMethodNameResovler, который будет имплементировать стандартный интерфейс MethodNameResolver и поместить туда примерно такой код:

1
public class GodMethodNameResolver implements MethodNameResolver {    private Properties mapping;    private String defaultMethodName;    public void setMappings(Properties mappings) {        this.mappings = mappings;    }    public void setDefaultMethodName(String defaultMethodName) {        this.defaultMethodName = defaultMethodName;    }    public void afterPropertiesSet() {        if (mapping == null) {            throw new IllegalArgumentException("Methods mapping property required.");        }    }    public String getHandlerMethodName(HttpServletRequest request)                    throws NoSuchRequestHandlingMethodException {        for (Iterator it = this.mappings.keySet().iterator(); it.hasNext();) {            String submitParamter = (String)it.next();            if (WebUtils.hasSubmitParameter(request, submitParamter)) {                return (String)mapping.get(submitParamter);            }        }        return defaultMethodName;    }}

Когда с этим покончено, создадим абстрактный контроллер, который в последствии будут наследовать все остальные MultiActionController’ы:

1
public abstract class AbstractMultiActionFormController extends SimpleFormController {    private MethodNameResolver methodNameResolver;    protected ModelAndView processFormSubmission(HttpServletRequest request,        HttpServletResponse response,                                          Object command, BindException errors)                                          throws Exception {        if (errors.hasErrors() || isFormChangeRequest(request)) {            return showForm(request, response, errors);        } else {            String methodName = getMethodNameResolver().getHandlerMethodName(request);            Method m = (Method)this.getClass().getMethod(methodName,                                          new Class[] {HttpServletRequest.class,                                          Object.class, BindException.class});            if (m == null) {                throw new NoSuchRequestHandlingMethodException(methodName, getClass());            }            List params = new ArrayList(3);            params.add(request);            params.add(command);            params.add(errors);            return (ModelAndView) m.invoke(this,      params.toArray(new Object[params.size()]));        }    }    public void setMethodNameResolver(MethodNameResolver methodNameResolver) {        methodNameResolver = methodNameResolver;    }    public MethodNameResolver getMethodNameResolver() {        return methodNameResolver;    }}

Также, потребуется описать все это в конфиге спринга:

1
<bean id="godMethodNameResolver" class="com.myapp.GodMethodNameResolver">    <property name="mappings">        <props>            <prop key="testAction">testAction</prop>        </props>    </property>    <property name="defaultMethodName"><value>testAction</value></property></bean><bean id="blessMultiFormController" class="com.myapp.BlessMultiFormController">    <property name="methodNameResolver"><ref bean="godMethodNameResolver"/></property>    <property name="sessionForm"><value>true</value></property>    <property name="successView"><value>someformview</value></property>    <property name="commandName"><value>somecommand</value></property>    <property name="formView"><value>someformview</value></property></bean>

И последний шаг – создание контроллера:

1
public class BlessMultiFormController extends AbstractMultiActionFormController {    public ModelAndView testAction(HttpServletRequest request, Object command,                                      BindException errors) throws Exception {        // do something with form        return showForm(request, errors, getFormView());    }}

Алилуя!

• Blogger
• YouTube
• FeedBurner
• Picasa Web Albumes
• …and all Google Apps

И значете что? Доступ ко всем этим прелестям вы можете получить уже прямо сейчас, скачав всего лишь одну библиотеку. Библиотека, представляющая из себя в полном смысле слова КЛИЕНТ, доступна для таких платформ:

• Java
• .NET
• PHP
• Python
• Objective-C
• JavaScript

Работать с ней очень просто. Ниже приведу пример работы с YouTube:

public class YouTubeServiceDelegate {    private static final String CLIENT_ID = "Your client ID here";    private static final String DEVELOPER_KEY = "Your developer key here";    private static final String USER_SPECIFIC_URL        = "http://gdata.youtube.com/feeds/api/users/{userId}/uploads";    public VideoFeed getVideosByUserId(String userId)        throws YourException {        YouTubeService service =

            new YouTubeService(CLIENT_ID, DEVELOPER_KEY);        VideoFeed videoFeed = null;        try {            videoFeed = service.getFeed(new URL(                USER_SPECIFIC_URL.replace("{userId}", userId)),                VideoFeed.class);        } catch (IOException e) {            throw new YourException("Say something");        } catch (ServiceException e) {            throw new YourException("Say something");        }        return videoFeed;        }}

Приведенный выше простейший класс демонстрирует как легко и просто получить список загруженного видео с YouTube для определенного пользователя.Удачного вам использования!

В этой статье нам предстоит сделать:

• Сервис и DAO для работы с данными
• Контроллер обработки формы
• Валидатор формы
• JSP страницу

Одним словом – ерунда осталась

Сервисы и DAO

Для начала разберёмся, для чего нужно и то и другое, ведь можно обойтись без сервисов и работать просто с DAO. Да, можно. Однако, прежде всего это более правильный подход или архитектура, называйте как угодно. Уровень сервисов включает в себя не только выполнение таких простых действий как сохранить и получить объект, но и содержит в себе часть логики, необходимую для выполнения действий над данными перед сохранением или получением из БД. Тобишь, говоря более наглядно, метод отвечающий, например, за сохранение нового пользователя в БД на уровне DAO будет скорее всего называться save, а на уровне сервиса register. Улавливаете разницу? Во вторых, на уровне сервисов в нашем приложении будет происходить управление транзакциями.

Переходя от нудной теории к практике создадим сервис, обеспечивающий добавление нового подписчика в БД.

InviteSubscribersService.java

@Transactional(readOnly = true)
public class InviteSubscribersService {

private InviteSubscribersDAO dao;

@Transactional(readOnly = false, propagation = Propagation.REQUIRES_NEW)
public void create(InviteSubscriber subscriber) throws DataAccessException, ServiceException {
if (subscriber == null) {
throw new ServiceException(”Subscriber cannot be null or empty”);
}

getInviteSubscribersDAO().save(subscriber);
}

public void setInviteSubscribersDAO(InviteSubscribersDAO dao) {
this.dao = dao;
}

public InviteSubscribersDAO getInviteSubscribersDAO() {
return dao;
}
}

Разберём по порядку, что тут к чему.

Аннотация @Transactional(readOnly = true)перед объявлением класса говорит о том, что все методы содержащиеся в классе расcчитаны по умолчанию на чтение данных из БД. Далее сследует объявление DAO, с которым будет работать сервис и непосредственно сам метод, выполняющий создание нового подписчика в БД.

Аннотация @Transactional(readOnly = false, propagation = Propagation.REQUIRES_NEW)говорит о том, что этот метод транзакционный. Фокус в том, что вам не нужно вручную делать commit и rollback, как это приходилось делать нашим предкам. Об этом позаботится менеджер транзакций встроенный в Spring, который мы успешно сконфигурировали в предыдущей статье. В случае, если произойдёт exception, менеджер автоматически выполнит rollback, в противном случае commit. При желании, можно указать на какие конкретно типы Exception должен срабатывать rollback. Об этом более детально смотрите документацию Spring.

Далее, как вы уже догадались, следует создать DAO.

InviteSubscribersDAO.java

public class InviteSubscribersDAO extends HibernateDaoSupport {

public void save(InviteSubscriber subscriber) throws DataAccessException {
getHibernateTemplate().save(subscriber);
}
}

Здесь всё просто. Работа с Hibernate происходит через специальный слой HibernateDaoSupport встроенный в Spring. Зачем использовать какой-то слой, если можно работать с Hibernate на прямую? Очень просто – этот слой автоматически следит за созданием и закрытием сессий, как следствие – у вас меньше головной боли.

Контроллер обработки формы

Создадим контроллер, который будет обрабатывать нашу форму подписки.

InviteActionController.java

public class InviteActionController extends SimpleFormController {

private InviteSubscribersService subscribersService;

protected ModelAndView onSubmit(HttpServletRequest request,
HttpServletResponse response,
Object command,
BindException errors) throws Exception {

InviteFormBean form = (InviteFormBean)command;

InviteSubscriber subscriber = new InviteSubscriber();
subscriber.setEmail(form.getEmail());

getSubscribersService().create(subscriber);

request.setAttribute(”afterprocess_message”, “Thank you! You have joined to the AllOfRSS users.”);
return super.onSubmit(request, response, form, errors);
}

public InviteSubscribersService getSubscribersService() {
return subscribersService;
}

public void setSubscribersService(InviteSubscribersService subscribersService) {
this.subscribersService = subscribersService;
}
}

Здесь вообще всё проще пареной репы. Метод onSubmit срабатывает при сабмите формы. Command – это объект формы, преобразуем его в соответсвующий бин и создаём объект для сохранения в БД. Объект errors содержит ошибки, возвращаемые валидатором. Создаём валидатор и не забываем, что он уже прописан у нас в конфиге, а значит больше ни о чём думать не надо, всё будет работать автоматически.

Валидатор

InviteFormValidator.java

public class InviteFormValidator implements Validator {

public boolean supports(Class candidate) {
return InviteFormBean.class.isAssignableFrom(candidate);
}

public void validate(Object obj, Errors errors) {
ValidationUtils.rejectIfEmptyOrWhitespace(errors, “email”, “required”, “To proccess this action you need to fill your e-mail!”);

InviteFormBean form = (InviteFormBean)obj;
Pattern pattern = Pattern.compile(”.+@.+\\.[a-z]+”);
Matcher matcher = pattern.matcher(form.getEmail());
if (!matcher.matches()) {
errors.rejectValue(”email”, “required”, “Ivalid e-mail address!”);
}
}
}

Осталось создать JSP страничку с формой.

JSP страница

invite.jsp

<%@ page language=”java” contentType=”text/html; charset=utf-8″ pageEncoding=”utf-8″%>
<%@ taglib prefix=”c” uri=”http://java.sun.com/jsp/jstl/core” %>
<%@ taglib prefix=”form” uri=”http://www.springframework.org/tags/form” %>
<%@ taglib prefix=”spring” uri=”http://www.springframework.org/tags” %>

<c:set var=”successmessage” value=”<%= request.getAttribute(”afterprocess_message”)%>”/>

<form:form commandName=”invite”>

<form:input path=”email” id=”email” cssClass=”text”/>
<input type=”submit” value=”?”/>

${successmessage}

<spring:hasBindErrors name=”invite”>
<form:errors path=”email” />
</spring:hasBindErrors>

</form:form>

Я даже не буду здесть ничего объяснять. Просто внимательно посмотрите на форму, а затем на конфигы, созданные в предыдущей статье и у вас не останется ни одного вопроса.

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

Развлекайтесь и больше бывайте на свежем воздухе…

В данной статье я рассмотрю конфигурацию нашего приложения. В процессе будут созданы все необходимые конфигурационные файлы для его полноценного функционирования.
Для начала откроем Eclipse и создадим новый проект (File->New->Web Project), также рекомендую установить плагин для более комфортной работы с фреймворком Spring – Spring IDE Plugin. В процессе создания проекта, Eclipse попросит указать название вашей “Web root folder” (по умолчанию стоит – WebRoot), я обычно указываю – web, а также J2EE Specification Level, отметьте – Java EE 5.0 (если, конечно, вы используете Java 5). Остальное пусть будет без изменений.

Веб дескриптор

Как и в любом другом веб-приложении на Java всё начинается с конфигурации web.xml (web(WebRoot)/WEB-INF/web.xml).

Для начала установим путь к осноному конфигу Spring.

web.xml

<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>/WEB-INF/allofrss-servlet.xml</param-value>
</context-param>

<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>

Сравнительно с другими веб-приложениям на Java, приложение на Spring не отличается особой оригинальностью поскольку здесь тоже всё работает через сервлеты, правда сервлет здесь будет всего один. DispatcherServlet главный сервлет в приложении на Spring. Он выполняет роль “гейтвея” входящих запросов, перенаправляя вызовы “внутрь” системы (в науке это называется паттерном Front Controller).

web.xml

<servlet>
<servlet-name>allofrss</servlet-name>
<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>

Следует, также, установить маппинг на DispatcherServlet. Конструкция, приведенная ниже, означает, что все запросы, которые начинаются с “/c” будут направлены на DispatcherServlet.

web.xml

<servlet-mapping>
<servlet-name>allofrss</servlet-name>
<url-pattern>/c/*</url-pattern>
</servlet-mapping>

И последенее, что следует внести в наш web.xml:

<welcome-file-list>
<welcome-file>index.jsp</welcome-file>
</welcome-file-list>

Закончив с конфигурацией web.xml, можно перейти к настройке Spring приложения. Я предлагаю разделить конфигурацию на 3 конфигурационных файла:

• /WEB-INF/context/common.xml – основной конфиг, содержащий информацию о маппингах и слое отображения
• /WEB-INF/context/allofrss-context.xml – конфиг, содержащий информацию о контроллерах приложения
• /WEB-INF/context/allofrss-data.xml – содержит информацию о классах доступа к БД

Настройка маппинга и слоя отображения

Создайте файл /WEB-INF/context/common.xml следующего содержания.

common.xml

<?xml version=”1.0″ encoding=”UTF-8″?>
<beans xmlns=”http://www.springframework.org/schema/beans”
xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”
xmlns:aop=”http://www.springframework.org/schema/aop”
xsi:schemaLocation=”http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd”>

<!– This config contains main info about application mappings and view resolvers–>

</beans>

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

common.xml

<bean id=”simpleUrlMapping” class=”org.springframework.web.servlet.handler.SimpleUrlHandlerMapping”>
…
</bean>

В терминах Spring любой класс, конфигурируемый с его помощью называется бином(<bean…), не путать с JavaBeans. В связи с этим, поначалу вас может одолевать вопрос, типа, причём тут бин если я подключаю обычный класс. Извините, не ко мне вопрос, просто смиритесь

Запись id=”simpleUrlMapping” определяет уникальный идентификатор для подключаемого класса для возможности ссылаться на этот класс в пределах конфигов по короткому имени.

Определив класс, добавим ему параметры маппинга.

common.xml

<bean id=”simpleUrlMapping” class=”org.springframework.web.servlet.handler.SimpleUrlHandlerMapping”>
<property name=”order”><value>0</value></property>
<property name=”mappings”>
<props>
<prop key=”/welcome”>inviteController</prop>
<prop key=”/about”>aboutController</prop>
</props>
</property>
</bean>

Записи <prop key=”/welcome”>inviteController</prop>, <prop key=”/about”>aboutController</prop> означают, что запросы /welcome и /about должны обработать классы с id inviteController и aboutController соотвественно.

Осталось подключить класс, который будет заниматься отображением.

common.xml

<bean id=”viewResolver” class=”org.springframework.web.servlet.view.InternalResourceViewResolver”>
<property name=”cache” value=”false”/> <!– Запрещаем кэширование –>
<property name=”viewClass”><value>org.springframework.web.servlet.view.JstlView</value></property> <!– Используем JSTL –>
<property name=”prefix”><value>/WEB-INF/templates/jsp/</value></property> <!– Путь, где будут храниться JSP –>
<property name=”suffix”><value>.jsp</value></property> <!– Расширение для файлов шаблонов –>
</bean>

Конфигурация контроллеров

Создайте файлик /WEB-INF/context/allofrss-context.xml с базовым содержанием, аналогичным предыдущему common.xml.

Добавим информацию о классах контроллерах.

allofrss-context.xml

<bean id=”inviteController” class=”com.allofrss.controllers.action.InviteActionController”>
<property name=”commandName” value=”invite”/> <!– Название формы–>
<property name=”commandClass” value=”com.allofrss.beans.form.InviteFormBean”/> <!– Бин формы –>
<property name=”formView” value=”invite”/> <!– Название JSP с формой –>
<property name=”successView” value=”invite”/> <!– Название JSP, которая будет показана после успешной обработки формы –>
<property name=”validator”> <!– Класс валидатора формы –>
<bean class=”com.allofrss.validators.InviteFormValidator”/>
</property>
</bean>

<bean id=”aboutController” class=”com.allofrss.controllers.lookup.AboutController”/>

Конфигурация доступа к БД

Аналогично, создаём файл /WEB-INF/context/allofrss-data.xml следующего содержания.

allofrss-data.xml

<?xml version=”1.0″ encoding=”UTF-8″?>
<beans xmlns=”http://www.springframework.org/schema/beans”
xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”
xmlns:aop=”http://www.springframework.org/schema/aop”
xmlns:tx=”http://www.springframework.org/schema/tx”
xsi:schemaLocation=”
http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx-2.0.xsd
http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop-2.0.xsd”>

</beans>

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

allofrss-data.xml

<bean id=”dataSource” class=”org.apache.commons.dbcp.BasicDataSource” destroy-method=”close”>
<property name=”driverClassName” value=”com.mysql.jdbc.Driver”/>
<property name=”url” value=”jdbc:mysql://localhost:3306/database_name?useUnicode=true”/>
<property name=”username” value=”username”/>
<property name=”password” value=”password”/>
</bean>

Как я упоминал в предыдущей статье, в качестве ORM будет использоваться фреймворк Hibernate. В Spring присутствуют классы, облегчающие процесс интеграции Hibernate в ваше приложение. Прежде всего следует определить класс поддержки сессий БД.

allofrss-data.xml

<bean id=”sessionFactory” class=”org.springframework.orm.hibernate3.LocalSessionFactoryBean”>
<property name=”dataSource” ref=”dataSource”/> <!– В качестве параметра передается ссылка на определенный выше класс источника данных –>
<property name=”mappingResources”/>
<property name=”hibernateProperties”> <!– Некоторые параметры Hibernate –>
<value>
hibernate.dialect=org.hibernate.dialect.MySQLDialect
hibernate.show_sql=true
hibernate.format_sql=false
hibernate.use_sql_comments=true
hibernate.connection.charSet=utf8
</value>
</property>
</bean>

На данном этапе можно сказать, что конфигурация доступа к БД закончена, однако мы на этом не остановимся и добавим ещё один очень важный компонент – поддержку транзакций.

Воспользуемся встроенным в Spring менеджером транзакций DataSourceTransactionManager, а также поддержкой AOP. Для этого добавим несколько простых строчек.

allofrss-data.xml

<tx:annotation-driven transaction-manager=”txManager”/>

<bean id=”txManager” class=”org.springframework.jdbc.datasource.DataSourceTransactionManager”>
<property name=”dataSource” ref=”dataSource”/> <!– В качестве параметра всё тот же источник данных –>
</bean>

Ну и на последок, объединим все созданные конфигурационные файлы, создав файл /WEB-INF/allofrss-servlet.xml с таким содержанием.

allofrss-servlet.xml

<?xml version=”1.0″ encoding=”UTF-8″?>
<beans xmlns=”http://www.springframework.org/schema/beans”
xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”
xmlns:aop=”http://www.springframework.org/schema/aop”
xsi:schemaLocation=”http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd”>

<import resource=”context/allofrss-data.xml” />
<import resource=”context/allofrss-context.xml” />
<import resource=”context/common.xml” />
</beans>

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

Читайте также:

• Разработка веб-приложений на Spring. Часть 1 (Проектирование)
• Webdev: Обзор фреймворка Spring