2010-04-04 2 views
6

В GWT один обычно загружает i18n строки, используя интерфейс, как это:Загрузка GWT сообщений из базы данных

public interface StatusMessage extends Messages { 
    String error(String username); 
    : 
} 

, который затем загружает фактические строки из StatusMessage.property файла:

error=User: {0} does not have access to resource 

Это отличное решение, однако мой клиент не может претендовать на то, чтобы поместить строки i18n в базу данных, чтобы их можно было изменить во время выполнения (хотя это не требование, чтобы они были изменены в реальном времени).

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

Итак, мой вопрос в том, могу ли я в славном способе реализовать пользовательский поставщик сообщений, который загружает сообщения из бэкэнд одним крупным махом (для текущего сеанса пользователя). Если он также может подключиться к механизму сообщений GWT по умолчанию, тогда я был бы полностью доволен (т. Е. Я мог бы создать интерфейс, как указано выше, и продолжать использовать приятный {0}, {1} ... формат замены собственности) ,

Другие предложения по чистым сообщениям, управляемым базой данных в GWT, также приветствуются.

ответ

3

Класс GWT Dictionary - лучший способ двигаться вперед. Вот как это сделать: official documentation.

+1

+1 Это довольно хорошая идея. Идея состоит в том, что вы распечатываете карту JSON, такую ​​как 'var dict = {'key': 'value'}' в HTML-странице хоста, затем в своем коде GWT вызовите 'Dictionary dict = Dictionary.getDictionary (" dict "); 'для получения объекта, подобного карте, в вашем коде GWT. –

+0

Как работает приложение, над которым я работаю в настоящий момент, это похоже на поведение, основанное на методе «одного маха», которое упоминается Ларсом, поскольку есть одна страница хоста, поэтому все сообщения (в том числе, в случае с Ларсом) сохраняться и извлекаться вместе в одном файле. –

1

Предположим, ваше приложение имеет 500 сообщений на языковой стандарт в среднем по 60 символов в сообщении. Я бы не подумал дважды о загрузке всех этих данных, когда пользователь входит в систему или выбирает свой язык: это < 50 тыс. Данных и не должно быть проблемой, если вы можете предположить, что доступ к широкополосной связи доступен ... ваше предложение «одного маха». Я уже делаю это в одном приложении GWT, хотя это не сообщения, а свойства, которые считываются из базы данных.

+0

Широкополосная связь не является проблемой, и БД быстро. Вы просто загружаете все сообщения в одноэлемент сразу после onModuleLoad? (когда локаль доступна). У меня есть тысячи сообщений, поэтому потребуется некоторая форма агрегации для того, чтобы классы сообщений были взломаны по размеру (fx. Класс с сообщениями, специфичными для каждого представления). –

+1

. В моем случае это событие отличается (свойство login login пользователя погрузка в моем случае). Однако, учитывая, что у вас достаточно большое количество сообщений для извлечения, выполнение поиска для отдельных просмотров может иметь смысл, как вы сказали. Когда пользователь обращается к просмотру, вы lazy-load сообщения в статическом списке или карту не должны перезагружать его для каждого доступа к странице для определенного пользователя. Если ваши представления расширяют общий родительский класс (как в случае приложения, над которым я работаю), вы, вероятно, можете уйти с добавлением класса между ними и содержать всю структуру логики и данных. –

1

я думаю, что вы могли бы найти эту статью полезной: http://googlewebtoolkit.blogspot.com/2010/02/putting-test-data-in-its-place.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed:+blogspot/NWLT+(Google+Web+Toolkit+Blog)&utm_content=Google+Reader

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

+0

Это неплохая идея, я попробую реализовать ресурс, который загружает сообщения в формате JSON с сервера через REST api. –

0

Чтобы оптимизировать производительность, вы можете поместить свои сообщения в ресурс js, например: http://host.com/app/js/messages.js?lang=en, затем сопоставить этот ресурс сервлету, который возьмет словарь сообщений из вашего кеша (например, один элемент) и напишет это ответ.

Для оптимизации даже больше, вы можете:
- поставить параметр в URL ресурса, например: .../messages.js языки = еп & версии = {последняя дата обновления сообщений}
- {последняя обновленная дата сообщений} хранится где-то в БД
- всякий раз, когда пользователь обновляет сообщения, {последняя обновленная дата сообщений} изменяет
- в ответ на браузер установите Cache-control, как вы хотите сообщить браузеру кешируйте свои сообщения.

Смежные вопросы