Buenas de nuevo a todos/as
De nuevo estoy aquí ya de vuelta de la selva pa daros el coñazo con nuevas entradas. Por el momento estoy en un momento muy liado hasta finales de febrero, pero quería dejar constancia de que a partir de ahora retomaré el hábito de escribir alguna entrada cada cierto tiempo. Y para que no sea una entrada vacía, aquí os dejo un documental sobre la Fundación EHAS (Enlace Hispano-Americano de Salud) que lleva ya 10 años trabajando en proyectos de cooperación para el desarrollo en Perú, Colombia y Cuba, aplicando para ello su investigación en Tecnologías de la Información y la Comunicación adaptadas a estos entornos. Ellos son los culpables de que haya dejado de escribir este tiempo :). Espero que os guste.
Saludos de nuevo.
domingo, enero 27, 2008
miércoles, enero 16, 2008
Usar certificados de cliente de la FNMT en una Aplicación Web
Mucho tiempo ha pasado desde la última entrada, pero entre que hemos estado muy ocupados y la pereza que da ponerse de nuevo a escribir, pues, han pasado tres meses (o más). Sin embargo, un nuevo reto se me planteó y tras sudar sangre para resolverlo lo comparto con vosotros. El tema de este post es: ¿Cómo usar certificados de la FNMT (Fábrica Nacional de Moneda y Timbre) en nuestra web?
Existe poquísima información al respecto en Internet, muchos posts de gente, mucha historieta pero nada concreto. Voy a intentar, por lo tanto, dar las instrucciones para configurar un servidor de internet (en mi caso IIS, aunque la configuración es similar para el resto) para poder pedir al usuario que utilice un certificado emitido por la FNMT.
Paso I: La Seguridad
Si no tenemos una conexión https con SSL, GAME OVER, fin de la partida. Es requisito indispensable comunicarnos con el cliente mediante una conexión cifrada para poder interactuar con los certificados. Pero, ¿cómo lo hacemos para conseguir un certificado?. En desarrollo podemos seguir los siguientes pasos (en producción necesitareis un certificado emitido por una CA Root reconocida):
Existen muchos sitios en internet donde se describe este proceso, os pongo esta url donde explican como generar nuestro propio certificado con OpenSSL:
http://www.locualo.net/programacion/activar-ssl-iis-certificado-digital-prueba/00000079.aspx
Paso II: La Teoría
Vamos a ver un poco de la teoría para saber cómo funciona el tema de los certificados. Una vez que sepamos como funciona, entenderemos los pasos a dar. El circuito de los certificados es el siguiente:
1. El cliente accede a la url https://.... (para la cual es necesario un certificado de cliente)
2. El servidor envía su certificado al cliente para establecer el canal seguro. El cliente debe confiar en la entidad que ha generado ese certificado y comprobar que es válido. En caso de no confiar aparecerá un mensaje en el explorador indicándonoslo (la mayoría de la gente no lo lee).
3. Una vez que el cliente ha confiado en el servidor, se establece el canal seguro.
4. El servidor tiene configurado que para el recurso que intenta ver el cliente es necesario que presente un certificado de cliente, emitido por una entidad certificadora en la que él confíe y además que está en la lista de los certificados admitidos para el recurso en cuestión.
5. El explorador del cliente recibe estas condiciones del servidor y muestra una ventana con los certificados instalados que cumplan los requisitos del servidor.
6. El usuario elige su certificado y éste es mandado al servidor.
7. El servidor comprueba la lista de revocación de certificados de la entidad que emitió el certificado para ver si sigue siendo válido.
8. En caso que el certificado sea válido, podremos acceder al recurso y en la sesión tendremos guardado el certificado para usarlo.
En la siguiente imagen os muestro el flujo:
Paso III: La Confianza
Como habéis podido observar, la clave del asunto es la confianza entre los diferentes elementos (cliente y servidor). Vamos a ver cómo configurar nuestro servidor para: 1) requerir el certificado del cliente y 2)confiar en la fnmt para que acepte sus certificados.
Para requerir el certificado del cliente iremos al "Administrador de Servicios de IIS", buscaremos el recurso, sitio web o directorio virtual que necesitará certificado y pulsamos en "Propiedades" del menú contextual. En la pestaña "Seguridad de Directorios" pulsamos sobre el botón "Modificar" de la parte inferior. Nos aparecerá la siguiente pantalla:
Marcaremos la opción "Requerir Canal Seguro" y "Requerir Certificados de Cliente". Pulsamos sobre Aceptar y hemos terminado. Ahora el IIS espera un certificado del cliente para acceder al recurso, sin embargo, todavía no le hemos dicho que debe confiar en la FNMT como entidad certificadora.
Para confiar en la FNMT, tendremos que abrir una consola mmc (Ejecutar--> mmc), Archivo-->Agregar o Quitar Complemento. En la pantalla que aparece pulsaremos de nuevo sobre Agregar y seleccionaremos el complemento "Certificados":
Pulsamos sobre "Agregar", seleccionamos la opción "Mi Cuenta de usuario" y cerramos la pantalla de agregar complementos. En la consola mmc, expandimos "Entidades emisoras raíz de confianza-->Certificados" y buscamos a la FNMT:
En caso que no esté, tendremos que importarlo. Lo primero será conseguir la definición del certificado de la FNMT. La podéis conseguir desde aquí:
http://www.cert.fnmt.es/content/pages_std/certificados/FNMTClase2CA.cer
Guardamos el fichero .cer en nuestro servidor y en la consola mmc pulsamos con el botón derecho sobre "Certificados" y elegimos "Todas las tareas-->Importar". Saltará un asistente para importar un certificado, seleccionaremos el fichero que nos acabamos de descargar y siguiente hasta el final.
Una vez importado, veremos las propiedades del certificado y habilitaremos la opción "Autenticación del Cliente". De esta forma habilitamos a los certificados de la FNMT para que sirvan como certificados de cliente.
Con esto hemos dado nuestra confianza a la FNMT como CA Root, sin embargo, todavía no funciona porque tenemos que incluir a la FNMT como entidad válida para nuestro recurso, en la CTL (Certificate Trusted List). Para ello, volvemos a la consola del IIS y nos vamos a las propiedades del sitio web en el que esté el recurso del certificado. Seleccionamos la pestaña "Seguridad de Directorios" y pulsamos sobre el botón "Modificar" de la parte inferior. Aparecerá la pantalla siguiente:
En la parte inferior tenemos la lista de certificados de confianza, pulsamos sobre "Modificar" y en la lista que aparece, pulsamos sobre "Agregar desde el almacén" e incluimos el de la FNMT. Pulsamos "Siguiente" hasta el final y ya tenemos todo hecho.
Paso IV: Final
Ya tenemos nuestro entorno habilitado para utilizar certificados de cliente. En producción tendremos que tener un certificado emitido por una entidad reconocida, pero el resto es igual.
Espero que os haya aclarado las ideas y os haya servido.
Existe poquísima información al respecto en Internet, muchos posts de gente, mucha historieta pero nada concreto. Voy a intentar, por lo tanto, dar las instrucciones para configurar un servidor de internet (en mi caso IIS, aunque la configuración es similar para el resto) para poder pedir al usuario que utilice un certificado emitido por la FNMT.
Paso I: La Seguridad
Si no tenemos una conexión https con SSL, GAME OVER, fin de la partida. Es requisito indispensable comunicarnos con el cliente mediante una conexión cifrada para poder interactuar con los certificados. Pero, ¿cómo lo hacemos para conseguir un certificado?. En desarrollo podemos seguir los siguientes pasos (en producción necesitareis un certificado emitido por una CA Root reconocida):
Existen muchos sitios en internet donde se describe este proceso, os pongo esta url donde explican como generar nuestro propio certificado con OpenSSL:
http://www.locualo.net/programacion/activar-ssl-iis-certificado-digital-prueba/00000079.aspx
Paso II: La Teoría
Vamos a ver un poco de la teoría para saber cómo funciona el tema de los certificados. Una vez que sepamos como funciona, entenderemos los pasos a dar. El circuito de los certificados es el siguiente:
1. El cliente accede a la url https://.... (para la cual es necesario un certificado de cliente)
2. El servidor envía su certificado al cliente para establecer el canal seguro. El cliente debe confiar en la entidad que ha generado ese certificado y comprobar que es válido. En caso de no confiar aparecerá un mensaje en el explorador indicándonoslo (la mayoría de la gente no lo lee).
3. Una vez que el cliente ha confiado en el servidor, se establece el canal seguro.
4. El servidor tiene configurado que para el recurso que intenta ver el cliente es necesario que presente un certificado de cliente, emitido por una entidad certificadora en la que él confíe y además que está en la lista de los certificados admitidos para el recurso en cuestión.
5. El explorador del cliente recibe estas condiciones del servidor y muestra una ventana con los certificados instalados que cumplan los requisitos del servidor.
6. El usuario elige su certificado y éste es mandado al servidor.
7. El servidor comprueba la lista de revocación de certificados de la entidad que emitió el certificado para ver si sigue siendo válido.
8. En caso que el certificado sea válido, podremos acceder al recurso y en la sesión tendremos guardado el certificado para usarlo.
En la siguiente imagen os muestro el flujo:
Paso III: La Confianza
Como habéis podido observar, la clave del asunto es la confianza entre los diferentes elementos (cliente y servidor). Vamos a ver cómo configurar nuestro servidor para: 1) requerir el certificado del cliente y 2)confiar en la fnmt para que acepte sus certificados.
Para requerir el certificado del cliente iremos al "Administrador de Servicios de IIS", buscaremos el recurso, sitio web o directorio virtual que necesitará certificado y pulsamos en "Propiedades" del menú contextual. En la pestaña "Seguridad de Directorios" pulsamos sobre el botón "Modificar" de la parte inferior. Nos aparecerá la siguiente pantalla:
Marcaremos la opción "Requerir Canal Seguro" y "Requerir Certificados de Cliente". Pulsamos sobre Aceptar y hemos terminado. Ahora el IIS espera un certificado del cliente para acceder al recurso, sin embargo, todavía no le hemos dicho que debe confiar en la FNMT como entidad certificadora.
Para confiar en la FNMT, tendremos que abrir una consola mmc (Ejecutar--> mmc), Archivo-->Agregar o Quitar Complemento. En la pantalla que aparece pulsaremos de nuevo sobre Agregar y seleccionaremos el complemento "Certificados":
Pulsamos sobre "Agregar", seleccionamos la opción "Mi Cuenta de usuario" y cerramos la pantalla de agregar complementos. En la consola mmc, expandimos "Entidades emisoras raíz de confianza-->Certificados" y buscamos a la FNMT:
En caso que no esté, tendremos que importarlo. Lo primero será conseguir la definición del certificado de la FNMT. La podéis conseguir desde aquí:
http://www.cert.fnmt.es/content/pages_std/certificados/FNMTClase2CA.cer
Guardamos el fichero .cer en nuestro servidor y en la consola mmc pulsamos con el botón derecho sobre "Certificados" y elegimos "Todas las tareas-->Importar". Saltará un asistente para importar un certificado, seleccionaremos el fichero que nos acabamos de descargar y siguiente hasta el final.
Una vez importado, veremos las propiedades del certificado y habilitaremos la opción "Autenticación del Cliente". De esta forma habilitamos a los certificados de la FNMT para que sirvan como certificados de cliente.
Con esto hemos dado nuestra confianza a la FNMT como CA Root, sin embargo, todavía no funciona porque tenemos que incluir a la FNMT como entidad válida para nuestro recurso, en la CTL (Certificate Trusted List). Para ello, volvemos a la consola del IIS y nos vamos a las propiedades del sitio web en el que esté el recurso del certificado. Seleccionamos la pestaña "Seguridad de Directorios" y pulsamos sobre el botón "Modificar" de la parte inferior. Aparecerá la pantalla siguiente:
En la parte inferior tenemos la lista de certificados de confianza, pulsamos sobre "Modificar" y en la lista que aparece, pulsamos sobre "Agregar desde el almacén" e incluimos el de la FNMT. Pulsamos "Siguiente" hasta el final y ya tenemos todo hecho.
Paso IV: Final
Ya tenemos nuestro entorno habilitado para utilizar certificados de cliente. En producción tendremos que tener un certificado emitido por una entidad reconocida, pero el resto es igual.
Espero que os haya aclarado las ideas y os haya servido.
jueves, septiembre 06, 2007
Cooperante no hay camino...
¡Buenas chavalucos!
Esta entrada es solo pa informar de que me viajo este mes de Octubre a realizar un proyecto de cooperación para el desarrollo en la región de Loreto, Perú, provincia del Alto Amazonas .Mi misión allí será junto con otros/as ingenieros/as realizar el mantenimiento y puesta a punto de una red telemática que intercomunica los centros de salud de los pueblos de la selva amazónica de aquella región, a orillas del río Napo, uno de los principales afluentes del Amazonas.
Con motivo de este proyecto y de otros tantos que se realizarán financiados con fondos de la Oficina de Cooperación para el Desarrollo de Universidad Carlos III de Madrid, hemos abierto un blog donde trataremos de informar del estado de cada proyecto así como de las vivencias que se nos vayan ofreciendo en el camino. El blog se llama "Cooperante no hay camino..." y espero que a más de uno le sirva para animarse a poner al servicio del desarrollo humano sus conocimientos técnicos.
Durante ese periodo no podré poner entradas en este blog, pero prometo volver con ánimos para seguir colaborando con este blog tanto como me sea posible, aunque con Manolo ya tenéis información interesante para dar y regalar.
Por el momento, me despido temporalmente de vosotros y espero que os parezca interesante la información que podáis leer sobre los proyectos de cooperación al desarrollo. ¡¡Hasta pronto!!
Esta entrada es solo pa informar de que me viajo este mes de Octubre a realizar un proyecto de cooperación para el desarrollo en la región de Loreto, Perú, provincia del Alto Amazonas .Mi misión allí será junto con otros/as ingenieros/as realizar el mantenimiento y puesta a punto de una red telemática que intercomunica los centros de salud de los pueblos de la selva amazónica de aquella región, a orillas del río Napo, uno de los principales afluentes del Amazonas.
Con motivo de este proyecto y de otros tantos que se realizarán financiados con fondos de la Oficina de Cooperación para el Desarrollo de Universidad Carlos III de Madrid, hemos abierto un blog donde trataremos de informar del estado de cada proyecto así como de las vivencias que se nos vayan ofreciendo en el camino. El blog se llama "Cooperante no hay camino..." y espero que a más de uno le sirva para animarse a poner al servicio del desarrollo humano sus conocimientos técnicos.
Durante ese periodo no podré poner entradas en este blog, pero prometo volver con ánimos para seguir colaborando con este blog tanto como me sea posible, aunque con Manolo ya tenéis información interesante para dar y regalar.
Por el momento, me despido temporalmente de vosotros y espero que os parezca interesante la información que podáis leer sobre los proyectos de cooperación al desarrollo. ¡¡Hasta pronto!!
miércoles, agosto 15, 2007
YA SAN CASAOOOO, YA SAN CASAAAOOOO...
Pos eso, que Marivi y Manolo, socios de N-Idea Soluciones y colaboradores de este blog ya han hecho su roce oficial y se casaron el sábado pasao. Dentro de poco editaré esta entrada con alguna foto ilustrativa de la efeméride.
La fiesta insuperable, la novia guapísima y el novio mu elegante, la comida insuperable (por lo menos la mía), y hasta las mil y pico de la madrugá bebiendo, cantando, bailando y gritando "¡¡Vivan los novios!!" y demás alaridos propios del casamiento. Especialmente gracioso era el gesto de Manolo cada vez que gritaban "¡Viva el novio!" que se rodeaba y hacía el gesto de la "v" con los dedos a tol mundo.
Pos eso, que pa bodas la de Marivi y Manolo. De lo único que nos quedamos con ganas es de haber escuchao cantar más a la madre de Marivi, que ya tendrá ocasión de deleitarnos más si cabe en alguna otra ocasión.
Por mi parte, me levanté al día siguiente con un pestazo a bizcocho de chocolate que algún desalmao me restregó por la cara y que esperaré a la siguiente boda familiar pa devolvérsela ;).
Y ná más, ¡¡¡¡VIVAN LOS NOVIOS!!!! ...y a ver si montáis más fiestones como ese que estaremos esperándolos con muchas ganas.
La fiesta insuperable, la novia guapísima y el novio mu elegante, la comida insuperable (por lo menos la mía), y hasta las mil y pico de la madrugá bebiendo, cantando, bailando y gritando "¡¡Vivan los novios!!" y demás alaridos propios del casamiento. Especialmente gracioso era el gesto de Manolo cada vez que gritaban "¡Viva el novio!" que se rodeaba y hacía el gesto de la "v" con los dedos a tol mundo.
Pos eso, que pa bodas la de Marivi y Manolo. De lo único que nos quedamos con ganas es de haber escuchao cantar más a la madre de Marivi, que ya tendrá ocasión de deleitarnos más si cabe en alguna otra ocasión.
Por mi parte, me levanté al día siguiente con un pestazo a bizcocho de chocolate que algún desalmao me restregó por la cara y que esperaré a la siguiente boda familiar pa devolvérsela ;).
Y ná más, ¡¡¡¡VIVAN LOS NOVIOS!!!! ...y a ver si montáis más fiestones como ese que estaremos esperándolos con muchas ganas.
jueves, julio 12, 2007
Frameworks para RIAs
En esta cuarta entrega del desarrollo basado en Ajax, nos vamos a centrar en los diferentes frameworks existentes que nos pueden ayudar en nuestros desarrollos. Si no os habéis leído los posts anteriores, os recomiendo que os los leáis para entender mejor este:
Yahoo User Interface:
Esta fue la primera librería que utilicé en mis pruebas. Tiene varias cosas muy buenas a tener en cuenta:
http://www.nidea-soluciones.com/PruebasAjax/YUI/yui1.html
El código javascript utilizado se divide en dos partes: primero tenemos que importar los scripts de YUI que vayamos a utilizar (lo miramos en su web para saberlo) y después realizamos nuestros propios scritps:
Los scripts a importar dependerán de qué es lo que vamos a utilizar de la librería de controles de Yahoo. En la página web se indica para cada caso cuáles son necesarios. La parte de programación es la siguiente:
El meollo se encuentra en la línea YAHOO.util.Connect.AsyncRequest() que es la que crea el objeto XMLHttpRequest y realiza la llamada. Se le pasa el método, la url y una variable que contiene toda la información relativa a la función si va todo bien, la función si no va bien, los argumentos, etc. Es muy importante el orden, no podemos definir la variable callback antes de las funciones que manejarán las respuestas, ni podemos definir la variable callback después de la llamada al servidor.
Utilizamos también uno de los controles de YUI, el container en su versión panel. La programación con YUI se puede realizar de dos maneras distintas, por marcación o por Javascript. Todos los controles se pueden definir directamente en Javascript (caso del ejemplo) o definir en HTML (Markup). Al definir por HTML, cuando se llama al método render, la librería busca determinadas clases css y las convierte en controles. El mismo panel que se define en el ejemplo con HTML sería:
La librería lee las clases y las renderiza en pantalla en forma de panel.
Framework Dojo:
Este es el siguiente framework con el que trabajé. Tiene otras ventajas e inconvenientes que el YUI. Los que encontré fueron los siguientes:
Cosas buenas:
http://www.nidea-soluciones.com/PruebasAjax/Dojo/dojo1.html
El estilo de programación varía ligeramente entre ambos frameworks. En ambos disponemos de una parte de inicialización de dependencias que en el caso de YUI es mediante la incorporación de scripts y mediante Dojo se realiza más al estilo Java o C#:
Lo primero es importar la librería base dojo.js y después utilizamos la sentencia para importar aquellas partes que vayamos a utilizar. Podemos utilizar una sintaxis del tipo dojo.require() dojo.require("dojo.widget.*"); para importar todos los widgets. En este caso, como sólo vamos a utilizar el tipo Dialog pues lo importamos. La sentencia djConfig = {isDebug:true}; nos permite sacar mensajes de debug o de error en la librería por pantalla.
Dojo se diferencia de YUI en que al definir los elementos HTML, introducimos un nuevo parámetro llamado dojotype en el que le indicamos qué tipo de elemento dojo va a ser. De esta forma al inicializar el elemento en Javascript, la mayoría de la definición se encuentra en el elemento HTML. Vayamos por pasos: paso 1, el código HTML:
En el código definimos tres divs a los que les decimos que son dojotype="dialog". De esta forma, Dojo sabe que tiene que renderizarlos como diálogos. Además les definimos una serie de características propias de Dojo (las subrayadas en rojo): bgcolor(color de fondo de la pantalla no del div), bgOpacity(opacidad del fondo de la pantalla), toogle (forma en la que aparece o desaparece la pantalla) y toogleDuration (duración del efecto de aparecer y desaparecer).
El resto del código es html normal. Veamos cómo se definen los diálogos y las funciones (ved que llamo a dos funciones Javascript CargarNombre() y Empezar()).
He dividido el Javascript en trozos. En la primera parte tenemos las definiciones de las variables que vamos a utilizar después, los tres diálogos, y las dos funciones manejadoras de los eventos de respuesta correcta y respuesta incorrecta, hasta aquí todo igual que antes. Tenemos también la función init, que se ejecuta al cargar la página que define el primer diálogo que aparece en pantalla. La definición es muy simple, solamente utilizamos la sentencia dojo.widget.byId() y le pasamos el id del div que va a ser el diálogo (ese div tiene que tener el dojotype="dialog"). Le definimos el botón que va a ocultar el diálogo con la sentencia setCloseControl(). Ved que podemos utilizar con los diálogos las sentencias show() y hide() para mostrarlos u ocultarlos desde cualquier parte del código. ¿Y las llamadas a servidor cómo se hacen? Pues veamos el resto del código:
Tenemos la función CargarNombre() que muestra el diálogo de espera y llama al servidor. Con Dojo, las llamadas se realizan utilizando el método dojo.io.bind al que le pasamos parámetros. Los más comunes y necesarios (algunos) son: url (dirección a la que llamar), load (método que controlará la respuesta correcta del servidor), error (método que manejará la respuesta de error del servidor), mimetype (mimetype de los datos de la llamada).
Dojo también permite realizar llamadas cross-domain mediante el método bind(), pero hay que importar el espacio dojo.require("dojo.io.XhrIframeProxy"), proque la llamada se realiza mediante un iFrame Proxy. Esto está aún en pruebas así que os aconsejo que vayáis a la documentación y os lo leáis.
Conclusión (hasta la próxima):
Como se me está haciendo demasiado largo el post, dejaremos los dos frameworks restantes para el siguiente. Sólo comentaros mi experiencia con ambos: personalmente prefiero el framework de Dojo que es bastante más intuitivo de utilizar, aunque YUI tenga más documentación (es realmente buena), cuando empiezas a trabajar con Dojo y te empiezas a enterar de cómo funciona, es más liviano. De todas formas, al ser frameworks completamente independientes de plataformas, siempre podéis conjugarlos y utilizar aquellas partes que más os gusten de uno y de otro.
Proximamente: GWT y ASP.NET AJAX
- ¿Qué es eso del AJAX?: Introducción a ajax, a su funcionamiento y al objeto XMLHttpRequest.
- AJAX para CAMPEONES o ¿Qué es eso del AJAX? (Segunda Parte): en este segundo post, nos adentramos un poco más en la implementación práctica a través de ejemplos de las llamadas asíncronas.
- AJAX PARA SUPERCAMPEONES o ¿Sabremos alguna vez qué es AJAX? (III): en la tercera entrega vimos cómo hacer múltiples llamadas de forma simultánea y cómo enlazar múltiples llamadas secuenciales.
- YUI: Yahoo User Interface, framework de Yahoo (que listo soy) para aplicaciones ricas de internet (RIA: Rich Internet Application). Muy completo y con un montón de ejemplos y documentación.
- Dojo: Framework de la Dojo Foundation. Es también muy completo, quizás un poco más sencillo de utilizar que el de Yahoo y menos pesado para el explorador, aunque con menos documentación.
- GWT: Google Web Toolkit. Es la implementación que da Google para Ajax sobre Java. En realidad, la filosofía de GWT es la de programar en Java y él interpreta el código Java para generar las páginas con los controles AJAX.
- AJAX ASP.NET: La implementación para asp.net de AJAX. Incluye, aparte del core de librerías de comunicación una librería de controles llamada Atlas Control Toolkit. Se puede utilizar aunque no se utilice asp.net.
Yahoo User Interface:
Esta fue la primera librería que utilicé en mis pruebas. Tiene varias cosas muy buenas a tener en cuenta:
- Una documentación muy buena con unas cheatsheets muy curradas.
- Un mogollón de ejemplos con el código bien puesto.
- Muchos controles
- El respaldo de una gran empresa que soporta el proyecto (no te van a dejar tirado).
- Puede llegar a ser bastante pesado para el cliente (las librerías javascript)
- Es el framework más complejo con el que trabajar debido a que puedes hacer lo que quieras con él.
http://www.nidea-soluciones.com/PruebasAjax/YUI/yui1.html
El código javascript utilizado se divide en dos partes: primero tenemos que importar los scripts de YUI que vayamos a utilizar (lo miramos en su web para saberlo) y después realizamos nuestros propios scritps:
Los scripts a importar dependerán de qué es lo que vamos a utilizar de la librería de controles de Yahoo. En la página web se indica para cada caso cuáles son necesarios. La parte de programación es la siguiente:
El meollo se encuentra en la línea YAHOO.util.Connect.AsyncRequest() que es la que crea el objeto XMLHttpRequest y realiza la llamada. Se le pasa el método, la url y una variable que contiene toda la información relativa a la función si va todo bien, la función si no va bien, los argumentos, etc. Es muy importante el orden, no podemos definir la variable callback antes de las funciones que manejarán las respuestas, ni podemos definir la variable callback después de la llamada al servidor.
Utilizamos también uno de los controles de YUI, el container en su versión panel. La programación con YUI se puede realizar de dos maneras distintas, por marcación o por Javascript. Todos los controles se pueden definir directamente en Javascript (caso del ejemplo) o definir en HTML (Markup). Al definir por HTML, cuando se llama al método render, la librería busca determinadas clases css y las convierte en controles. El mismo panel que se define en el ejemplo con HTML sería:
La librería lee las clases y las renderiza en pantalla en forma de panel.
Framework Dojo:
Este es el siguiente framework con el que trabajé. Tiene otras ventajas e inconvenientes que el YUI. Los que encontré fueron los siguientes:
Cosas buenas:
- Un montón de controles
- Definición en la programación más intuitiva que la de YUI.
- Menos importaciones a nuestras páginas
- La documentación es mucho peor.
- Existen menos ejemplos en la utilización de los diferentes controles.
http://www.nidea-soluciones.com/PruebasAjax/Dojo/dojo1.html
El estilo de programación varía ligeramente entre ambos frameworks. En ambos disponemos de una parte de inicialización de dependencias que en el caso de YUI es mediante la incorporación de scripts y mediante Dojo se realiza más al estilo Java o C#:
Lo primero es importar la librería base dojo.js y después utilizamos la sentencia para importar aquellas partes que vayamos a utilizar. Podemos utilizar una sintaxis del tipo dojo.require() dojo.require("dojo.widget.*"); para importar todos los widgets. En este caso, como sólo vamos a utilizar el tipo Dialog pues lo importamos. La sentencia djConfig = {isDebug:true}; nos permite sacar mensajes de debug o de error en la librería por pantalla.
Dojo se diferencia de YUI en que al definir los elementos HTML, introducimos un nuevo parámetro llamado dojotype en el que le indicamos qué tipo de elemento dojo va a ser. De esta forma al inicializar el elemento en Javascript, la mayoría de la definición se encuentra en el elemento HTML. Vayamos por pasos: paso 1, el código HTML:
En el código definimos tres divs a los que les decimos que son dojotype="dialog". De esta forma, Dojo sabe que tiene que renderizarlos como diálogos. Además les definimos una serie de características propias de Dojo (las subrayadas en rojo): bgcolor(color de fondo de la pantalla no del div), bgOpacity(opacidad del fondo de la pantalla), toogle (forma en la que aparece o desaparece la pantalla) y toogleDuration (duración del efecto de aparecer y desaparecer).
El resto del código es html normal. Veamos cómo se definen los diálogos y las funciones (ved que llamo a dos funciones Javascript CargarNombre() y Empezar()).
He dividido el Javascript en trozos. En la primera parte tenemos las definiciones de las variables que vamos a utilizar después, los tres diálogos, y las dos funciones manejadoras de los eventos de respuesta correcta y respuesta incorrecta, hasta aquí todo igual que antes. Tenemos también la función init, que se ejecuta al cargar la página que define el primer diálogo que aparece en pantalla. La definición es muy simple, solamente utilizamos la sentencia dojo.widget.byId() y le pasamos el id del div que va a ser el diálogo (ese div tiene que tener el dojotype="dialog"). Le definimos el botón que va a ocultar el diálogo con la sentencia setCloseControl(). Ved que podemos utilizar con los diálogos las sentencias show() y hide() para mostrarlos u ocultarlos desde cualquier parte del código. ¿Y las llamadas a servidor cómo se hacen? Pues veamos el resto del código:
Tenemos la función CargarNombre() que muestra el diálogo de espera y llama al servidor. Con Dojo, las llamadas se realizan utilizando el método dojo.io.bind al que le pasamos parámetros. Los más comunes y necesarios (algunos) son: url (dirección a la que llamar), load (método que controlará la respuesta correcta del servidor), error (método que manejará la respuesta de error del servidor), mimetype (mimetype de los datos de la llamada).
Dojo también permite realizar llamadas cross-domain mediante el método bind(), pero hay que importar el espacio dojo.require("dojo.io.XhrIframeProxy"), proque la llamada se realiza mediante un iFrame Proxy. Esto está aún en pruebas así que os aconsejo que vayáis a la documentación y os lo leáis.
Conclusión (hasta la próxima):
Como se me está haciendo demasiado largo el post, dejaremos los dos frameworks restantes para el siguiente. Sólo comentaros mi experiencia con ambos: personalmente prefiero el framework de Dojo que es bastante más intuitivo de utilizar, aunque YUI tenga más documentación (es realmente buena), cuando empiezas a trabajar con Dojo y te empiezas a enterar de cómo funciona, es más liviano. De todas formas, al ser frameworks completamente independientes de plataformas, siempre podéis conjugarlos y utilizar aquellas partes que más os gusten de uno y de otro.
Proximamente: GWT y ASP.NET AJAX
Suscribirse a:
Entradas (Atom)