Portada del web --> página de sección --> página de subsección

En las siguientes líneas voy a explicar cómo realizar estos menús mediante elementos <li> y CSS.

El toolkit se puede utilizar sobre cualquiera de los entornos habituales de desarrollo Java, como Eclipse o Netbeans, aparte de poder utilizar las herramientas habituales como JUnit o JProfiler. Todo esto permite crear aplicaciones basadas en Ajax de una forma más eficiente y menos propensa a errores, pudiéndose incluso depurar la aplicación en el entorno Java.

El toolkit dispone de un conjunto de widgets que podemos utilizar en nuestras aplicaciones, como paneles, pestañas, árboles, menús… Merece la pena también destacar algunas características interesantes que ofrece, como la comentada capacidad de depuración, gestión de la historia del navegador para que se puedan usar los botones de adelante y atrás en nuestra aplicación ajax, compatibilidad con los navegadores actuales y por supuesto, la posibilidad de incluir código Javascript propio.

Y ahora pensando un poco más, ¿qué nos ofrece este toolkit realmente? Pues de primeras lo que se me ocurre es que pese a que los widgets ofrecidos sean pocos y no muy vistosos, aporta una nueva visión de cómo realizar aplicaciones Ajax, que puede ser muy ventajosa. Actualmente desarrollar una aplicación Ajax implica programar el lado del servidor, diseñar el html, y escribir todo el Javascript que controla el Html poniéndose en contacto con el servidor, todo ello muy entrelazado y relativamente complejo de independizar y controlar. Con este toolkit podríamos diseñar la aplicación teniendo en cuenta que vamos a hacer el lado servidor por ejemplo en PHP, definiendo un conjunto de servicios que se utilizarán posteriormente desde el navegador de los usuarios. De forma independiente podríamos diseñar el interfaz de usuario en Html y la lógica que lo controla mediante Java (o cualquier otro lenguaje llegado el caso), depurarlo, y una vez testeado compilarlo a Javascript. Habríamos conseguido principalmente simplificar el desarrollo del interfaz reutilizando componentes existentes, habríamos simplificado las comunicaciones con el servidor usando las capacidades RPC del toolkit, y tendríamos una aplicación mucho más estructurada y mantenible, a la vez que menos propensa a errores.

En realidad este mensaje es una muestra más de hasta donde puede llegar a ser pernicioso el tema de las patentes de software. Resulta que Microsoft llevaba bastante tiempo en juicios con una empresa llamada Eolas, que tiene la única licencia de utilización de una patente registrada por la Universidad de California, referente a la inclusión de plugins dentro de páginas web. Finalmente Microsoft ha sido condenada a pagar la friolera de 560 millones de dolares y se ha visto obligada a crear un parche para el explorer que modifica la carga de los plugin, entre ellos flash, de forma que el usuario no pueda interactuar con ellos hasta hacer click voluntariamente.

La estandarización la está llevando a cabo el Web APIs Working Group con el nombre The XMLHttpRequest Object.

Últimamente han aparecido multitud de proyectos independientes orientados al desarrollo de aplicaciones Ajax, desde proyectos comerciales a open-source, y cubriendo no siempre las mismas posibilidades. A mi entender es precisamente este gran abanico de opciones lo que en muchos casos está frenando actualmente la adopción de esta tecnología y que además está provocando que no se usen todas sus funcionalidades.

El siguiente framento de código JavaScript permite añadir funciones al evento onload sin problemas de este tipo, lo único que debemos tener en cuenta es que las asignaciones deben hacerse utilizando esta función.

function addLoadEvent(func) {
   var oldonload = window.onload;
   if (typeof window.onload != 'function') {
      window.onload = func;
   }
   else {
      window.onload = function() {
      oldonload();
      func();
    }
}

Si quisiéramos añadir la función “funcion1″ al evento, haríamos únicamente addLoadEvent('funcion1').

Para todo esto relacionado con los eventos, el W3C ha creado la especificación
DOM Level 2 Event, aunque dicha especificación no está implementanda en todos los navegadores, por lo que aunque desde luego esta no es la forma óptima ni ideal de hacer las cosas, el método descrito nos permite resolver el problema.

Si tienes interés en obtener más información sobre qué navegadores soportan la especificación del W3C, puedes hacerlo en el árticulo Advances event registration de Quirksmode.

Evitarlo es realmente sencillo, basta con incorporar el siguiente código JavaScript en tu página.

<script type="text/javascript">
if (top != self) top.location.href = location.href;
</script>

Si nuestra página está dentro de un frame, top será distinto de self, en cuyo caso se cambia la url de la página que nos contiene por la nuestra, de forma que el frame desaparece y nuestra página pasa a tomar el control de la ventana. Rápido, sencillo y eficaz.

Una posible solución, que a mi entender es bastante buena, se basa en la utilización de una capa con posicionamiento absoluto que se ubica en la pantalla mediante JavaScript. Al lanzarse los eventos onload y onresize se llama a una función (positionIt) que se encarga de obtener las dimensiones de la capa que hay que centrar (divCentrado) y configurar sus valores left y top, para lo cual a su vez necesita obtener el tamaño disponible en el navegador del usuario, lo cual lo hace mediante las funciones getViewportWidth y getViewportHeight.

• Ver ejemplo

El siguiente HTML monta un formulario de ejemplo con el cual se solicita al usuario que elija su sistema operativo favorito.

<form name="frmSO">
<input type="radio" name="so" value="windows">Windows
<input type="radio" name="so" value="linux">Linux
<input type="radio" name="so" value="osx">OSX
<input type="radio" name="so" value="other">Other
</form>

No hay una forma directa de obtener qué radio button está seleccionado y saber así su valor. Si es la primera vez que lo intentas seguramente habrás intentado hacer algo como document.form.so.value y te habrás dado cuenta que eso no funciona, y es normal ya que si te fijas en el html, tenemos 4 controles con el mismo nombre. Para poder obtener el valor seleccionado, cada “conjunto” de controles radio está representado en JavaScript mediante un array, de forma que debemos recorrer ese array para obtener la opción seleccionada. El siguiente código nos facilita el trabajo:

function getRadioButtonSelectedValue(ctrl)
{
    for(i=0;i<ctrl.length;i++)
        if(ctrl[i].checked) return ctrl[i].value;
}

Ahora ya podríamos utilizar esta función para obtener el valor seleccionado, pasándole como parámetro el control radiobutton del que queremos obtener el valor, en nuestro caso: getRadioButtonSelectedValue(document.frmSO.so);.