Fue un desarrollo exprés, ya que tenía otros compromisos que no podía dejar de lado. Fueron unas 6 o 7 horas de trabajo a tope ese mismo fin de semana, pero me apetecía colaborar por fin con algún medio, aunque fuera tan pequeñito como lo es arredol .

Herramientas utilizadas:

• El API que puso a disposición El País. Que básicamente hizo el trabajo que según los que defendemos el OpenData debería ser responsabilidad del Ministerio del Interior, poner a disposición de cualquier persona o entidad esos datos de forma estructurada para poder procesarlos.
• El API de Google Charts para las representaciones gráficas. No pude adaptar los colores por partido por las limitaciones que tiene, o al menos no logré dar con la solución.
• En el lado del servidor PHP y simplexml para procesar la información de El País. Básicamente por que el hosting de arredol sólo soporta php, no por otra cosa en especial.

Como podréis comprender, por haber sido un pequeño desarrollo hecho a toda prisa, el código en general es muy mejorable; pero el resultado cara al usuario creo que no está del todo mal.

Seguramente fuera una solución muy alejada de las herramientas de visualización de algunos grandes medios de comunicación, con una posibilidad de interacción mucho mayor. Pero en Aragón quizás fuera de lo mejor, cosa que casi me entristece.

No vi que tuviera mucho que envidiar a lo que vi que hicieron por ejemplo en la web de Heraldo, y no digamos de El Periódico de Aragón donde no vi nada especial para la ocasión… Supongo que no dedicarían muchos esfuerzos…

Hace unos pocos días nos encontramos uno de esos problemas curiososos. Resulta que teníamos varios mapas en una misma página, dentro de la que habían mapas en capas ocultas usando css. La curiosidad en cuestión es que al hacer visibles esas capas no se pintaban correctamente los mapas.

Buscando un poco que podría estar pasando, resulta que cuando creas el mapa google maps coge los estilos que hay en ese momento, y al pasar de oculto a visible el API no es consciente que ha cambiado la visibilidad del elemento que lo contiene y donde se pinta.

Esto en la V2 del API se solucionaba usando checkResize, pero resulta que para V3 no está disponible ese método para notificar al mapa que se redimensione.

La necesidad de un checkResize está reportado como bug de la versión 3. Pero por suerte en los mismos comentarios aparecen algunas soluciones que me han venido como anillo al dedo para ir trasteando y terminar implementando una solución un poco más a mi gusto, añadiendo a la clase de google.maps.Map un comportamiento equivalente:


google.maps.Map.prototype.checkResize = function() {
   var center = this.getCenter();
   google.maps.event.trigger(this, 'resize')
   this.setCenter(center);
}


Y así ya puedo utilizar el checkResize en los mapas del mismo modo que en la versión 2.

Cuando pretendamos sacar partido de las nuevas características de HTML5 debemos tener en cuenta que cada navegador puede soportar sólo algunas especificaciones, no es un todo o nada, por lo que lo primero que deberemos hacer es comprobar que soporta la especificación que queremos usar, por ejemplo:

function supports_local_database() {
return !!window.openDatabase;
}

Si existe openDatabase, crearemos la conexión a la base de datos:


db = openDatabase('dndzgz', '1.0', 'DNDzgz', 65536);

Una vez abierta la conexión, podremos ejecutar cualquier tipo de query SQL(compatible con SQLite), dentro de una transacción. Por ejemplo crear una tabla:

db.transaction(
function(transaction) {
transaction.executeSql(
'CREATE TABLE IF NOT EXISTS favorites ' +
' (id INTEGER NOT NULL, ' +
' service VARCHAR(255) NOT NULL, ' +
' date DATE NOT NULL,' +
' name VARCHAR(255) NOT NULL, ' +
' latitude REAL NOT NULL, ' +
' longitude REAL NOT NULL, ' +
' PRIMARY KEY (id,service));'
);
}
);

Insertar datos:

db.transaction(
function(transaction) {
transaction.executeSql(
'INSERT INTO favorites (id, service, date, name, latitude, longitude) VALUES (?, ?, ?, ?, ?, ?);',
[id, service, new Date(), name, latitude, longitude],
callBack,
errorCallBack
);
}
);

Eliminar datos:

db.transaction(
function(transaction) {
transaction.executeSql('DELETE FROM favorites WHERE id=? AND service=?;',
[id,service], null, errorCallBack);
}
);

Y por supuesto mostrarlos:

db.readTransaction(
function(transaction) {
transaction.executeSql(
'Select * from favorites;', [],
function(transaction, result){
for (var i=0; i < result.rows.length; i++) {
var row = result.rows.item(i);
alert(row.name);
alert(row.service);
}
},
errorCallBack
);
}
);

Como podéis ver, a executeSql se le pasa primero la query, seguidamente un array con los valores de los argumentos de la query, y finalmente una función de callback y otra de callback para el caso de que existan errores. Y existen dos tipos de transacciones: transaction y readTransaction, la primera es de lectura-escritura, mientras que la segunda es de sólo lectura.

En fin, supongo que a otros también os pasará lo mismo, resulta bastante raro estar tirando queries SQL desde javascript. Pero puede resultar útil para muchos casos, empezando por descargar de responsabilidades y carga al lado servidor.

La elección de GAE fue casi instantánea cuando empezamos a hablar con gimenete acerca de presentarnos al AbreDatos, las razones: hosting gratis y capacidad de escalar mucho sin tener que gastarnos ni un euro, despreocuparnos de la parte de sistemas, ningún problema con las limitaciones por correr sobre la plataforma de Google.

Que usáramos Python, aún siendo más javeros que otra cosa, fue por que ninguno de los 2 teníamos experiencia con GAE en Java(okok, yo había hecho un pequeño experimento, pero muy poca cosa para llegar a ninguna conclusión). Por eso preferimos aprovechar su experiencia desarrollando la primera versión de debug_mode=ON con Python+GAE; mientras que varias semanas antes yo me ojeé un par de manuales de inicio rápido, retomé el ebook Python para todos que tenía a medio leer(hace muuuucho ) y un par de días antes, me hice en poco rato el proyecto de ejemplo de GAE. Para extraer los datos utilizamos tanto Beautiful Soup como expresiones regulares para hacer scraping de HTML o Javascript de Tuzsa y Bizi, y simplejson para cargar los datos JSON de datos.zaragoza.es.

Que utilizáramos jQuery como framework Javascript, fue una elección posterior a jQTouch(que está basado en jQuery) pero de todas formas, seguramente lo hubiéramos elegido. Google Maps es la elección “por defecto” para todo el que quiere hacer algo con mapas . Gimenete es quien estuvo peleando con esto, teníamos problemas con la fluidez en la navegación de los mapas, que al final consiguió mejorar… Eso sí, fuera del navegador Safari del iPhone no conseguimos que los mapas funcionaran correctamente, ni en terminales con distintas versiones de Android y ni si quiera en el Safari de Mac(tenemos que ver que pasa exactamente, tras algunas pruebas, el sospechoso principal es jQTouch).

Gracias a que iPhone(y las últimas versiones de Android) soportan parte de HTML5, se ponían a nuestra disposición algunas de esas novedades que molan tanto (Flash, tiemblaaa!! ):

• La posibilidad de geolocalizar al usuario por medio del GPS del terminal (no es exactamente HTML5, pero parece que la mayoría lo ponemos en el mismo saco) muy fácilmente utilizando navigator.geolocation.
• Para implementar los favoritos/acceso rápido estuvimos usando Web SQL Database, lo que supone guardar los datos en una base de datos embebida al navegador web(actualmente parece que en todos es SQLite, o al menos parece ser la implementación de referencia), que finalmente se quedó fuera por falta de 3/4 horas :S.

En fin, que debemos molar, porque nuestro proyecto es una pequeña colección de buzzwords: Cloud Computing vía Google App Engine, HTML5, iPhone… XD

Si lo único que quisieramos probar es que, en una cadena JSON, se está devolviendo algún valor que estuvieramos esperando, podríamos utilizar el contenido que devuelve la response como una cadena(con contentAsString) y hacer alguna comprobación sobre el texto:

def response = controller.response.contentAsString
assertTrue response.contains('"name":"Gustavo Poyet"')
assertTrue response.contains('"goals":63')


Pero claro, este test es un muy ligero y no prueba demasiado. Si quisieramos probar más a fondo la respuesta(estructura, un elemento concreto de un array, etc), podríamos usar contains sobre la cadena devuelta, convertir tipos… vamos, que sería más que posible que el código del test terminara siendo infumable. Pero está disponible out of the box el converter JSON de Grails, que permite testear más a fondo fácilmente y con un código mucho más claro.

Es muy posible que si alguien se ve en la necesidad de escribir un test para una acción que devuelve un JSON, ya conozca el converter, por que es una de las alternativas que hay para hacerlo:

render object as JSON

Pues esa misma clase, tiene el paso contrario, pasar una cadena a un objeto groovy/java(JSONElement). De esta forma ya nos ahorraremos trabajo sucio y el código quedará bastante claro:

def response = controller.response.contentAsString
def responseJSON = grails.converters.JSON.parse(response)
assertNotNull responseJSON.players
assertEquals 5, responseJSON.players.size()
assertEquals 63, responseJSON.players[0].goals
assertEquals "Gustavo Poyet", responseJSON.players[0].name


Después de refactorizar nuestro código javascript dependiente de prototype, donde hemos encontrado que hay efectos muy sencillos de implementar gracias a script.aculo.us que no lo son tanto con YahooUI(la librería Effects Widget nos ha ayudado en esta transición), nos encontramos que teniendo en el layout la declaración de qué librería deben usar para renderizar esos taglibs de Ajax, en las vistas seguía haciéndolo con el código para prototype, por lo que daba errores javascript. Para que en cada vista renderizara usando el código de YUI, debemos poner la declaración <g:javascript library=”yui” /> en cada vista, yendo con cuidado en el orden de las dependencias, ya que si hay un <g:javascript library=”yui”/> en el layout y en la vista sólo se renderizará el segundo, por lo que habría que hacer algo así:

En el layout:
<g:javascript library="yui" />
<g:layoutHead />
<yui:javascript dir="..." file="..." />
<yui:javascript dir="..." file="..." />
<g:javascript library="application" />

En la vista:
<g:javascript library="yui" />
<yui:javascript dir="..." file="..." />

En este orden se renderizarán primero las dependencias básicas de la librería YUI, luego las que necesitemos para usar componentes, y por último nuestro propio código que puede depender de algún componente.

En fin, no es una solución DRY, pero funciona para los pocos casos en los que lo necesitamos.

Otra de las soluciones de las que nos hemos ayudado, como muchos seguro que imaginaréis , es implementar una función $(), que aunque no nos dé las bondades de las extensiones DOM de prototype, nos ha ayudado a tener que cambiar mucho menos código:

function $(id){ return YAHOO.util.Dom.get(id)}

Pues resulta que cuando intentaba crear una nueva validación a un textarea concreto en un formulario, me daba un error:

LiveValidation::getElementType – Element must be an input, select, or textarea!.

A base de “debuggar” el código de la librería vi que al final la causa era porque ese textarea tenía un id=description, y al hacer la comprobación de si el elemento con ese id es un input, un textarea o un select devolvía un meta por el meta name=description… del header.

La solución tan sencilla como cambiar el dichoso id y seguidamente informar a los autores de la librería sobre el bug.

Lo típico es hacerlo en el evento onload del body o poniendo las llamadas a nuestras funciones javascript dentro del código para que se vayan ejecutando mientras se carga la página, ésta sería la forma intrusiva de hacerlo, la forma no intrusiva sería utilizar window.onload.

window.onload = mifuncion();

Hay un problema que fácilmente nos puede surgir, cuando tenemos varias asignaciones a window.onload, ya que se ejecutará sólo la última.

En un principio se me ocurrió solucionarlo con una asignación común para toda la web, el problema es evidente, para una web más o menos grande llegaría a ser una macro-función, además de ser una solución nada elegante.
Al final a googleando un poco, acabé encontrando la solución en el blog de Robert Hahn, donde plantea tres formas de hacerlo para “que funcione”, y una solución que al parecer es la ideal, simplemente es asignar a window.onload ésta función que nos devuelve una función anónima:

function makeDoubleDelegate(function1, function2) {
return function() {
if (function1)
function1();
if (function2)
function2();
}
}

Para probarlo simplemente con éste código, podemos ver que funcina correctamente:

window.onload = makeDoubleDelegate(window.onload, alert('1'));
window.onload = makeDoubleDelegate(window.onload, alert('2'));
window.onload = makeDoubleDelegate(window.onload, alert('3'));

Pues resulta, que Hijax, es una “técnica” de uso de Ajax(y javascript en general) para realizar desarrollos accesibles, que se basa en no utilizar javascript hasta que no esté desarrollado el funcionamiento accesible, y una vez que introduzcamos el uso de javascript éste no sea intrusivo.

En mi opinión a raíz de lo vivido en carnes propias, es la mejor forma de enfocar un desarrollo que tenga como requisito ser accesible, ya que considero más sencillo desarrollar los efectos y añadidos a posteriori, que definir una forma accesible de uso de una aplicación sin haberlos tenido en cuenta desde el inicio, ya que puede suponer prácticamente un doble desarrollo. Y siendo egoístas, como desarrolladores, corremos el riesgo de que ese tiempo de trabajo extra no esté planificado, y luego pasa lo que pasa.