Локализованные исключения (в приложении Struts2) - PullRequest
1 голос
/ 13 ноября 2009

Я занимаюсь разработкой приложения Struts 2 с поддержкой нескольких языков. Если один из объектов домена должен выдать исключение, как он может сделать это так, чтобы сообщение об ошибке не зависело от языка? И как позднее это исключение может отображаться в зависимости от текущей локали?

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

Так что мне интересно, как другие люди подошли к этой проблеме. (И я не думаю, что это действительно специфично для Struts 2, но относится к любому многоязычному приложению).

Ответы [ 4 ]

2 голосов
/ 16 ноября 2009

Заметив, что у Throwable есть метод getLocalizedMessage (), я решил использовать это в своем решении.

Мой класс BusinessException расширяет Exception, и его конструктор принимает ключ, представляющий ошибку:

public BusinessException(String key, Object[] arguments) {
    this.key = key;
    this.arguments = arguments;
    this.locale = Locale.getDefault();
}

Как видите, языковой стандарт по умолчанию соответствует стандартному языку JVM. Однако в веб-приложении вместо этого следует использовать локаль текущего запроса. Таким образом, BusinessException предоставляет метод setLocale (), который должен быть вызван перед getLocalizedMessage (). Следовательно, в действии Struts2 идиома выглядит примерно так:

try {
    // call business objects
}
catch(BusinessException be) {
    be.setLocale(ActionContext.getContext().getLocale());
    addActionError(be.getLocalizedMessage());
    return ERROR;
}

Для записи, локализованные сообщения поступают из семейства комплектов ресурсов для класса исключения: BusinessException.properties и т. Д. Приложение Struts2 также имеет комплект ресурсов для всего приложения, но я решил не использовать его, чтобы избежать зависимостей бизнес-объектами в веб-фреймворке.

0 голосов
/ 13 ноября 2009

Зачем вам выбрасывать исключения в сообщениях, специфичных для локали? Я бы постоянно держал их на английском. Вы можете сделать свою страницу ошибки конкретной, однако. Покажите сообщение о конкретной локали о том, что что-то не удалось, и что пользователь должен делать, и что пользователь может найти подробности здесь ниже (вставьте простые английские подробности ошибки здесь). Для основных проверочных сообщений («Это необходимо», «Пожалуйста, введите действующий адрес электронной почты» и т. Д.), Конечно, используйте сообщения, специфичные для локали.

0 голосов
/ 14 ноября 2009

Я предполагаю, что страница ошибок должна использовать локализованные строки для отображения ошибок в соответствии с локалью. Определите ваши стандартные сообщения в соответствующих файлах, относящихся к конкретной локали, и структуры 2 должны отображать их в соответствии с рабочей локалью. (смотрите, как работает s:text).

Чтобы определить конкретный файл локали и место, куда их поместить в приложение, см. Локализация Struts 2

0 голосов
/ 13 ноября 2009

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

try {
   doSomething();

} catch (BusinessException e) {
   LOG.error("Create your error message in English, it's good for logging", e);

   int id = e.getId();
   // internationalize here
}
...