В Spring / JSP, где должно выполняться форматирование? - PullRequest
Новая
       46

В Spring / JSP, где должно выполняться форматирование?

5 голосов
/ 12 декабря 2008

Я использую Spring, но этот вопрос относится ко всем типам конструкций JSP-контроллеров.

Страница JSP ссылается на данные (с использованием тегов), которые заполняются соответствующим контроллером. У меня вопрос, где подходящее место для выполнения форматирования, в JSP или контроллере?

До сих пор я готовил данные, форматируя их в моем контроллере. 

public class ViewPersonController extends org.springframework.web.servlet.mvc.AbstractController
{
    private static final Format MY_DATE_FORMAT = new SimpleDateFormat(...);
    protected ModelAndView handleRequestInternal(HttpServletRequest request, HttpServletResponse response)
    {
        Person person = get person from backing service layer or database
        Map properties = new HashMap();

        // No formatting required, name is a String
        properties.put("name", person.getName());

        // getBirthDate() returns Date and is formatted by a Format
        properties.put("birthDate", MY_DATE_FORMAT.format(person.getBirthDate()));

        // latitude and longitude are separate fields in Person, but in the UI it's one field
        properties.put("location", person.getLatitude() + ", " + person.getLongitude());

        return new ModelAndView("viewPerson", "person", properties);
    }
}

Файл JSP будет выглядеть примерно так: 

Name = <c:out value="${person. name}" /><br>
Birth Date = <c:out value="${person. birthDate}" /><br>
Location = <c:out value="${person. location}" /><br>

Я знаю, что в JSP есть некоторые условия для форматирования, 

<%@ taglib uri="http://java.sun.com/jstl/fmt" prefix="fmt" %>
<fmt:formatDate type="date" value="${person. birthDate}" />

Но это работает только с Java java.util.Format. Что делать, если мне нужны более сложные или вычисленные значения. В таком случае размещение кода в JSP будет громоздким (и уродливым).

Мне любопытно, следует ли это духу Spring / JSP / MVC. Другими словами, является ли контроллер частью представления? Где предпочтительное место для выполнения форматирования, связанного с просмотром? Должен ли мой контроллер просто возвращать объект (Person) вместо Map отформатированных значений?

Ответы [ 4 ]

5 голосов
/ 12 декабря 2008

JSP, как правило, не содержат большого (или какого-либо?) Кода в них, поэтому ваши параметры будут

  • Контроллер
  • библиотеки тегов

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

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

1 голос
/ 12 декабря 2008

Я предпочитаю рассмотреть форматирование части слоя отображения, что делается в JSP. Я использовал Velocity совсем недавно, но та же идея с JSP: контроллер возвращает модель данных, и представление отвечает за отображение этих данных в видимом представлении. Множество библиотек тегов JSP для общих нужд.

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

1 голос
/ 12 декабря 2008

Я обычно делаю форматирование и т. Д. В bean-компоненте или представлении "помощник". Это имеет несколько преимуществ, включая следующие:

  1. Проще проверить
  2. Гибкость в изменении технологий просмотра, не беспокоясь о переносе или переписывании того, что вы сделали в пользовательских вкладках.
  3. Более чистый и простой в обслуживании контроллер и просмотр кода.
0 голосов
/ 12 декабря 2008

Я бы так и сделал -

экземпляр класса Person будет единственным объектом в модели ModelAndView

Я бы переместил «логику представления» в сам класс Person. Например, 

public class Person {
    public String getLocation() {
        return this.latitude.concat(", ").concat(this.longitude);
    }
}

Я думаю, что в целом такой подход: 1 - укрепляет модель вашего домена. 2 - уменьшает дублирование кода (что, если вы хотите показать местоположение в другом JSP? При вашем подходе вы получите много дублированного кода)

...