В приложении Spring MVC 3.1, как я должен использовать локаль запроса для управления форматированием строк с помощью HttpMessageConverter?

В приложении Spring MVC 3.1, как я должен использовать локаль запроса для управления форматированием строк с помощью HttpMessageConverter?

У меня есть это перечисление, представляющее типы почв (выдержка):

public enum Soil {

    SAND("0.35"),
    PEAT("0.70");

    private Double porosity;

    Soil(String porosity) {
        this.porosity = new Double(porosity);
    }

    @NumberFormat(pattern = "0.000")
    public Double getPorosity() {
        return porosity;
    }

}

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

@Controller
@RequestMapping("/soil/*")
public class SoilController {

    @RequestMapping(value="{id}/porosity")
    public @ResponseBody Double getPorosity(@PathVariable String id) {
        Soil soil = Soil.valueOf(id);
        return soil.getPorosity();
    }

}

Как я понимаю, используя @RequestBody, Spring преобразует возвращенный Double в тело ответа с помощью HttpMessageConverter. Это отлично работает, но строка ответа всегда форматируется с использованием стандартного языкового стандарта. Например, запрос GET на/почва/PEAT/пористость приведет к тому, что в тело ответа будет записано «0,7».

Тем не менее, большинство посетителей имеют «nl» в качестве предпочтительной локали, ожидая десятичную запятую вместо десятичной точки. В этом случае я бы хотел, чтобы строка ответа была отформатирована как «0,7».

Я могу добавить параметр HttpServletRequest к сигнатуре метода обработчика, чтобы определить локаль запроса, но не знаю, как передать эту информацию в HttpMessageConverter - MappingJacksonHttpMessageConverter в этом случае (*). Я знаю, что можно настроить компонент MappingJacksonHttpMessageConverter, переопределив значения по умолчанию в теге, но как мне узнать о локали запроса?

(*) DEBUG: org.springframework.web.servlet.mvc.method.annotat ion.RequestResponseBodyMethodProcessor - написано [0.7] как «application/json; charset = UTF-8», используя [org.springframework.http.converter.json. MappingJac ksonHttpMessageConverter @ 145240a]

Рабочее решение

Как заметил @CodeChimp ( https://stackoverflow.com/a/15074077/1343409 ), форматирование i18n лучше всего обрабатывать вид.

Я изменил метод обработчика на

@RequestMapping(value="{id}/porosity")
public String getPorosity(@PathVariable String id, HttpServletRequest request, Model model) {
    Soil soil = Soil.valueOf(id);
    model.addAttribute("doubleValue", soil.getPorosity());
    return "basevalues/double";         
}

и добавил простой вид JSTL double.jsp

<%@ taglib prefix="fmt" uri="http://java.sun.com/jsp/jstl/fmt" %>
<%@ page contentType="text/plain;charset=UTF-8" %>

Это работает для меня.

1
nl ja de

1 ответы

Аннотации ResponseBody инструктируют Spring принимать все, что вы возвращаете, и переносить в тело ответа. Он делает это 1 к 1, конверсия отсутствует. Например, я использовал эту аннотацию для возврата данных двоичного изображения, CSV-файлов и т. Д. Если вы хотите вернуть число, сформированное для определенного языкового стандарта, вам нужно будет выполнить проверку в методе getPorosity() и сделать правильный модификация есть.

Изменить для добавления информации

Мое понимание HttpMessageConverter заключается в том, что оно используется для преобразования в/из HTTP-запроса/ответов. HttpMessageConverter сам по себе является интерфейсом со многими реализациями. Правильная реализация выбирается на основе заголовков запроса/ответа и типа возвращаемого вами дохода. Например, если запрос указывает, что он принимает приложение/xml или text/xml, то MarshallingHttpMessagingConverter используется для преобразования возвращаемого значения в соответствующий формат XML.

Тем не менее, аннотация @ResponseBody позволяет обойти конверсию. Эта аннотация в основном указывает на Spring: «Не беспокойтесь о преобразовании возвращаемого типа, просто возьмите то, что я возвращаю, и засунем в тело ответа».

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

0
добавлено
Спасибо за ваше предложение. Тем не менее, Spring docs на static.springsource.org/spring/docs/3.1.x/… подразумевать, что методы обработчика могут возвращать любой тип и оставлять преобразование в String для реализации HttpMessageConverter. Я доволен прагматичным решением, но кажется странным, что нужно делать форматирование String в обработчике и принудительно возвращать String.
добавлено автор gerjantd, источник
Ваше последнее замечание заставило меня понять, что я, вероятно, пытаюсь использовать HttpMessageConverter для проблемы, которую он не предназначен для решения. Конечно, вы правы: если вам нужно отформатировать номер, лучше использовать представление. Я приложил рабочее решение к моему оригинальному вопросу. Еще раз спасибо за то, что поставил меня на правильный путь!
добавлено автор gerjantd, источник
Spring Framework and more
Spring Framework and more
839 участник(ов)

чат о spring framework и связанных с ним технологиях. We're discussing: job, tech questions, beer meet up/networking: tech review ,LinkedIn skills, SOF q/a raise up& etc. languages: russian,java,eng.