Global implementation of spring

As an open-source framework, Spring provides support for internationalization. When it comes to internationalization, some people think it is of little use because it is only from the perspective of language. Indeed, if only Simplified Chinese is enough, it is not necessary to use internationalization, but another feature of internationalization is very useful for us. That is, unified management of prompt information.

We can write all the prompts in the international resource file in a unified manner, and it also supports dynamic input parameters, that is, you can write a prompt template, dynamically generate prompts based on parameters. This will not only avoid gibberish caused by code file encoding, but also take effect directly after modification without restarting the project or re-compiling. There are many advantages. The disadvantage is that the performance is not directly written in the code ).

So today we will introduce spring's national support.

I. browser-based internationalization Configuration

Use spring MVC and configure the resource file.

XML Code

<! -- Resource file binder --> <bean id = "messagesource" class = "org. springframework. context. support. resourcebundlemessagesource "> <property name =" basename "value =" message-Info "/> <property name =" usecodeasdefaultmessage "value =" true "/> </bean>

Here, message-info is the common name of your properties file. For example: My configuration file is called message-info.properties, message-info_zh_CN.properties and so on. In addition, you can use cacheseconds to specify the resource File Cache Time (that is, Dynamic Refresh) and defaultencoding to specify the encoding format.

With this configuration, and then configure the JSP Renderer to be supported by jstl, you can use the FMT tag in your JSP file to internationalize your browser language.

For example:

<fmt:message key="info.login.title" />

The info. login. Title corresponds to your resource file.

Another method is to use the labels provided by spring to display international information, such:

<spring:message code="main.title" /><br> <input type="button" value="<spring:message code="main.title" />"/><br>

Ii. Dynamic Loading-based internationalization Configuration

1. Request-based internationalization Configuration

Request-based international configuration means that the international configuration takes effect in the current request. Otherwise, the browser is automatically used.

The configuration method is as follows:

First configure the interceptor

<! -- The interceptor must be configured for international operations and can be used in other international ways --> <bean id = "localechangeinterceptor" class = "org. springframework. Web. servlet. i18n. localechangeinterceptor"/>

In this configuration, whether the request level is internationalized, the cookie level is internationalized, or the session level is internationalized, this interceptor must be configured, otherwise it will not be available.

After the interceptor is configured, inject it into your urlhandlermapping, for example;

XML Code

<bean id="defaultUrlMapping" class="org.springframework.web.servlet.handler.BeanNameUrlHandlerMapping">　　<property name="interceptors" ref="localeChangeInterceptor" />　　<property name="order">　　　　<value>1</value>　　</property></bean>

At this time, whenever there is a request that meets the urlmapping, it will be blocked and the configuration of international parameters will begin.

<bean id="localeResolver" class="org.springframework.web.servlet.i18n.AcceptHeaderLocaleResolver"></bean>

The default parameter name is locale. It contains your submission parameters. For example, en_us, zh_cn, and so on. At this time, you can add <a href = "? Locale = zh_cn "> Simplified Chinese </a>

If your resources are full of recommended Chinese configurations, it will become a simplified Chinese pull.

If an exception "cannot change HTTP accept header-use a different locale resolution strategy" is generated, the root cause is that spring source imposes restrictions. The solution is as follows:

public class MyLocaleResolver extends AcceptHeaderLocaleResolver {private Locale myLocal;public Locale resolveLocale(HttpServletRequest request) {return myLocal == null ? request.getLocale() : myLocal;}public void setLocale(HttpServletRequest request, HttpServletResponse response, Locale locale) {myLocal = locale;}}

Modify the localeresolver configuration in the configuration file, and point the class to this class.

2. Session-based internationalization Configuration

The Interceptor is the same as the request-based one.

The session configuration is as follows:

<bean id="localeResolver" class="org.springframework.web.servlet.i18n.SessionLocaleResolver"></bean>

In the controller you process, generate the submitted locale field information to a real locale object, and save the object in the session. The default saved ID is sessionlocaleresolver. locale_session_attribute_name.

In this way, when your session does not expire, the language type will always be correct. I have always used it like this. I think it is better for the session, and I am very satisfied with it.

3. Cookie-based international configuration

I will not talk about this, but I will not use much of it anyway. At least I will not use cookies for my projects. Therefore, I will not elaborate on the cookie-based internationalization configuration. The configuration is as follows:

<bean id="localeResolver" class="org.springframework.web.servlet.i18n.CookieLocaleResolver" />

Iii. Notes

If you do not use the default browser language internationalization method, you must configure the Interceptor. If you have multiple urlmapping, each of them must be configured with an interceptor.

As for the name of the configured localeresolver, you must use the name localeresolver in the configuration above. Of course, this is the default name. You can set it to something else, but it is troublesome, anyway, I feel good when I use the default one.

In addition