Blog Tecnológico de Azalorea

Tras muchos meses de desarrollo y versiones 0.x por fina ha salido la versión 1.0 de MooTools.

Lo que más destacan sus desarrolladores (yo aún no lo he probado) es que todas sus clases usan eventos. Cuando lo leí por primera vez no entendía a que se refieren, pero tras leerlo una segunda vez me dí cuenta que las mismas clases pueden evocar eventos. Por ejemplo onStart para ejecutar código antes de inicializar un método.

También han mejorado su gestión de eventos que ahora consume menos memoria y dispone de la posibilidad de eliminar todos los eventos de un elemento o de un tipo de evento (pe onClick). Además se puede evocar eventos manualmente.

Por el lado negativo nos encontramos con que han hecho cambios en el API (en una librería tan nueva no nos debe extrañar) y si has usado una versión 0.x de MooTools tendrás que actualizar tu código antes de pasarte a la versión 1.0.

ENLACES:

Artículo original:
http://mad4milk.net/entry/mootools-version-1-official-world-release
Documentación:
http://docs.mootools.net/

Joe Hewitt ha puesto manos a la obra y ha sacado la versión beta de Firebug 1.0. Al día de hoy es la beta3 que incorpora funcionalidades que usuarios le han pedido tras haber evaluado beta1 y beta2.

Y estamos de suerte porque Joe ha decidido, tras pensarselo detenidamente y hablar con los usuarios, a seguir con el modelo OpenSource [ver su comentario]. Al parecer ha hecho bien porque los mismos usuarios se han volcado en donar importes de 20 a 100€ para que Joe pueda dedicarle recursos a esta herramienta que ya se ha vuelto indisepnsable para muchos desarrolladores.

El interfaz de Firebug está totalmente renovado y mucho más limpio… cosa que era necesaria porque tiene un sinfin de nuevas funcionalidades. Las más importantes son:

• Poder abrir Firebug en una ventana propia
• Editar HTML (y no solo los parámetros como en la versión 0.4)
• Editar CSS (desde beta3 se puede editar enteramente)
• Monitorizar tráfico de red detallando gráficamente cuando tarda cada elemento en cargarse.
• Perfilar tiempo de ejecución

Aparte del AddOn para Firefox Joe ha creado Firebug Lite… una librería JavaScript para disponer de las funcionalidades (limitadas por momento) de Firebug en Internet Explorer, Opera y Safari. Por momento Firebug Lite está limitado al logging y ejecución de comando JS en la consola.

Happy debugging,
Miguel

Con el release de hace unos días de la nueva versión de Internet Explorer, IE7, y sus mejoras a nivel de CSS nos encontramos con que algunos workarounds que chequean el nombre del navegador dan resultados no deseados en IE7.

Abe Fettig nos recomienda un método para discernir entre IE7 e IE6-.

if (typeof document.body.style.maxHeight != "undefined") {
// IE 7, mozilla, safari, opera 9
} else {
// IE6, navegadores antiguos
}

Es muy recomendable hacerlo de esta manera y no usar el UserAgent ya que este se cambia fácilmente.

Arjan, en un comentario en ajaxian.com, dice que es más fácil usar window.XMLHttpRequest que ha sido intorducido en IE7 y es más corto.

La decisión final depende del gusto del programador

Entrado de pleno en la guerra de las librerías DOM para JavaScript, Claudio Cicali se ha puesto a comparar la velocidad de los selectores de Prototype y jQuery. En particular las funciones que ha usado son $() para jQuery y $$() para Prototye.

El resultado de su benchmark es que las 2 librerías tienen un rendimiento muy parecido, ganando Prototype en algunas asignaturas y jQuery en otras.

Hay un patch para Prototype que mejora sensiblemente el rendimiento de la función $$() y según un comentario en el blog de Claudio usando el patch Prototype gana a jQuery en todos los campos.

Queda preguntarse porque el patch aún no forma parte del core de Prototype.

Cada día se escucha más hablar de DOM y cada vez menos de DHTML. Hay discusiones larguísimas acerca de estos 2 términos sobre todo porque no está del todo claro si es lo mismo o no lo es. Cómo siempre depende del enfoque que cada uno le dé a un término y otro.

Hay quienes defienden DOM cómo la tecnología del futuro (y sin duda tienen razón) objetando que DHTML es cosa del pasado (cosa que no creo). DOM-scripting lo interpreto cómo parte de DHTML (HTML dinámico), que en este caso se consigue actuando sobre nodos en vez de actuar sobre capas.

Hoy me he topado con un artículo muy bueno sobre cómo pasar de DHTML a DOM-scripting. Salvando el hecho de que yo considero DOM cómo una parte de DHTML, el artículo es muy instructivo por tener cómo meta querer ayudar a evitar técnicas antiguas y enseñar a usar técnicas actuales.

El autor diferencia DHTML de DOM-scripting por el hecho de que DHTML no es ningún estándar del W3C sino que es un conjunto de estándares (al igual que lo es Ajax hoy en día) y que DHTML aparenta cambiar la página sin recargarla, cuando DOM es capaz de enviar y recibir datos a otros sistemas (pe servidor). Lo último en realidad nada tiene que ver con DOM y mucho menos es un estándar (aunque lleva mucho tiempo vagando por el mundo de los navegadores).

Estoy muy de acuerdo en que DOM es el futuro…. de DHTML… y si se hace uso de Ajax de manera reservada (quiero decir que no se intente usarlo porque si) pues aún mejor.

Bueno… aquí va el enlace (el artículo está en inglés):
http://icant.co.uk/articles/from-dhtml-to-dom/from-dhtml-to-dom-scripting.html

Otro tutorial interesante trata de objetos literales (también en inglés):
http://www.wait-till-i.com/index.php?p=239

Ha salido por fin la la largamente prometida versión 0.4 de Firebug. Lo más impresionante es que esta versión viene con un debugger “básico” pero muy funcional. No es tan completo (o complejo) cómo el Venkman, pero la facilidad y rápidez de uso del Firebug pronto nos hará olvidarnos de Venkman. Además con esta nueva versión el autor ha inaugurado dominio propio para la herramienta. Para la URL ha seguido el estilo de la Mozilla Foundation… www.getfirebug.com

Las funcionalidades nuevas son las siguientes:

• Permite poner breakpoints desde la consola.
• Inspeccionar variables locales.
• Stacktraces en los errores… para saber en que circunstancia se dispara el error.
• Break on error… (opcional) para para la ejecución cuando hay un error y llevarnos a la fuente del mismo.
• console.log… ya no necesitamos la función printfire()… Firebug pone a disposición de las páginas el objeto console para ello.
• Los mensajes de logging ahora se pueden clasificar (debug, error, warning, info)… parte del objeto log.
• Aserciones… podemos testear aserciones con el objeto log.
• Uso de funcionalidad tipo prinf (PHP) para los mensajes del objeto log. Esto nos permite incluir una referencia a un objeto e inspeccionarlo con un solo click.

Para un listado completo de cambios ir a los release notes.
Documentación para las nuevas funcionalidades se encuentra aquí.

Feliz debugging

Llevo tiempo buscando un script para tooltips que no exija html redundante y que coja el texto (o html) a mostrar del atributo title. No encontré nada que lo haga, pero al final dí con un script que hacía algo parecido y lo adapté a mi gusto.

El script original se puede bajar de http://jnetiq.com/tool_tips.html.
El script adaptado lo puedes bajar aquí.

También adapté el script para que haga uso de Prototype/Scriptaculous. Aún queda mejorar algunos detalles, pero el resultado ya es muy satisfactorio.

Modo de uso:

Poner el siguiente código en el header

var jttl;
function jttl_init(){
if (typeof(Tooltips) == “function”){
jttl = new Tooltips();
jttl.registerElements(document.body);
jttl.activate();
}
}

Al final de la página o en onLoad poner

jttl_init();

Los elementos que deban tener el tooltip han de tener la clase tooltip (class=”tootltip”).

En los últimos meses ha habido mucha discusión acerca del uso de innerHTML. Los hay que están totalmente en contra por el hecho de no ser un estándar. Otros sin embargo lo abogan su uso porque a pesar de no ser un estándar tiene un amplio soporte en los navagedores y por su mayor rapidez [ver comparativa].

La verdad es que el soporte de los navegadores para innerHTML es bastante mejor que el soporte para DOM. Firefox, desde la versión 1.5, hasta permite usar innerHTML para documentos XML.

Yo suelo usar mucho Ajax en mis aplicaciones, y la manera más rápida es que el servidor me devuelva un fragmento de XHTML porque así evito hacer 2 funciones, una para la visualización HTML y otra para la visualización DOM. Esto me lleva a usar innerHTML ya que de lo contrario tendría que convertir el HTML a DOM y después insertarlo… doble trabajo y tiempo de procesador.

Parto de la idea que los estándares son buenos, pero, como siempre, no todo es blanco o negro. Uno debe elegir las herramientas a usar según convengan en la situación dada.