2010-04-04 14 views
6

En GWT uno normalmente cargas cadenas i18n usando una interfaz de la siguiente manera:Cargando GWT mensajes de una base de datos

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

que luego carga las cadenas reales de un archivo deStatusMessage.property:

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

Esta es una gran solución; sin embargo, mi cliente es inamovible en su demanda de colocar las cadenas i18n en una base de datos para que puedan modificarse en tiempo de ejecución (aunque no es un requisito que se modifiquen en tiempo real).

Una solución es crear un servicio asíncrono que tiene un identificador de mensaje y configuración regional del usuario y devuelve una cadena. Lo he implementado y lo encuentro terriblemente feo (introduce una gran cantidad de comunicación extra con el servidor, además de que hace que el reemplazo del marcador de propiedad sea bastante complicado).

Así que mi pregunta es esta, ¿puedo en algún buen camino implementar un proveedor de mensajes personalizado que carga los mensajes desde el servidor de una sola vez (para la sesión del usuario actual). Si también se puede enganchar en el mecanismo de mensaje de GWT predeterminado, entonces estaría completamente satisfecho (es decir, así puedo crear una interfaz como la de arriba y seguir usando el agradable formato de reemplazo de propiedad {0}, {1} ...) .

También son bienvenidas otras sugerencias para mensajes limpios basados ​​en bases de datos en GWT.

Respuesta

3

La clase incorporada de GWT Dictionary es la mejor manera de avanzar. Aquí está el official documentation sobre cómo usarlo.

+1

+1 Esta es una muy buena idea. La idea es que imprimirías un mapa JSON como 'var dict = {'key': 'value'}' en el HTML de la página del host, luego en tu código GWT, llama a 'Dictionary dict = Dictionary.getDictionary (" dict "); 'para obtener el objeto similar a un mapa en su código GWT. –

+0

La forma en que está configurada la aplicación en la que trabajo actualmente, esto sería similar en comportamiento al enfoque de "un solo golpe" que Lars mencionó ya que hay una página de host, por lo que todos los mensajes (miles, en el caso de Lars) ser almacenados y recuperados juntos en un solo archivo. –

1

Digamos que su aplicación tiene 500 mensajes por localidad con un promedio de 60 caracteres por mensaje. No lo pensaría dos veces antes de cargar todo esto cuando el usuario inicie sesión o seleccione su idioma: es < 50k de datos y no debería ser un problema si puede suponer que la conectividad de banda ancha está disponible ... su sugerencia de "una sola vez". Ya lo hago en una aplicación GWT, aunque no son mensajes, sino propiedades que se leen desde la base de datos.

+0

La conectividad de banda ancha no es un problema y la base de datos es rápida. ¿Acabas de cargar todos los mensajes en un singleton justo después de onModuleLoad? (cuando la configuración regional está disponible). Tengo miles de mensajes, por lo que se necesitaría algún tipo de agregación para evitar que las clases de mensajes explotaran en tamaño (por ejemplo, una clase con mensajes específicos para cada vista) –

+1

Bueno, el evento es diferente en mi caso (inicio de sesión de usuario activa la propiedad) cargando en mi caso). Sin embargo, dado que tiene una gran cantidad de mensajes para recuperar, hacer la recuperación para vistas individuales podría tener sentido, como usted dijo. Cuando el usuario accede a una vista, carga los mensajes en una lista estática o asigna un mapa y no tiene que volver a cargarlo en cada acceso de página para un determinado usuario. Si sus puntos de vista extienden una clase principal común (como es el caso en la aplicación en la que estoy trabajando), probablemente pueda salirse con la suya al agregar una clase intermedia y contener toda la lógica y estructuras de datos allí. –

1

creo que se puede encontrar este artículo útil: 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

Lo que podría hacer es crear un TextResource y luego, sólo podría cambiar el texto en tiempo de ejecución. No lo he intentado pero estoy seguro de que esto funcionará.

+0

No es una mala idea, intentaré implementar un recurso que cargue los mensajes en formato JSON desde el servidor a través de una API REST. –

0

Para optimizar el rendimiento, puede colocar sus mensajes en un recurso js, ​​por ejemplo: http://host.com/app/js/messages.js?lang=en, luego asignar este recurso a un servlet que tomará el diccionario de mensajes de su caché (un bean singleton, por ejemplo) y escriba a la respuesta.

Para optimizar aún más, puede:
- poner un parámetro a la URL del recurso, por ejemplo:? .../messages.js lang = es la versión & = {fecha de última actualización de los mensajes}
- {última fecha actualizada de mensajes} se almacena en algún lugar en DB
- siempre que el usuario actualice los mensajes, {la última fecha actualizada de mensajes} cambiará
- en la respuesta al navegador, configure Cache-control como desee decirle al navegador almacenar sus mensajes en caché

Cuestiones relacionadas