BeOSmAn's Blooog

Una de las cosas que más me ha llamado la atención estos días, por su simplicidad y potencia a la vez, ha sido WWW SQL Designer.

WWW SQL Designer es una aplicación Web hecha en Javascript que te puedes descargar para que funcione desde tu ordenador y sirve para hacer diseños sencillos de tablas y relaciones de bases de datos.

Desde el propio navegador puedes crear tablas, añadir campos a las tablas de diferentes tipos y añadir relaciones entre campos de diferentes tablas.

Luego, estos datos se pueden guardar en XML o se puede generar el SQL para distintas bases de datos entre las que están MySQL y PostgreSQL. Eso sí, el XML no se puede guardar en un archivo sino que se genera para que tú lo guardes en un archivo local (recordemos que Javascript no puede acceder a otros archivos del ordenador que no sean las cookies) aunque también tiene la opción de guardar tu diseño en su servidor. Por supuesto, también se puede cargar un diseño en XML (el mismo que se generó anteriormente) ya que en cada recarga del navegador se pierden los cambios.

Lo que realmente me gusta de esto no es que sea vía Web, para nada, de hecho en Firefox en Linux va de pena mientras que en Firefox en Windows va muy bien. Lo que realmente me gusta es la sencillez tanto de manejo como de opciones. Es decir, en muy pocos pasos tienes un pequeño diseño válido para cualquier aplicación pequeña (pongamos… un blog ).

Y es que esta sencillez no la he encontrado en otros programas que tienen más opciones, que generan mejor el SQL y, sobre todo, que son más caros. En Linux hay algunos, pero ninguno tan sencillo como este. Por supuesto, para diseños grandes o hazlo a mano (cosa que recomiendo, así siempre tendrás el control sobre las tablas) o búscate/cómprate un programa profesional.

¿Y a vosotros qué os parece esa aplicación? ¿Alguna mejora? ¿Algún programa similar a este para el escritorio?

La solución propuesta en varios sitios (donde lo vi) para solucionar el problema de las imágenes PNG en Internet Explorer 6 no es una buena solución porque es extremadamente lenta. Hay que darse cuenta de que, para cada imagen, ya sea <img src="..." /> en el HTML o cada elemento background-image o background que lleve el CSS , hay que ejecutar el archivo .htc con lo que hay que ir al servidor, bajarlo y ejecutarlo. Por cierto, donde está la caché cuando se la necesita…

A mi no me ha quedado otra que rendirme. Pues sí, qué queréis que os diga. Prefiero que en IE se vean peor las imágenes (ojo, siempre que no sean fondos espectaculares y tu web se base en el diseño en lugar de en la funcionalidad) pero ganar en velocidad; en mucha velocidad.

Es por eso que la otra solución que propongo es: primero, convertir todas las imágenes a formato GIF (por eso de que tengan, al menos, algo de transparencia, aunque se pueden convertir al formato que se necesite). Esto se puede hacer mediante el comando convert en Linux:

diego@dbox:~/projects/MyApp/public/images/:$ find -name ‘*.png’ | while read; do name=`basename $REPLY .png`; convert $REPLY ${name}.gif; done

Una vez hecho esto, nos creamos otro archivo CSS específico para IE donde sólo estén los selectores donde se usa background o background-image. Además, en estos selectores se debería eliminar el resto de código CSS para minimizar el ancho de banda usado por el nuevo CSS. Luego, lógicamente, cambiados todas las referencias a imágenes en PNG por las referencias a las imágenes en GIF.

Para incluir este CSS sólo en IE usamos el truco de inclusión condicional (sólo válido para IE, obviamente):

<!––[if lte IE 6]>
<link rel=”stylesheet” type=”text/css” href=”ie.css” media=”all” />
<![endif]––>

Y para las imágenes dentro del HTML usamos un poco de javascript (yo, personalmente uso jQuery):

$(“document”).ready(function() {
$(“img”).each(function() {
var src = $(this).attr(“src”);
src = src.substring(0,src.length-4);
$(this).attr(“src”,src + “.gif”);
});
});

Esta no es ni de lejos la solución definitiva y, ni muchos menos, es una buena solución, pero es mucho más rápida que la solución del archivo .htc porque una de las cosas que hace es que sí que usa la caché para las imágenes, con lo que después de cargarlo la primera vez, las siguientes van más rápido.

Ahora sois vosotros los desarrolladores los que tenéis que decir qué os interesa más, si que vuestra página se vea perfecta en IE a costa de sacrificar la velocidad, o que vaya rápido a costa de sacrificar vuestro diseño. Yo, en este preciso caso, elegí la velocidad. La proxima vez ya se verá.

Como se puede ver un poco por la falta de entradas en el blog, vuelvo a estar de vacaciones (las dos semanas que me quedaban). Pero siempre tengo algún rato para dedicarle a esto de la informática friki.

Y, como no, aquí tenéis un ejemplo. ¿Os acordáis de esos relojes que puse por aquí llamados Pim Watches? Pues aquí tenéis una simulación hecha en javascript:

Espero que funcione en todos los navegadores porque yo sólo lo he probado en Firefox y Chrome para Windows. En IE 6, por supuesto, no funciona.

Podéis, además, hacer click dentro de él para ver algún efecto que otro de las lucecitas que también se produce una vez por minuto.

Ahora a ver si tengo más tiempo y lo preparo como un plugin de jQuery o algo similar y así se puede poner en cualquier página web además de poder configurar varios aspectos como los efectos, el tiempo entre cada efecto, etc. También, por supuesto, tengo que añadir más efectos (todavía no me he puesto a hacer la espiral) y más colores para las luces y el fondo. Y a ver si se me ocurre algo para añadirle un segundero.

Por cierto, la hora se lee de la siguiente forma: la primera columna crece de abajo a arriba e indica la hora que es en formato de 12 horas según los números de la izquierda. Las siguientes 5 columnas crecen de izquierda a derecha de abajo a arriba indicando los minutos que van de la hora. Cuando una fila de las 5 últimas columnas está toda iluminada, indica que han pasado tantos minutos como indica el número de la derecha.

Y lo siguiente no es hacer otra simulación, lo siguiente es comprármelo…

Hoy toca un poco de desarrollo web, y como ejemplo voy a poner un listado (de lo que queráis) en una tabla con varias columnas y ordenable tomando como criterio cada una de ellas. Además, se pueden filtrar los datos de esta tabla.

La ordenación y las búsquedas no me preocupan. Para la ordenación se puede hacer bien en el cliente por JavaScript (con el problema de la paginación) o bien en el servidor (con tu lenguaje de progarmación favorito – en mi caso el PHP, que no es que sea mi favorito, es que es en el que programo). Para las búsquedas en el servidor (de momento nada de AJAX).

Mi duda es ¿dónde guardo los criterios de ordenación y búsqueda?, es decir ¿dónde guardo la columna por la que se ordena y si es orden ascendente o descendente y los valores de los campos de búsqueda para que entre cambios de página mantenga dicho orden y filtro?

Así, a priori, veo cuatro lugares donde guardarlo:

• La URL: Añadir variables a la URL con la columna ordenada, si el orden es ascendente o descendente, y también añadir una variable por cada campo de búsqueda con su correspondiente valor. Este tiene el pequeño problema de que las URL crecen y crecen y, si usamos mod_rewrite de Apache (reescritura de URL’s) pues se vuelve un poco difícil de tratar.
• En la cookie: Guardando en la cookie del navegador (o en varias cookies) todos los criterios de búsqueda y ordenación y cargarlos según la ventana que se cargue y guardarlos cada vez que haya una búsqueda u ordenación. El problema es que las cookies están limitadas (al menos en IE) y si se tiene una aplicación muy grande con varias personas trabajando sin que se preocupen los unos por las cookies de los otros, se pueden llegar a terminar y ya no funcionaría nuestro sistema.
• En la sesión: Igual que en las cookies, se pueden guardar datos en la sesión con lo que los datos viajarán del cliente al servidor y viceversa contínuamente. El problema es que puede haber aplicaciones que no usen sesiones. Además, PHP no recomienda que guardes grandes cantidades de datos y el id de sesión también se propaga en una cookie o en la URL.
• En la base de datos: En caso de que haya un usuario conectado al sistema y se mantengan los accesos por usuario (que viene siendo normal en aplicaciones web), se pueden guardar los criterios de ordenación y búsqueda en la base de datos, en el registro asociado a los datos del usuario actual. Esta quizás sea la mejor opción, ya que se puede guardar cualquier cantidad de datos, no hay URL grandes y sólo usa cookies para propagar el id de sesión. El problema es que quizás se sobrecargue más la base de datos (aunque ya está bastante cargada ahora ).

Probablemente en la próxima aplicación grande que desarrolle lo guarde en la base de datos (en la actual está en la URL y es bastante chungo gestionarlo sin una clase URL que lo gesione automáticamente).

El problema es que hay que gastar bastante tiempo en diseñar toda la arquitectura de seguridad, incluyendo usuarios y grupos, para poder tener un sistema robusto para guardar, no sólo esto, sino todos los datos asociados a los usuarios incluyendo la configuración y, sobre todo, los permisos.

De todas formas ¿alguien me recomienda otra solución? Yo siempre propongo muchas cosas, pero siempre estoy abierto a nuevas soluciones que, si son mejores que las mías (que suelen serlo), se adoptan sin problemas. Así que ya sabéis, a proponer.