Главная » Spring » Контроллер обработки входных данных Spring

0

Контроллер HomeController получился довольно простым. Перед ним не стоит задача обрабатывать пользовательские данные или какие-либо параметры. Он просто обрабатывает простейший запрос и заполняет модель данными для представления. Сложно было бы придумать более простой контроллер.

Но не у всех контроллеров жизнь такая же простая. Часто от кон- троллеров требуется выполнять операции с некоторыми данными, ко- торые передаются в виде параметров запроса в URL или данных фор- мы. Это как раз относится к контроллерам SpitterController и Spittle- Controller. Эти два контроллера будут обрабатывать различные виды запросов, многие из которых содержат некоторые входные данные.

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

Создание  контроллера, обрабатывающего входные данные

Один из способов передачи данных контроллеру SpitterController – отправка имени пользователя приложения Spitter в URL в виде па- раметра запроса. Например, при обращении по URL http://localhost: 8080/spitter/spitters/spittles?spitter=habuma приложение должно отобразить все сообщения пользователя habuma.

В листинге 7.6 представлена реализация контроллера SpitterCont- roller, способного обрабатывать такого рода запросы.

Листинг 8.6. Типичный способ обработки запросов на получение сообщений пользователя приложения Spitter

package  com.habuma.spitter.mvc;

import  org.springframework.beans.factory.annotation.Autowired; import    org.springframework.stereotype.Controller;

import   org.springframework.ui.Model;

import     org.springframework.web.bind.annotation.RequestParam; import    org.springframework.web.bind.annotation.RequestMapping; import      com.habuma.spitter.domain.Spitter;

import com.habuma.spitter.service.SpitterService;

import  static  org.springframework.web.bind.annotation.RequestMethod.*;

@Controller

@RequestMapping("/spitter")     // Корневой путь в URL public   class   SpitterController   {

private final SpitterService spitterService;

@Inject

public  SpitterController(SpitterService  spitterService)  { this.spitterService   =   spitterService;

}

// Обрабатывает GET-запросы к URL /spitter/spittles

@RequestMapping(value="/spittles",    method=GET)

public  String  listSpittlesForSpitter(

@RequestParam("spitter") String username, Model model) { Spitter   spitter   =   spitterService.getSpitter(username); model.addAttribute(spitter);                            // Заполнение модели model.addAttribute(spitterService.getSpittlesForSpitter(username)); return      "spittles/list";

}

}

В листинге 8.6 класс SpitterController отмечен аннотациями @Cont- roller и @RequestMapping. Как уже говорилось выше, аннотация @Cont- roller подсказывает элементу <context:component-scan>, что данный класс должен автоматически регистрироваться в контексте прило- жения Spring как компонент.

Обратите внимание, что класс SpitterController также отмечен аннотацией @RequestMapping. Аннотация @RequestMapping уже использо- валась в определении класса HomeController для аннотирования ме- тода showHomePage(), но при применении на уровне класса аннотация

@RequestMapping действует несколько иначе.

При применении к классу, как в данном примере, аннотация

@RequestMapping определяет корневой путь в URL, обрабатываемый данным контроллером. В конечном итоге в классе SpitterController будет реализовано несколько методов-обработчиков, по одному для каждого типа запросов. И в данном случае аннотация @RequestMapping сообщает, что все эти запросы будут иметь пути, начинающиеся со

/spitters.

В настоящий момент в классе SpitterController имеется всего один метод: listSpittlesForSpitter(). Подобно любому другому методу-об- работчику, данный метод отмечен аннотацией @RequestMapping. Она мало чем отличается от аналогичной аннотации, использованной в классе HomeController. Но в действительности разница гораздо су- щественнее, чем кажется на первый взгляд.

Действительно  ли  нужна  аннотация  @RequestParam?  Аннотация

@RequestParam не является строго обязательной. Ее удобно использовать для связывания параметров запроса с параметрами метода, когда их имена отличаются. В соответствии с соглашениями все неаннотиро- ванные параметры метода обработчика будут связаны с одноименными параметрами запроса. Например, метод listSpittlesForSpitter() имеет параметр spitter, которому соответствует параметр запроса username, поэтому аннотация @RequestParam в данном случае необходима. Аннотация @RequestParam также может пригодиться, когда предполагается компилировать программный код Java без включения отладочной инфор-

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

Аннотация @RequestMappings ограничивает область отображения, объявленную в аннотации @RequestMapping на уровне класса. В дан- ном случае на уровне класса класс SpitterController отображает- ся на путь /spitters, а на уровне метода – на путь /spittles. В ре- зультате объединения этих двух аннотаций получается, что метод listSpittlesForSpitter() должен обрабатывать запросы для /spitters/ spittles. Кроме того, значение GET в атрибуте method указывает, что этот метод будет обрабатывать только запросы типа HTTP GET.

Метод listSpittlesForSpitter()  принимает строковый параметр

username с именем пользователя и объект Model.

Параметр username отмечен аннотацией @RequestParam("spitter"), чтобы показать, что он должен получить значение параметра запро- са с именем spitter. Этот параметр будет использоваться методом listSpittlesForSpitter() для поиска соответствующего объекта Spitter и его списка сообщений – объектов Spittle.

Возможно, вы уже призадумались над вторым параметром метода listSpittlesForSpitter(). В контроллере HomeController в качестве мо- дели передавался объект типа Map<String, Object>. А здесь передается объект Model.

В действительности объект, передаваемый как параметр типа Model, можно передавать как параметр типа Map<String,Object>. Но тип Model позволяет использовать некоторые вспомогательные методы, удобные для заполнения модели, такие как addAttribute(). Метод addAttribute() действует практически так же, как метод put() ин- терфейса Map, за исключением того, что он определяет собственный ключ для доступа к данным в отображении.

Когда в модель добавляется объект Spitter, метод addAttribute() дает ему имя spitter, которое получается при применении правил именования свойств компонентов JavaBeans к имени класса объ- екта. При добавлении списка сообщений (объект List, содержащий список объектов Spittle) метод addAttribute() добавляет имя List к имени типа элементов списка, в результате получается атрибут с именем spittleList.

Теперь практически все готово к вызову метода listSpittlesFor-

Spitter(). Мы определили контроллер SpitterController и его метод-

обработчик. Осталось лишь написать представление, которое будет отображать список сообщений.

Источник:   Уоллс К., Spring в действии. – М.: ДМК Пресс, 2013. – 752 с.: ил.

По теме:

  • Комментарии