DOM: intoducción
September 4, 2009
Aprovechando que todavía falta algunos días para que sea martes, el día que he escogido para liberar los artículos sobre ajax, y que nada me impide publicar algo que no sea ajax durante los demás días, me voy a tomar el tiempo para dar una breve introducción al DOM.
El DOM, o Document Object Model, no es más que una interfaz independiente o neutral al lenguaje y la plataforma que nos da la oportunidad de acceder y modificar documentos, específicamente aquellos que han sido tratados con algún lenguaje de enmarcado como lo es (X)HTML.
Este famoso DOM nos permite acceder de forma estructural el contenido de nuestros documentos de forma dinámica. Algunos tienen la idea que el DOM es exclusivo de HTML o de Javascript. La verdad no podría ser más diferente. El DOM no es exclusivo de HTML y mucho menos de Javascript. Si bien es cierto que por un lado los documentos HTML, todos, contienen un DOM, por el otro lado, los documentos Javascript no. De hecho, la única relación entre Javascript y el DOM es la que se mantiene mediante la API de DOM de Javascript. Esta API nos permite el acceso al DOM y se conforma de métodos como getElementById() y getElementsByTagName().
Es el DOM un leguaje de programación?
No. El DOM es simplemente un modelo, un maqueta de la estructura de nuestro documento; de ahí su nombre. El DOM se representa generalmente como un árbol genealógico, con el elemento HTML a la cabeza, ya que este elemento es el antecesor de todos. No hay otro elemento más arriba de HTML (esto hablando aquí exclusivamente de documentos HTML). Analicemos un ejemplo:
<html>
<head>
<!-- Contenido de head -->
</head>
<body>
<!-- Contenido de body -->
</body>
</html>
Como puedes ver en ese código, el elemento html es que contiene a todos los demás (head y body junto con sus elemento internos no mostrados aquí). A cada uno de estos elementos dentro del DOM se les conoce como nodos. Todos los nodos, excepto por html, son hijos de otro nodo. En nuestro ejemplo, los nodos head y bodoy son hijos de html.
Interactuando con el DOM.
Dependiendo del lenguaje que escojas, la forma de interactuar con el DOM puede variar. Nosotros escogeremos Javascript, ya que este blog es principalmente sobre Javascript. Como ya mencioné anteriormente, Javascript nos ofrece una API (Application Programing Interface) para el uso del DOM. Una API no es más que una serie de métodos que se hacen disponibles para poder interactuar con una aplicación. De hecho, dependiendo de con quien hables, puede ser que algunos no consideren lo métodos que ofrece Javascript para interactuar con el DOM como una API ya que el DOM no es una aplicación, sino una representación del documento. Sin embargo, yo, por comodidad, he decidido llamar a este conjunto de funciones API.
Esta API se conforma de métodos como los ya mencionados getElementById() y getElementsByTagName(). Curiosamente javascript no contiene un método getElementsByClassName(), lo cual es curioso considerando que las clases son una buena forma de agrupar elementos que en determinado momento nos gustaría poder manejar todos de una sola vez. Sin embargo, Javascript si nos ofrece otra serie de métodos como appendChild() y removeChild() que sirven para agregar y remover nodos respectivamente. No voy a entrar en detalles ni a listar todos los métodos para el manejo de DOM ofrecidos por Javascript ya que solo pretendo dar una breve introducción al DOM y no al API de Javascript para el uso del DOM. En su momento ya habrá tiempo para tratar ese tema.
Los tipos de Nodos
Ya mencioné que cada elemento en HTML es representado por un nodo en el DOM. Veamos ahora los distintos tipos de nodos que hay. Específicamente tenemos:
El nodo document que es la representación de todo el documento.
Nodos de elemento, que representan un elemento como puede ser <p></p>
Nodos de texto, que representan texto como puede ser “mi texto”
Nodos de atributo, que representan un atributo como title=”hola mundo”
Nodos de comentario, que representan un comentario <!– comentario –>
Es necesario entender los diferentes tipos de nodo ya que cada uno tiene sus peculiaridades. Algo en lo que muchos novatos caen, es pensar en elementos como entidades globales, es decir que en:
<p>Mi parrafo</p>Muchos ven a “Mi parrafo” como el valor de <p></p>. La verdad no puede estar más lejos. “Mi parrafo” no es el valor de <p></p>, más bien es un nodo completamente distinto y hasta cierto punto “independiente”. En un articulo futuro estaré hablando más sobre el DOM y explicando con código estas leves confusiones. Como dije hace un momento, mi único objetivo por ahora es poder explicar lo que el DOM es.
Por último, voy a decir que el DOM es una de las mejores cosas que le pudo pasar al mundo de la web. A través de DOM es posible modificar dinámicamente y en tiempo real muchos aspectos de una página web. En un futuro me gustaría hablar sobre DOM scripting y sobre uso responsable, amigable y degradable del DOM, pero por ahora esto es el fin de esta breve introducción.
Ajax: Introducción
September 2, 2009
Ajax es una tecnología que muchos consideran relativamente nueva. Para mí, ajax ya no tiene nada de nuevo. Su época de fama parece haber pasado, y gracias a Dios su época de abuso también, no así su tiempo de uso. Ajax sigue representando un tremendo potencial, aun que desgraciadamente son pocos los que le han sabido sacar provecho, la mayoría solo lo han abusado y jugado con él, como quien abusa de cualquier juguete. Desgraciadamente, el tremendo poder que ajax representa, se ha salido del control en las manos de unos cuantos script kiddies que no han sabido usarlo propiamente.
En esta serie voy a tratar de enseñar, no solo ajax, sino su uso correcto en base a mi experiencia como desarrollador y sobre todo como usuario consiente del verdadero potencial que la web puede alcanzar con un arma tan poderosa como ajax en nuestra bolsa de herramientas.
Empecemos por definir lo que es ajax. Para poder comprender ajax y usarlo propiamente, primero hay que entender que ajax es solo una combinación de diferentes tecnologías existentes, todas ellas unidas por un solo objeto. Ese objeto se llama XMLHttpRequest. Fue introducido por Microsoft como componente de Active X, posteriormente fue adoptado por mozilla y en la actualidad se encuentra en desarrollo una especificación por parte de la W3C. Las diferentes tecnologías que se mantiene unidas por este objeto varían dependiendo el proyecto y las preferencias del desarrollador, pero comúnmente se usan solo dos: Javascript y (X)HTML. Sin embargo, en esta ensalada de tecnologías pueden entrar en juego algunos otros componentes como puede ser PHP, XML, texto plano etc.
Mucha gente confunde ajax con DOM scripting o con el antiguo DHTML. Estos son totalmente diferentes, y por ningún motivo deben confundirse ya que eso puede traer problemas al momento de tratar de separar uno del otro para poder crear una metodología de trabajo mucho más eficiente. Por ejemplo, un buen programador querrá mantener sus mecanismos relacionados con ajax aparte de los relacionados con DOM scripting de modo que los problemas que pueda presentar puedan ser divididos a su vez en problemas más pequeños y más fáciles de solucionar. Si el programador no sabe distinguir entre ajax y DOM scripting, lo más probable es que termine mezclando ambos procesos haciendo imposible dividir el problema de la forma más eficiente y, por ende, causando que el desarrollo sea más difícil. La pregunta es, entonces, como distinguir entre uno y otro?
Ajax tiene solo un objetivo. Su principal funcionalidad está muy bien definida y teóricamente debe ser completamente sencillo poder identificar en donde empieza y termina su área de trabajo. Ajax tiene como objetivo la comunicación con el servidor de forma asíncrona. Uno de los típicos abuso de ajax es usarlo para acarrear datos del servidor al navegador por el simple hecho de no querer recargar la página, entonces terminamos con sitios que recargan todo, menos el menú, cada vez que se hace un click. El trabajo de ajax no es simplemente acarrear datos de un lado a otro, sino poder interactuar con el servidor en tiempo de ejecución y delegar tareas que han de ser ejecutadas, esperar por la respuesta y luengo entonces traer la respuesta de regreso al cliente. Solo cuando logramos entender lo que esto significa, hemos logrado entender ajax.
Para evitar su abuso, hay que considerar cada una de las tecnologías que están en juego, sus limitaciones, su desventajas y su grado de inaccesibilidad. Así también hay que poner en la balanza los beneficios que su uso puede traer y los problemas que puede causar, pero sobre todo, hay que proveer siempre de una alternativa para aquellos que por una u otra razón han de navegar si ajax.
A lo largo de esta serie vamos a hablar de formas para resolver distintos problemas. Vamos a analizar diferentes situaciones en la que podemos usar ajax y sobre todo, vamos a desarrollar una metodología de trabajo que nos permita desarrollar pensando siempre en accesibilidad para todos. Esta ha sido solo la introducción, espero poder verlos y sobre todo leer sus comentarios a lo largo de esta serie.
Next time:
La siguiente vez empezaremos con el uso de ajax y veremos algunos ejemplos prácticos de su potencial.
Formularios más inteligentes con php.
August 21, 2009
Bueno, una nota primero en cuanto al titulo del articulo. La neta que no sabía ni como llamarlo, así que el titulo igual y no sea 100% descriptivo del contenido del post.
Habiendo dicho eso, prosigamos. Hace unos días me encontraba con un dilema. Has encontrado alguna vez con un formulario que quieres que muestre una página u otra dependiendo de si la acción fue realizada con éxito o no? Bueno, pues ese era mi dilema. Es muy sencillo solucionarlo, pero yo no quería tener que cambiar la estructura de toda la aplicación (un CMS). Explico el problema para que veas un poco más de lo que hablo:
Tengo una pagina que se llama digamos “informacion.php”. Esta pagina se encarga de tres cosas, 1)agregar información nueva, 2)editar información existente y 3)borrar información existente. Para poder hacerlo toma el valor de una variable que se le pasa por GET, de modo que si la variable tiene como valor “aInfo”, la pagina muestra un formulario para poder agregar información nueva. El formulario tiene como action ‘informacion.php?modo=aInfo’, de modo que si al hacer la validación del formulario se determina que el formulario no es valido, se muestra un error y se vuelve a mostrar el formulario con los elementos que ya habían sido introducidos. Esto es por motivos de usabilidad ya que si el action del formulario fuera solo ‘informacion.php’, la aplicación no mostraría nuevamente el formulario y al presionar el enlace que nos lleva al formulario los datos de POST se perderían dejando sin posibilidad de introducir automáticamente los datos previamente introducidos por el usuario, obligando al usuario a escribir todo de nuevo en lugar de solo editar lo que estaba mal.
Algunos pueden argumentar que se puede usar GET para enviar los datos de POST al formulario nuevamente, pero eso representa más trabajo, a demás de no representar ninguna garantía debido a las limitaciones de GET e incluso podría ser perjudicial ya que el usuario pensaría que todo esta como él lo había dejado anteriormente cuando la realidad pudiera ser que un texto muy largo no haya sido incluido en su totalidad por GET, eso solo por mencionar uno de los muchos problemas que esta ’solución’ nos podría traer. Otro método igualmente ineficiente es pensar que como se implementará validación en tiempo real mediante javascript se puede confiar en que el problema será captado por javascript y no habrá necesidad de requerir al usuario que navegue manualmente al formulario nuevamente después de haberse encontrado un error en el formulario enviado.
Ninguna de estas dos opciones me convence por completo. Para que comprendas mejor de lo que hablo, muestro aquí una estructura de como está el código:
<?php
$ok = chacarFormulario(‘info’);
//checarFormulario regresa true o false dependiendo de si el formulario es o no valido
if(!$ok){
$error=”formulario invalido”;
//La variable error es capturada después por la aplicación y mostrada al usuario
}else{
//Guardo todo en la base de datos
}
?>
Si todo está bien no necesito mostrar el formulario ya que eso puede confundir al usuario a demás de que se ve feo. Si, por el contrario, hay algún error, necesito mostrar el formulario con los campos previamente llenados con la información que el usuario introdujo antes de enviar el formulario. Esta info se encuentra en $_POST, pero no entrare en esos detalles. La cosa es que para poder mostrar esa formulario action tiene que estar como ‘informacion.php?modo=aInfo’, pero eso me trae problemas si todo estuvo bien ya que para que no se muestre el formulario la variable modo no tiene que estar presente (o seteada como dicen algunos).
En otras palabras, si el formulario está correcto su action debería ser “informacion.php” y si no, el action debería ser “informacion.php?modo=aInfo”, pero claro, es imposible cambiar el action del formulario después de haberlo enviado y no hay forma de saber si el formulario es valido y así cambiar su action antes de enviarlo. Un dilema con una solución más fácil de lo que parece.
Mientras algunos empezarían a hacer raras convinaciones entre POST y GET y a usar variables para esto y para lo otro creando una pesadilla de código. Yo preferí sentarme a analizar el tema y llegue a la conclusión de que, si el problema era la existencia de la variable modo, bastaría con borrar esa variable y todo andaría bien.
Efectivamente, basta un simple unset para solucionar el problema:
<?php
$ok = chacarFormulario(‘info’);
//checarFormulario regresa true o false dependiendo de si el formulario es o no valido
if(!$ok){
$error=”formulario invalido”;
//La variable error es capturada después por la aplicación y mostrada al usuario
}else{
//Guardo todo en la base de datos
unset($_GET['modo']);
}
?>
De esta manera, para cuando la applicación llega a la parte que decide que parte mostrar (un formulario para gregar info, un listado de la información existente o una tabla con opciones de editar y borrar), lo cual hace dependiendo del valor de modo, se da cuenta que modo no existe, aún cuando en nuestra URL siga estando. Como para php modo ha sido eliminada y por consiguiente ya no existe, la aoplicación toma el valor por defecto. Para entenderlo mejor, te muestro la estructura de la parte de la app que decide que parte mostrar:
<?php
if($_GET && isset($_GET['modo'])){
switch($_GET['modo']){
case ‘aInfo’:
//muestra formulario para agregar info
break;
case ‘eInfo’:
//muestra opciones para editar info
break;
//mas de lo mismo case break, case break…
}
}else{
//si la variable $_GET['modo'] no existe entonces:
//muestra tabla con lista de info existente y opciones de borrar y eliminar.
}
?>
En caso de que todo haya estado bien, la vaiable modo es eliminada (para eso usamos unset()) por lo que cuando se llega a la parte de código apenas mostrada arriba, se ejecuta el código dentro del else{ } como si nuestro formulario hubiera sido enviado con action=”informacion.php”, cuando en realidad ha sido enviado con action=”informacion.php?modo=aInfo”.
Bueno, espero que se haya entendido por lo menos un poco. Creí que era un buen método para compartir con los visitantes de este blog. Espero sus comentarios.
Cuando encuentres un problema en una app, arreglalo.
June 28, 2009
Uf, esto va a ser como un record de errores que he aprendido a la mala. Han sido un montón, pero apenas pensé en iniciar esta serie. Ayer estaba muy tranquilo esperando que se llegara la hora de ir al trabajo. De repente me puse a pensar el cual sería la razón por la que una de mis amigas a quien invite a mi nuevo proyecto, el xismografo, no había escrito uno a pesar de haber contestado el mio sin demora. Era una de dos, o no lo había hecho, o no me había invitado a contestarlo. Ambas eran muy improbables. Decidí ir y revisar los últimos ximografos y me di cuenta que en efecto si había creado un xismografo. Entonces pensé, por que no me invito. Revise la lista de invitados y me di cuenta que sí había intentado invitarme. El problema es que todos los correos los había encerrado en un paréntesis. Por ejemplo, (uncorreo@unsitio.com). La parte de la app que envía los correos simplemente envió las invitaciones a las direcciones tal y como estaban, con paréntesis. Como es de esperarse, esas invitaciones no son validas, y aun que lo fueran, no son las correctas.
Me tocó modificar manualmente una de las tablas en mi base de dato, algo que nunca debe hacerse, pero que esta vez no tenía otra opción. Lo peor de todo es que esa posibilidad de error yo ya la había pensado, pero preferí confiar en que el usuario haría bien las cosas.
Modificar manualmente las bases de datos me trajo otro problema que aun estoy tratando de resolver. El problema no es grabe y es solo con uno de los registros anteriores. Podría decirse que puedo simplemente olvidarme del problema y que no me afectara realmente mucho, pero esa no es una opción cuando quieres que un proyecto tenga éxito.
Otro de los problemas en lo que ya había pensado, pero que también, tontamente, preferí confiar en el usuario, es que a la hora de presionar enter en un formulario, este se envía automáticamente. Por muchos tiempo estuve pensando en cancelar esa acción por que me podría causar resultados no deseados. Por ejemplo el envío de un formulario cuando aun no está completo. Me he dado cuenta que eso fue lo que le pasó a mi amiga.
Estos dos errores me parecieron poco probables que aparecieran, pero al final son los dos errores que presenta la primera persona que intenta crear un xismografo y distribuirlo. Por eso cuando piense en una posibilidad de error en algún sitio o app en la que estés trabajando. O cuando estés organizando cualquier cosa, no te dejes convencer por ti mismo pensando que es muy poco probable que pase. Mejor ponte a trabajar en prevenir y asegurar que efectivamente no pase. Generalmente soy un programador muy negativo. Siempre pensando que mis usuarios van a tratar de hackearme el sitio, que no van a saber ni como prender una compu, que no van a tener javascript activado, que no van a tener imágenes disponibles o css disponible. Trato de prevenir cualquier disfuncionalidad en mis proyectos, pero esta ves simplemente me dejé llevar por el conformismo y un poco de flojera y ahora he tenido que pagar el precio.
Esta insana carrera por el #1 en Google.
April 9, 2009
Leyendo algunos comentarios en la web me despertó el deseo por escribir este articulo. Quizá te parezca un poco exagerado afirmar que la carrera por el #1 en google es insana. Sin embargo, desde mi muy particular punto de vista sí lo es. He aquí el porque.
En nuestra carrera por llegar al #1 en Google nos hemos orientado mucho, demasiado diría yo, hacia el SEO y lo hemos adoptado como una de las principales herramientas para popularizar nuestros sitios web. Sin embargo, SEO debe ser solo un complemento en nuestros sitios web.
No es novedad que como lector apasionado me encanta defender el contenido en la web por sobre todas las cosa. Cuando me pongo en linea estoy en busca de contenido, pero no me conformo con cualquier tipo de contenido. A mi me gusta el contenido de calidad. Tristemente, entre más se popularizan ciertas técnicas eficaces del posicionamiento web, también se popularizan los resultados #1 basura en google, resultados con contenidos pobremente redactados que están en el primer puesto de google solo gracias a un buen trabajo de SEO, pero que al leerlos no aportan nada que sea realmente satisfactorio.
Puedo deducir que una de las principales causas de ese decaimiento en la calidad del contenido que se encuentra en la web es el gran esfuerzo empleado en encontrar, aplicar y mejorar las técnicas SEO para lograr una mejor posición en google el cual ha reducido el tiempo que se empleaba para revisar, corregir y editar el contenido que estamos publicando. Tristemente esta carrera por la primera posición esta dejando como resultado contenidos cada vez más pobres, pero que gracias al buen trabajo de SEO logran colocarse en las primeras posiciones en google y otros buscadores. Desgraciadamente el hecho de que un elemento esté en primera posición no nos garantiza calidad. Para mi es preferible crear contenido que sea de ayuda a mis 10 visitantes (tengo más no se crean que solo 10) que una basura que solo le quite el tiempo a 10,000 googlers quienes llegaron solo por que mi sitio es el numero 1 en google, al final de cuentas si mi contenido es de calidad tengo visitantes que vuelven y me recomiendan. Son ellos mismos quienes me hacen escalar en google y el SEO ¿que se valla al cuerno? En realidad no, pero un buen contenido, con redacción de calidad y excelentes títulos es tu primer arma en esta guerra por el número 1.
Que hacer? Muchos pensarán que empezar a evangelizar a otros es la solución. En realidad no lo es, si dar sermones fuera una solución, el mundo sería un lugar perfecto. Simplemente escribe con calidad y cuida tu contenido.
[Gracias a Panino5001 por la correción otrográfica]
Semantización Web
November 10, 2008
No se si el termino semantización web ha sido introducido anteriormente. De no ser así, me gustaría introducirlo en este articulo ya que la web ha llegado al punto en el que tanto estándares como semántica han alcanzado tal grado de importancia que sin estos dos componentes se podría desacelerar su crecimiento y evolución.
El termino semantización web se refiere al acto de impulsar la creación y redacción de sitios web que sean semánticamente correctos. Aun hoy en día, con todo el impulso y aceptación que se le ha dado a los estándares y sobre todo con el soporte que los navegadores lideres (exceptuando a IE) tienen sobre los estándares establecidos por la W3C, se ha logrado un crecimiento de las tecnologías web que no se había vivido anteriormente. Sin embargo, es triste ver que se ha relegado la semántica.
Si bien es un tema que empieza a sonar en los foros de habla hispana dedicados al desarrollo web, la semántica es aun un tema desconocido por muchos; un tema al que es necesario tratar en etapas tempranas del aprendizaje en el campo del desarrollo web. Muchos desarrolladores aun siguen preguntándose cuales son las ventajas de la llamada web semántica y hasta que punto es factible lograr que dicho concepto sea una realidad.
Para lograr la semantzación de la web es imperativo educar a las nuevas generaciones con un enfoque semántico. Pero como es eso posible si las generaciones actuales aun no han comprendido el mensaje? La respuesta está en los emprendedores que se han preocupado por impulsar el uso correcto del lenguaje base de todo sitio web; (X)HTML.
Tristemente aun hay quienes piensan que es buen idea evitar el uso de ids y clases, cuando en realidad son el complemento ideal para lograr la semantización web usando las tecnologías que tenemos al alcance en este momento.
Diseñar web, es diseñar experiencias
November 10, 2008
Hay ciertas facetas del diseño web con las que un diseñador convencional no está familiarizado. Ya muchas veces se ha mencionado que el diseño web no es diseño gráfico, pero al parecer el mensaje no ha sonado lo suficientemente fuerte, ya que seguimos viendo en la web sitios que no son mas que un folleto en Internet. Podría mostrar algunos cuantos sitios como ejemplo, pero el objetivo no es criticar a nadie.
Diseñar una pagina web, mas que crear un diseño en si, es crear una experiencia. Cada vez que un diseñador web se sienta a diseñar lo hace pensando en algo mas que colores, figuras e imágenes. El piensa en un usuario o mejor dicho, en miles de usuarios, cada uno con diferentes necesidades, experiencias y expectativas. El diseño web es mas que diseñar un folleto.
The Web and It’s New Objective
September 29, 2008
In the beginning there was the web, and it’s only objective was to be a mean of communication and information distribution. The web was created with the only objective in mind of serving as a communication system that allowed people to share different kinds of information. For that reason, one of the most important characteristics of the web was to be accessible for everyone trying to use it regardless of technology, software, hardware, device, or platform used. Nowadays, however, the web has became more like a development environment for Rich Internet Applications. It’s not that the web has lost it’s objective of being the place where sharing information is easy and fast. It is just that the web has gotten the power of creating that information instead of just sharing it.
Developer’s Minds.
September 22, 2008
There is something you won’t learn on the books or on the tutorials, something no one will teach you on the forums, and that something is how to develop a developer’s mind.
What in the world a Developer’s mind is? You may ask. It’s pretty simple, it’s the way a developer thinks of a given problem. Lets compare a situation where a developer’s mind and a regular mind face the same problem. Imagine your client comes into your office and tells you “I need a banner flying across the window every ten minutes.” A regular mind is thinking, “God, I need to create a function that can move an element across the window every ten minutes.” A developer’s mind is thinking “OK, I need a function that allows me to change the CSS left property dynamically and set an interval that fires that function every ten minutes.” This might seem like something that can make no difference, but in fact, its making a world of difference because while the regular mind is thinking about the problem, the developer’s mind is already thinking about the solution.
