Что такое Spring MVC
Spring Web MVC (Spring MVC) — это элегантная веб-инфраструктура, основанная на платформе Servlet API, которая всегда была важной частью Spring Framework. Официальное название «Spring Web MVC» происходит от имени его исходного модуля spring-webmvc, но его часто называют «Spring MVC».
Параллельно с Spring Web MVC в Spring Framework 5.0 представлен стек Reactive — веб-фреймворк, название которого Spring WebFlux также основано на его исходном модуле spring-webflux.
DispatcherServlet
Как и многие другие веб-фреймворки, Spring MVC также разработан на основе шаблона контроллера (контроллера) страницы внешнего интерфейса.Основной сервлет — DispatcherServlet предоставляет общий метод обработки запросов от клиента, а фактическая работа может выполняться с помощью Определяет сконфигурированные компоненты для выполнения. Эта модель очень гибкая в использовании и может удовлетворить различные потребности проекта.
Как и любой обычный сервлет, DispatcherServlet необходимо настроить с помощью кода Java в соответствии со спецификацией сервлета или объявить сопоставление между запросами и сервлетами в файле web.xml. DispatcherServlet считывает конфигурацию Spring, чтобы обнаружить компоненты, от которых он зависит, для сопоставления запросов, разрешения представления, обработки исключений и т. д.
Ниже приведен пример конфигурации кода Java для регистрации и инициализации DispatcherServlet. Этот класс будет автоматически обнаружен контейнером сервлета:
public class MyWebApplicationInitializer implements WebApplicationInitializer {
@Override
public void onStartup(ServletContext servletCxt) {
// 加载 Spring Web Application 的配置
AnnotationConfigWebApplicationContext ac = new AnnotationConfigWebApplicationContext();
ac.register(AppConfig.class);
ac.refresh();
// 创建并注册 DispatcherServlet
DispatcherServlet servlet = new DispatcherServlet(ac);
ServletRegistration.Dynamic registration = servletCxt.addServlet("app", servlet);
registration.setLoadOnStartup(1);
registration.addMapping("/app/*");
}
}
Вот как зарегистрировать и инициализировать DispatcherServlet в web.xml:
<web-app>
<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>
<context-param>
<param-name>contextConfigLocation</param-name>
<!-- Spring 上下文的配置 -->
<param-value>/WEB-INF/app-context.xml</param-value>
</context-param>
<servlet>
<servlet-name>app</servlet-name>
<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
<init-param>
<param-name>contextConfigLocation</param-name>
<param-value></param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>app</servlet-name>
<!-- "/*" 表示将所有请求交由 DispatcherServlet 处理 -->
<url-pattern>/*</url-pattern>
</servlet-mapping>
</web-app>
1. Иерархия контекстов приложения
DispatcherServlet полагается на WebApplicationContext (функциональное расширение обычного ApplicationContext) для реализации своей конфигурации. WebApplicationContext содержит ссылку на связанные с ним ServletContext и Servlet. Он также привязан к контексту сервлета, так что приложение может использовать статические методы в RequestContextUtils для поиска WebApplicationContext, чтобы определить, нужно ли вызывать методы в DispatcherServlet.
Для приложений только с одним WebApplicationContext этого достаточно. Также возможно использовать иерархически структурированные контексты, где корневой контекст (или базовый контекст) совместно используется несколькими экземплярами DispatcherServlet (или другого обычного сервлета), каждый со своей собственной конфигурацией подконтекста.
Корневой контекст обычно содержит общие bean-компоненты, которые совместно используются несколькими экземплярами сервлета, такими как хранилище данных и бизнес. Эти bean-компоненты наследуются для использования, а также могут быть переопределены (т. е. переопределены конфигурации bean-компонента) в определенном подконтексте сервлета, который имеет локальные экземпляры bean-компонентов, уникальные для этого сервлета:
Ниже приведен пример конфигурации с использованием иерархии WebApplicationContext:
public class MyWebAppInitializer extends AbstractAnnotationConfigDispatcherServletInitializer {
@Override
protected Class<?>[] getRootConfigClasses() {
return new Class<?>[] { RootConfig.class };
}
@Override
protected Class<?>[] getServletConfigClasses() {
return new Class<?>[] { App1Config.class };
}
@Override
protected String[] getServletMappings() {
return new String[] { "/app1/*" };
}
}
Конфигурация в web.xml
<web-app>
<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>
<context-param>
<param-name>contextConfigLocation</param-name>
<!-- 根上下文的配置 -->
<param-value>/WEB-INF/root-context.xml</param-value>
</context-param>
<servlet>
<servlet-name>app1</servlet-name>
<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
<init-param>
<param-name>contextConfigLocation</param-name>
<!-- app1 专属的的子上下文 -->
<param-value>/WEB-INF/app1-context.xml</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>app1</servlet-name>
<url-pattern>/app1/*</url-pattern>
</servlet-mapping>
</web-app>
2. Бины со специальными функциями
DispatcherServlet полагается на эти специальные bean-компоненты для обработки запросов и возврата ответов. Эти специальные bean-компоненты относятся к объектам, которые реализуют протокол инфраструктуры WebFlux, также управляемый Spring. Все эти объекты содержат набор конфигураций по умолчанию, но различные свойства также можно настраивать для гибкого расширения или функциональной перезаписи.
имя класса компонента | Функции |
---|---|
HandlerMapping | Сопоставляет запросы обработчикам и ряду перехватчиков для предварительной и последующей обработки. Это сопоставление имеет набор стандартов, а конкретные функции зависят от реализации HandlerMapping. Две основные реализации HandlerMapping — это RequestMappingHandlerMapping и SimpleUrlHandlerMapping. Первая поддерживает метод аннотации @RequestMapping, который регистрирует сопоставления URI для обработки запроса. |
HandlerAdapter | Помогает DispatcherServlet вызывать обработчик, который соответствует отображению запроса, не заботясь о том, как вызывается обработчик и какие-либо подробности об обработчике. Например, вызов метода в аннотированном контроллере требует, чтобы аннотации, такие как @RequestMapping, были разрешены в первую очередь. Основная функция HandlerAdapter — скрыть детали реализации DispatcherServlet. |
HandlerExceptionResolver | Содержит обходные пути для различных исключений, которые могут сопоставлять различные исключения с отвечающими обработчиками или страницами и т. д. |
ViewResolver | Верните ответ клиенту, преобразовав имя логического представления возвращаемого значения метода (строка) в обработчик в фактическое представление. |
LocaleResolver, LocaleContextResolver | Определите текущую локаль клиента, чтобы оценить приблизительный часовой пояс, чтобы можно было вернуть интернационализированное представление региона ответа. |
ThemeResolver | Проанализируйте доступные темы для текущего веб-приложения, например, чтобы предоставить персонализированные макеты. |
MultipartResolver | С помощью соответствующей библиотеки синтаксического анализа анализируйте запросы, состоящие из нескольких частей (например, загрузку файлов формы браузера). |
FlashMapManager | Сохраняет и извлекает FlashMap «входов» и «выходов», которые могут передавать параметры из одного запроса в другой, обычно посредством перенаправления. |
3. Конфигурация Web MVC
Приложения могут индивидуально объявлять базовые версии компонентов, перечисленных выше в разделе «Бобы со специальными возможностями». DispatcherServlet сканирует WebApplicationContext, которому принадлежат эти bean-компоненты. Если нет подходящего типа bean-компонента, он вернет тип по умолчанию в DispatcherServlet.properties.
В большинстве случаев конфигурация MVC по умолчанию является лучшей реализацией. Для настройки необходимых bean-компонентов требуется код Java или XML-файлы, а также предоставляется API обратного вызова конфигурации более высокого уровня для переопределения конфигурации по умолчанию.
4. Конфигурация сервлета
В Servlet 3.0 и более поздних версиях контейнер сервлета можно настроить в коде Java или в сочетании с файлом web.xml. Ниже приведен пример регистрации DispatcherServlet с помощью кода Java:
import org.springframework.web.WebApplicationInitializer;
public class MyWebApplicationInitializer implements WebApplicationInitializer {
@Override
public void onStartup(ServletContext container) {
XmlWebApplicationContext appContext = new XmlWebApplicationContext();
appContext.setConfigLocation("/WEB-INF/spring/dispatcher-config.xml");
ServletRegistration.Dynamic registration = container.addServlet("dispatcher", new DispatcherServlet(appContext));
registration.setLoadOnStartup(1);
registration.addMapping("/");
}
}
WebApplicationInitializer — это интерфейс, предоставляемый Spring MVC, все классы реализации которого можно сканировать и автоматически использовать для инициализации любого контейнера Servlet 3. Класс реализации AbstractDispatcherServletInitializer (абстрактный родительский класс WebApplicationInitializer) может настроить сопоставление запроса сервлета и каталог файла конфигурации DispatcherServlet путем переопределения метода, чтобы легко реализовать настройку DispatcherServlet.
Если вы настраиваете Spring через код Java, вам нужно сделать это:
public class MyWebAppInitializer extends AbstractAnnotationConfigDispatcherServletInitializer {
@Override
protected Class<?>[] getRootConfigClasses() {
return null;
}
@Override
protected Class<?>[] getServletConfigClasses() {
return new Class<?>[] { MyWebConfig.class };
}
@Override
protected String[] getServletMappings() {
return new String[] { "/" };
}
}
Если вы используете XML-файл для настройки Spring, вам нужно только определить класс реализации AbstractDispatcherServletInitializer:
public class MyWebAppInitializer extends AbstractDispatcherServletInitializer {
@Override
protected WebApplicationContext createRootApplicationContext() {
return null;
}
@Override
protected WebApplicationContext createServletApplicationContext() {
XmlWebApplicationContext cxt = new XmlWebApplicationContext();
cxt.setConfigLocation("/WEB-INF/spring/dispatcher-config.xml");
return cxt;
}
@Override
protected String[] getServletMappings() {
return new String[] { "/" };
}
}
AbstractDispatcherServletInitializer также может легко добавить фильтр и автоматически сопоставить DispatcherServlet:
public class MyWebAppInitializer extends AbstractDispatcherServletInitializer {
// ...
@Override
protected Filter[] getServletFilters() {
return new Filter[] {
new HiddenHttpMethodFilter(), new CharacterEncodingFilter() };
}
}
Различные фильтры будут зарегистрированы с разными именами и сопоставлены с DispatcherServlet.
The isAsyncSupported protected method of AbstractDispatcherServletInitializer provides a single place to enable async support on the DispatcherServlet and all filters mapped to it. By default this flag is set to true.
Метод isAsyncSupported() в AbstractDispatcherServletInitializer может указать, следует ли включать асинхронную поддержку для каждого фильтра.
Если вы хотите уточнить свою пользовательскую конфигурацию, вы можете сделать это, переопределив метод createDispatcherServlet().
5. Обработка запроса
Правила DispatcherServlet для обработки запросов:
- Найдите и привяжите в запросе WebApplicationContext, который можно использовать в качестве параметра методами в контроллере. Значение по умолчанию привязано к значению, соответствующему DispatcherServlet.WEB_APPLICATION_CONTEXT_ATTRIBUTE.
- Сопоставитель локали (LocaleResolver) также привязан к запросу, он может разрешать информацию в текущей среде локали в процессе синтаксического анализа запроса, рендеринга представления, подготовки данных и т. д. Если вам не нужно анализировать эту информацию, вы можете оставить ее в покое.
- Парсер темы используется для принятия решения о том, какую тему использовать. Если вы не используете тему, вы можете ее игнорировать.
- Если в приложении объявлен преобразователь составных файлов, запрос будет проверен на составные части; если составные части будут найдены, запрос будет заключен в MultipartHttpServlet для обработки.
- Если модель возвращается, представление анализируется и возвращается. Если модель не возвращается (возможно, по соображениям безопасности из-за того, что другие обработчики перехватывают запрос), представление не будет возвращено, поскольку ответ клиенту уже может быть отправлен.
Компонент HandlerExceptionResolver, объявленный в WebApplicationContext, может разрешать исключения, возникающие во время обработки запроса. Анализатор исключений можно настроить для разрешения определенных исключений.
DispatcherServlet также поддерживает возврат даты последнего изменения. DispatcherServlet сканирует зарегистрированное отношение сопоставления и определяет, реализует ли найденный обработчик интерфейс LastModified. Если реализовано, возвращаемое значение длинного метода getLastModified(request) интерфейса LastModified возвращается клиенту.
В web.xml вы можете настроить экземпляр DispatcherServlet, настроив параметры инициализации сервлета (init-param).
Параметры инициализации DispatcherServlet
параметр | значение |
---|---|
contextClass | Класс реализации WebApplicationContext, который инициализирует контекст сервлета, по умолчанию — XmlWebApplicationContext. |
contextConfigLocation | Передается как параметр для указания экземпляра контекста в contextClass, используется для определения местоположения контекста, принимает несколько строк (разделенных запятыми), если конфигурация одного и того же компонента происходит в нескольких контекстах, последний будет иметь преимущественную силу. |
namespace | Пространство имен WebApplicationContext, которое по умолчанию равно значению элемента плюс «сервлет». Например, app, тогда пространство имен — appServlet. |
6. Перехватчики
Все классы реализации HandlerMapping поддерживают использование перехватчиков, особенно когда определенные функции применяются только к определенным запросам (например, оценка разрешений), перехватчики очень полезны. Перехватчик должен реализовать HandlerInterceptor в пакете org.springframework.web.servlet, который предоставляет три метода для вызова в разное время:
- preHandle(..): выполняется до обработки запроса...
- postHandle(..): Выполняется после обработки запроса...
- afterCompletion(..): Выполняется после полного завершения обработки запроса...
Метод preHandle(..) возвращает логическое значение, которое можно выбрать, чтобы прервать или продолжить цепочку обработки запроса. При возврате true цепочка процессоров продолжит выполнение, при возврате false DispatcherServlet будет думать, что перехватчик обработал запрос или вернул представление, и не будет продолжать обработку другими процессорами или перехватчиками в цепочке обработки.
Обратите внимание, что postHandle(..) не очень полезен для использования методов @ResponseBody и ResponseEntity, в HandlerAdapter ответ отправляется до вызова postHandle(..). Поэтому в настоящее время бесполезно изменять ответ. В этом случае ResponseBodyAdvice можно реализовать и объявить как bean-компонент Controller Advice (с аннотацией @ControllerAdvice в классе Controller) или настроить непосредственно в RequestMappingHandlerAdapter.
7. Обработка исключений
При отображении или вызове обработчика запросов (например, контроллера с аннотацией @Controller) для обработки запроса, если возникает исключение, DispatcherServlet вызывает bean-компонент HandlerExceptionResolver для обработки исключения, а затем возвращает информацию, такую как страница ошибки или ошибка. код состояния на стороне клиента.
Несколько классов реализации HandlerExceptionResolver перечислены ниже:
Класс реализации HandlerExceptionResolver
имя класса | Функции |
---|---|
SimpleMappingExceptionResolver | Сопоставление типа исключения с именем представления страницы исключения упрощает возврат страницы ошибки. |
DefaultHandlerExceptionResolver | Обрабатывать исключения, создаваемые Spring MVC, которые могут быть напрямую сопоставлены с различными кодами состояния HTTP. |
ResponseStatusExceptionResolver | Обрабатывать исключения, аннотированные с помощью @ResponseStatus, и сопоставлять их с кодами состояния HTTP. |
ExceptionHandlerExceptionResolver | Обработка исключений путем вызова метода с аннотацией @ExceptionHandler в контроллере (с аннотацией @Controller или @ControllerAdvice ) |
Если вам нужно отобразить несколько типов исключений одновременно, вам необходимо установить вес (атрибут порядка) разных исключений.Чем выше вес, тем позже время обработки.
Как обращаться
HandlerExceptionResolver может возвращать:
- ModelAndView: указывает на имя представления
- ModelAndView без атрибутов: если исключение было обработано методом с меньшим весом
- null: это исключение не может быть распознано текущим обработчиком исключений и должно быть передано следующему обработчику.Если все обработчики не могут обработать это исключение, исключение будет передано в контейнер сервлетов для обработки контейнером
- Пользовательские запросы на обработку исключений также очень просты.Например, настройте bean-компонент HandlerExceptionResolver в xml, и Spring MVC будет автоматически использовать внутренний обработчик исключений по умолчанию для обработки исключений, создаваемых Spring MVC (исключения, аннотированные с помощью @ResponseStatus, или исключения с аннотированными методами @ExceptionHandler). ), вы можете изменить эти конфигурации по умолчанию или просто переопределить новые.
Страница ошибок, определенная в контейнере сервлета (страница ошибок)
Если созданное исключение не обрабатывается ни одним HandlerExceptionResolver, оно будет передано в контейнер сервлета. Если для кода ответа HTTP установлено значение 4xx или 5xx, контейнер сервлетов напрямую вернет страницу ошибки по умолчанию. Пользовательские страницы ошибок можно настроить в web.xml:
<error-page>
<location>/error</location>
</error-page>
На этом этапе, если вы хотите дополнительно настроить обработку исключений, вы можете сделать это:
@RestController
public class ErrorController {
@RequestMapping(path = "/error")
public Map<String, Object> handle(HttpServletRequest request) {
Map<String, Object> map = new HashMap<String, Object>();
map.put("status", request.getAttribute("javax.servlet.error.status_code"));
map.put("reason", request.getAttribute("javax.servlet.error.message"));
return map;
}
}
Это позволяет снова передать запрос /error в DispatcherServlet, что решает ситуацию с использованием RestController для возврата JSON вместо возврата представления.
8. Посмотреть разрешение имени
Spring MVC определяет два интерфейса: View и ViewResolver.View отвечает за подготовку данных перед возвратом представления, а ViewResolver отвечает за сопоставление имен логических представлений с фактическими представлениями. Детали реализации конкретных представлений скрыты.
Несколько классов реализации ViewResolver
имя класса | Функции |
---|---|
AbstractCachingViewResolver | Класс реализации AbstractCachingViewResolver кэширует проанализированные представления, что может повысить производительность определенных технологий представлений. Кэширование можно отключить, установив для свойства cache значение false . Если вы хотите обновить кеш представления во время выполнения, вы можете вызвать метод removeFromCache(String viewName, Locale loc) для удаления кэшированного содержимого. |
XmlViewResolver | Его можно настроить в xml, используя определения DTD компонента Spring. Файл конфигурации по умолчанию — /WEB-INF/views.xml. |
ResourceBundleViewResolver | Анализируя определенный bean-компонент ResourceBundle, имя представления разрешается в имя представления, а URL-адрес разрешается в путь представления. |
UrlBasedViewResolver | URL-адрес может быть напрямую сопоставлен с возвращаемым значением без дополнительной настройки сопоставления, что подходит для ситуации, когда структура представления ясна и может быть сопоставлена напрямую. |
InternalResourceViewResolver | Подкласс UrlBasedViewResolver, который разрешает InternalResourceView (например, Servlet или JSP) и его подклассы, такие как JstlView или TilesView. Конкретный тип представления, который необходимо разрешить, можно указать с помощью метода setViewClass(..) |
FreeMarkerViewResolver | Подкласс UrlBasedViewResolver, который может разрешать FreeMarkerView и пользовательские подклассы. |
ContentNegotiatingViewResolver | Разобрать представление по запрошенному URL-адресу или заголовкам запроса |
Как обращаться
Как и в случае с распознавателем исключений, упомянутым выше, при настройке bean-компонента для разрешения представления вы также можете указать вес различных распознавателей.Чем выше вес, тем позднее время вызова.
ViewResolver может возвращать значение null, чтобы указать, что представление не может быть разрешено.Если это JSP или InternalResourceViewResolver, единственный способ определить, существует ли JSP, — это выполнить метод отправки запроса RequestDispatcher. Поэтому InternalResourceViewResolver должен быть настроен с наивысшим весом среди всех преобразователей представлений.
Если выполнение возвращаемого представления не требует обработки какой-либо бизнес-логики, для этого можно использовать контроллер представления:
@Configuration
@EnableWebMvc
public class WebConfig implements WebMvcConfigurer {
@Override
public void addViewControllers(ViewControllerRegistry registry) {
// 将 url 为 "/" 的请求映射到名为 home 的视图上
registry.addViewController("/").setViewName("index");
}
}
Напишите это в xml:
<mvc:view-controller path="/" view-name="index"/>
перенаправить
Если возвращаемое имя представления начинается с "redirect:", UrlBasedViewResolver будет анализировать его как перенаправление запроса, а следующее имя представления будет перенаправленным URL-адресом.
Это имеет тот же эффект, что и возврат RedirectView, который может перенаправить запрос на относительный путь текущего контекста сервлета, если он написан следующим образом.redirect:http://myhost.com/some/arbitrary/path
, он будет перенаправлен на этот абсолютный путь.
Если аннотация @ResponseStatus написана в методе контроллера, код состояния в аннотации имеет приоритет над кодом в RedirectView.
Вперед
Если конечным распознавателем представлений является UrlBasedViewResolver, вы можете использоватьforward:
, эффект заключается в создании InternalResourceView с помощью метода forward(). Этот префикс не применяется к InternalResourceViewResolver и InternalResourceView (JSP), но полезен для использования других технологий представления и выполнения переадресации запросов. Аналогичным образом объединение нескольких преобразователей представлений в цепочку обработки реализует цепочку обработки.
спецификация содержания
ContentNegotiatingViewResolver на самом деле не разрешает представление, а вызывает другие преобразователи представлений, чтобы найти представление, соответствующее релевантной информации в клиентском запросе. Эту информацию можно получить из заголовка запроса.Accept
параметры в url или url.
ContentNegotiatingViewResolver сравнивает запрошенный тип мультимедиа с типами мультимедиа (также известными как Content-Types), поддерживаемыми представлениями, связанными с ViewResolver, и выбирает наилучшее представление для обработки запроса. Первое представление, соответствующее этому Content-Type, будет возвращено клиенту первым. Если цепочка ViewResolver не может разрешить представление, она будет искать в списке представлений DefaultViews. Последний подходит для одноэлементного представления без обработки бизнес-логики, поэтому имя логического представления не учитывается. Подстановочные знаки могут быть включены в заголовок Accept, например.text/ *
, он будет соответствовать типу содержимого какtext/xml
вид .
9. Регион
Как и большинство модулей Spring, Spring MVC также обеспечивает интернационализацию контента. DispatcherServlet может автоматически интернационализировать контент в соответствии с локалью клиента благодаря LocaleResolver.
Получив запрос, DispatcherServlet перейдет к контексту, чтобы найти bean-компонент LocaleResolver, и после его обнаружения он будет использовать его для выполнения задачи интернационализации. RequestContext.getLocale() можно вызвать, чтобы получить запрошенную локаль.
Если вы не хотите использовать метод автоматического синтаксического анализа по умолчанию, вы также можете сделать это, добавив перехватчик в сопоставление обработчика, например синтаксический анализ параметров в URL-адресе.
Парсеры и перехватчики, связанные с интернационализацией, определены вorg.springframework.web.servlet.i18n
, и оба должны быть настроены в контексте приложения. Spring может интернационализировать их:
Часовой пояс
В дополнение к локали иногда необходимо получить информацию о часовом поясе клиента.LocaleContextResolver расширяет функции LocaleResolver, так что в LocaleContext можно получить больше информации.
Информация о часовом поясе клиента получается с помощью метода RequestContext.getTimeZone(), и преобразователи даты/времени и средства форматирования, зарегистрированные в Spring ConversionService, автоматически получают эту информацию.
заголовок запроса
Этот распознаватель зон идентифицируетaccept-language
Заголовок, это поле обычно содержит региональную информацию гостевой операционной системы, но не может получить информацию о часовом поясе клиента.
Cookie
Этот сопоставитель локали проверяет файл cookie на клиенте на наличие информации о языке или часовом поясе. Преобразователь локали может установить имя файла cookie и время истечения срока его действия. Определите CookieLocaleResolver в XML-файле:
<bean id="localeResolver" class="org.springframework.web.servlet.i18n.CookieLocaleResolver">
<!-- 根据具体情况自定义 -->
<property name="cookieName" value="clientlanguage"/>
<!-- 100000 为秒数,值为 -1 时, cookie 会在浏览器关闭时被销毁 -->
<property name="cookieMaxAge" value="100000"/>
</bean>
Значение некоторых свойств CookieLocaleResolver
Атрибуты | По умолчанию | значение |
---|---|---|
cookieName | имя класса + локаль | имя куки |
cookieMaxAge | Значение, указанное в контейнере сервлета | Срок действия файла cookie, при значении -1 файл cookie будет уничтожен при закрытии браузера. |
cookiePath | / | Ограничьте область действия файла cookie указанным относительным путем, файл cookie будет действителен только для этого пути и его собственного пути. |
Session
SessionLocaleResolver может получать информацию о языке и часовом поясе из контекста сеанса. Разница между ним и CookieLocaleResolver заключается в том, что он хранит информацию о языке и часовом поясе в сеансе контейнера сервлета. Вся эта информация является временной и перестанет существовать после завершения сеанса. . . .
блокировщик локали
Компонент LocaleChangeInterceptor может изменять параметры в запросе с помощью пользовательской конфигурации для достижения цели изменения локали. Просто вызовите метод setLocal() в LocaleResolver. В следующем примере показано изменение параметра siteLanguage во всех запросах на голландский:
<bean id="localeChangeInterceptor"
class="org.springframework.web.servlet.i18n.LocaleChangeInterceptor">
<property name="paramName" value="siteLanguage"/>
</bean>
<bean id="localeResolver"
class="org.springframework.web.servlet.i18n.CookieLocaleResolver"/>
<bean id="urlMapping"
class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping">
<property name="interceptors">
<list>
<ref bean="localeChangeInterceptor"/>
</list>
</property>
<property name="mappings">
<value>/**/*.view=someController</value>
</property>
</bean>
10. Темы
Фреймворк Spring Web MVC поддерживает пользовательские темы, и общий вид приложения можно единообразно изменить. Тема — это набор статических ресурсов, обычно CSS и изображений, которые определяют общий стиль приложения.
Определение предмета
должен определитьorg.springframework.ui.context.ThemeSource
Класс реализации интерфейса может использовать функцию темы. По умолчанию WebApplicationContext передаетсяorg.springframework.ui.context.support.ResourceBundleThemeSource
Реализует функциональность темы, которая считывает файлы конфигурации из корня пути к классам. Чтобы использовать пользовательский ThemeSource, настройте префикс имени темы ResourceBundleThemeSource и зарегистрируйте bean-компонент themeSource в контексте приложения.
Чтобы настроить тему с помощью ResourceBundleThemeSource, нужно прописать конфигурацию в файле свойств, который содержит все ресурсы, из которых состоит тема.
styleSheet=/themes/cool/style.css
background=/themes/cool/img/coolBg.jpg
Чтобы использовать настройки темы в JSP, используйтеspring:theme
Этикетка:
<%@ taglib prefix="spring" uri="http://www.springframework.org/tags"%>
<html>
<head>
<link rel="stylesheet" href="<spring:theme code='styleSheet'/>" type="text/css"/>
</head>
<body style="background=<spring:theme code='background'/>">
...
</body>
</html>
По умолчанию префикс имени темы ResourceBundleThemeSource пуст. файлы свойств считываются из корневого каталога пути к классам. Таким образом, файл конфигурации abc.properties должен быть помещен в корневую директорию (/WEB-INF/classes
). ResourceBundleThemeSource может реализовать интернационализацию тем. Например,/WEB-INF/classes/abc_nl.properties
, в сочетании с настройкой свойства background выше, вы можете переключить фон на фоновое изображение с голландским текстом.
Анализ темы
После определения конфигурации темы при отправке запроса на этапе предварительной обработки он вызывается путем поиска контекста.themeResolver
bean-компонент, чтобы решить, какой синтаксический анализатор использовать для анализа объекта, который работает здесь и вышеlocaleResolver
Такой же. Переключает тему запроса, идентифицируя запросы с разными параметрами. Spring предоставляет следующие файлы themeResolvers:
имя класса | Функции |
---|---|
FixedThemeResolver | чтениемdefaultThemeName свойство для выбора фиксированной темы |
SessionThemeResolver | Информация о теме сохраняется по сеансам, каждый сеанс необходимо анализировать только один раз, и его нельзя использовать между разными сеансами. |
FixedThemeResolver | Информация о теме хранится в файле cookie на стороне клиента. |
Весна также обеспечиваетThemeChangeInterceptor
Перехватчик для переключения тем, определяя параметры запроса.
11. Multipart
org.springframework.web.multipart.MultipartResolver
Предоставляет решение для обработки файлов загрузки форм. Существует две реализации: одна основана на Apache Commons-Fileupload, а другая — на Servlet 3.0.
Прежде всего, в файле конфигурации Spring объявите файл DispatcherServlet с именемMultipartResolver
bean, DispatcherServlet автоматически распознает и вызовет его для обработки запроса на загрузку файла. он установит тип содержимого какmultipart/form-data
Запрос упакован какMultipartHttpServletRequest
, тем самым выставляя эти «части» как параметр запроса.
Apache FileUpload
Чтобы использовать Apache Commons-Fileupload, вам необходимоmultipartResolver
бин настроен какCommonsMultipartResolver
, а также не забудьте добавитьcommons-fileupload
зависимость.
Servlet 3.0
При обработке составных запросов через Servlet 3.0 его также необходимо зарегистрировать в DispatcherServlet. Если настроено в коде Java, вам необходимо добавитьMultipartConfigElement
; если настроено в файле xml, добавьте<multipart-config>
узел. Такие параметры, как ограничение размера файла и место сохранения файла, также должны быть настроены таким образом, потому что после Servlet 3.0 не разрешеноMultipartResolver
Так сделано.
После того, как Servlet 3.0 сконфигурирован, вам нужно только добавитьmultipartResolver
hean настроен какStandartMultipartResolver
Вот и все.