No se por qué lo llamamos "internacionalización"... Si viene diciéndose traducción o doblaje de toda la vida. Pero nada, nada, la cosa es poner letra por letra la misma palabra y a españolear.
Pues nada que, tonto de mí, iba a hacer un par de funciones para poder internacionalizar mi javascript y, de paso, hacer un favor a la línea en la que trabajo en Capgemini para facilitar la separación de javascript incrustado de las jotasepeses... Es una lacra que tenemos que pagar para entregar a tiempo. Símplemente se escribe el javascript, o peor, se copia de otra página.
Pocas cosas aprendí de mi empresa anterior salvo que, a veces, puede ser útil tener a alguien revisanding el código que se hace. La verdad es que para revisar el código aquí, aparte de que, como en la anterior empresa, no hay nadie con la capacidad técnica (me incluyo entre los incapaces) se necesitarían varios a tiempo completo ya que la cantidad de código generado en una línea en un día es inabarcable para un refactor bien estudiado. Pero se debería hacer para evitar tanta repetición y tantas barbaridades y patadas a las biblias (si las hay) de esto del desarrollo web.
Cada línea de javascript que se escribe es un paso a la tumba. Hay quien dice que así, en cliente va todo más rápido y casi sin frotar... Pero es que hay que depurarlo y cuando se corta y se pega en otra página hay que depurarlo dos veces... Y cuando se corta y se pega en otra página y, además, se modifica para que cuando pintaba X ahora ponga Z pues hay que depurar las dos de antes y seis más para que lo nuevo quede bien.
Yo soy más de aquel tutorial por el que parece que nadie ha pasado ya. Si se lee bien, te enseñan por qué usar JSPs, qué es un documento JSP en contra de una página JSP... Qué es un Servlet y por qué no usar más de uno. Además de proponer todos los patrones de diseño que ahora implementa Struts y que se citan en este libro que tengo por ahí de una vez que me volví loco y me dio por comprar libros.
En el tutorial, aparte de usar un controlador y el patrón command o delegate (hay que tener en cuenta que explican cómo usar Java y no una librería de terceros como es Struts, pese a que Sun se implica en el desarrollo de Struts) y de todas las pariditas que a uno se le ocurran, dicen expresamente que las páginas JSP (mejor usar documentos JSP) deberían poder ser escritas por alguien que no tenga ninguna capacidad como programador. Cualquiera con Dreamweaver o Notepad y un poco de idea sobre lo que es un tag HTML debería poder aprender a maquetar para nuestra aplicación. Así que antes de ponerse al meollo habría que pasear el documento funcional, las maquetas y las descripciones de su funcionamiento por los “expertos” en presentación o por alguien que decida qué tags hay que implementar.
El resultado de esta preparación seria una o varias librerías de etiquetas (custom tags) con sus correspondientes ficheros javascript. Todos estos se pueden incluir como librerías en Dreamweaver, Eclipse, Netbeans o a puro ojo en las maquetas con el edit de la línea de comandos.
El maquetista aprenderá a utilizar las etiquetas y a marcar tal o cual opción. Los TLD hoy dia son bastante descriptivos llegando incluso a presentar al cliente (maquetista) los posibles valores para los atributos de la etiqueta.
Visto así nunca haría falta escribir una sóla línea de javascript en las páginas. Salvo, por ejemplo, cuando sea estrictamente necesario. Un ejemplo de esto sería cuando usando Dojo queremos filtrar los parámetros que uno de los tags de Struts2 deberá enviar al servidor para actualizar un DIV pro Ajax…
Bueno… Dada la turria esta que acabamos de tener… Que me he salido totalmente del tiesto, etc… Volvemos al tema.
En mi trabajo ahora mismo utilizo, incluso, Struts1.1. Raro, me decían, que no trabajéis con una beta, ya que las empresas son tan estúpidas de utilizar herramientas tan anticuadas aun siendo gratuitas y no habiendo cambiado su funcionalidad ni las interfaces sino mejorado con el tiempo. Ahora mismo podríamos tener la versión posterior con más bugs corregidos y más facilidades de uso como DownloadAction, cosa necesaria para mis planes y para unas pariditas que he estado haciendo esta semana exportanding cartas en formato PDF…
La cosa estaría en poder internacionalizar el javascript. Actualmente uno de los mayores problemas que tenemos es que en el javascript incrustamos valores que vienen de la petición. Aún hay doctorandos (tócate los cojones) que quieren acceder a la request desde código ejecutado en el cliente (eso es javascript). Tontos aparte, todos sabemos que javascript es texto y, una vez escrito, salvo con algún eval() no se puede cambiar. Así tenemos parámetros a funciones o valores de variables sacados con escrituras de EL (Expresión Language) en mi caso y en el de la gente que trabaja conmigo a los que invito a aprender un poco más, que siempre es bueno. También hay quien escribe scriplets y le cortamos las manos o le dejamos por imposible y le reescribimos lo que haga para no enfadarle porque, encima, se enfadan. Tambien se escriben con bean:write.
La cuestión es que si queremos extraer el javascript de las páginas tendremos que declarar funciones con muchos parámetros para poder pasarles estos valores en su llamada. Los valores se pintarán en la JSP en la sentencia que llama al javascript que estará incluido en un fichero .js.
¿Y los mensajes al usuario? Pues lo mismo. Siempre se pintan con bean:message, ${el} (o con scriplets, no puedo vigilar todo lo que se hace). Y tenemos el mismo batiburrillo. Así que una función para validar un formulario una vez pasada a un fichero externo va a tener una interfaz enorme de la forma:
validate( document.forms[‘miform’], msg1, msg2, msg3, msg4 …);
Porque puede haber muchísimos mensajes de error.
Bueno, pues la solución que se me ocurrió es hacer una función javascript que se descargue los recursos de la aplicación ya internacionalizados (que pasen por la parte online) y que pinte el String que corresponda con la clave que se le de.
Surgen problemas, cada petición de un string a la función generará una petición de los recursos… Esto se puede saltar porque se puede hacer la petición con http GET para que no se cachee en el cliente. Si es que se ha configurado el controlador con parámetros para saltarse la caché del cliente, se podría configurar otra instancia del consolador o un servlet aparte que haga sólo de servidor de recursos.
Así que con una sóla función podríamos internacionalizar la aplicación completa. Pero aun así me estan comiendo los problemas… Tenemos problemas porque el cliente no va a permitir estas chorraditas. Son pariditas molonas pero me se salen del framework, muchacho y como pa hacerme entender el argumento a estas alturas de la película. A mi ponme un solo servlet y no se te ocurra escribir los recursos al cliente que te caneo… Y ya podrás argumentar y regatear que te van a cortar las alas.
Además esto va un pelín en contra de aquello que escribí arriba muy arriba de no ser intrusivo con la página. Cuanto menos código escribamos en la jsp mucho mejor. Una línea menos de javascript, un peldañito más al cielo… Y jQuery se hizo.
Ni por el forro de los jueves podríamos usar jquery en un proyecto. Los clientes se nos iban a chiflar y no veas de qué manera… Bueno, eso también pasa por preguntar y no meterlo sin decir nada a ver si ni lo miran… Pero bueno… Tenemos el problema.
Pero qué cojones. Voy a dejar de ayudar a la empresa y hacer como aquel fulano griego: Ayúdate a ti mismo. Para mis propósitos, si alguna vez tengo que pintar javascript internacionalizado, voy a utilizar jquery, cosa que intento aprender y este plugin para poder incluir mensajes. Además mi acción para descargarme recursos desde el cliente sigue siendo útil: Incluso el plugin jquery me envía el locale del cliente por si no le gusta el que su navegador envía en la petición.
Así quedará una página del tipo holamundo con jquery, el plugin y mi action de descarga de recursos:
Las peticiones hechas por el cliente vistas con firebug:
Y la página en pantalla:
Quod erat demostrandum ^g^
