Un poco sobre Buzu.
September 11, 2009
Si eres un visitante regular, sabrás que pocas veces hablo sobre mí. Irónicamente, mi intención al crear este blog era tener un blog personal. Si lees mis primeros post te darás cuenta que son más enfocados a mi persona que a la tecnología. Mi intención era mantener comunicación con mis amigos y que pudieran ver un log de mi vida personal. Sin embargo, en algún momento todo cambió y mi afición por la tecnología, especialmente la que está orientada a la web, me ganó y deje de escribir post personales. Hoy quise escribir un poco sobre mí, y de hecho estoy pensando escribir más sobre mí: resúmenes de los libros que leo, las historias que escribo, posiblemente algunos poemas, entre otras cosas. Espero no les importe mucho, y si es posible, me gustaría conocer su opinión a través de los comentarios. Ustedes, mis visitantes, son lo más importante, y lo que más me importa es escribir cosas de su interés.
Quien rayos es Buzu?
Mi identidad prefiero dejarla en las sombras, aun que claro, muchos de ustedes ya conocen mi nombre y algunos datos más. En algún momento de mi vida en la red me descuidé, o mejor dicho, dejó de importarme mantenerme en las sombras, cosa que hoy realmente lamento mucho. Mi nombre como ciudadano de la red es Buzu, aun que muchos se confunden ya que últimamente me identifico como ImBuzu, y piensan que mi nombre es ImBuzu. En realidad ImBuzu es “corto” para I am Buzu (Soy Buzu), que también puede escribirse I’m Buzu, pero como los nick names generalmente no aceptan espacios ni caracteres como el apóstrofe (‘), el nombre se reduce a ImBuzu.
Desde que era niño me encantaba la tecnología, aun que en el lugar donde crecí realmente no teníamos mucho acceso a esta, por lo que desarrollé una afición enfermiza por los relojes digitales, que eran lo más cercano que teníamos a “alta tecnología” que yo pudiera comprar. Tenía una colección de diferentes relojes, desde relojes con simples numeritos y dos puntos (:) dividiendo horas y minutos que prendían y apagaban para indicar los segundos hasta relojes tan “exóticos” que medían la cantidad de kilocalorías que quemabas al correr, pasando por los clásicos relojes de calculadora y los parlantes, entre otros. Mi sueño siempre fue comprar un reloj de pantalla táctil. Pasaba por lo menos una vez a la semana y me quedaba mirándolo y soñando que tenía “la millonada” que costaba ese reloj para poder comprarlo, pero nunca pude.
Mis programas de TV favoritos eran caricaturas como Voltron, Mazinger Z, Transformers y todo lo que tuviera robots. Mis juguetes preferidos eran robots. Mi vida giraba al rededor de la tecnología, aun que yo ni siquiera lo sabía.
A lo largo del camino me desvíe. Me dedique al skate, dejó de interesarme la relojería, y eventualmente me olvidé de los robots, aun que mi interés por ellos nunca murió. Durante mucho tiempo tuve una computadora en casa a la que ni me acercaba, a pesar de que mis hermanos se quedaban horas pegados a ella editando música y video. Yo prefería salir a caminar, hacer ejercicio y patinar. En esas épocas mi vida era el skate, el hip hop, el punk, y la cultura urbana.
Uno de las aficiones que nunca me dejó fue la afición a los videojuegos. Si existe algún gen del videojuego, creo que lo tengo doble. Tal es mi afición a los videojuegos, que hoy en día prefiero evitarlos para no caer en una adicción que me enajenaría completamente. Recuerdo que muchas veces mi mamá me fue a “visitar” a los videojuegos con cara de pocos amigos, pero claro, cuando te escapas sin permiso no puedes esperar que te feliciten.
No fue sino hasta finales de 2005 que volví al buen camino. Por asares del destino me encontré que una amiga tenía uno de los spaces o espacios que ofrecía hotmail y decidí hacer uno, aun que en realidad nunca lo usé. Empecé a ver que algunos ponían los llamados cuadros flotantes e imágenes entre otras cosas y me interesó. Empecé a buscar como hacer esos “trucos” para “tunear” el espacio, y así fue que conocí HTML.
HTML me abrió los ojos a un mundo completamente nuevo: el mundo del desarrollo web. A pesar de que para ese entonces yo ya usaba internet, nunca me había puesto a pensar en que era lo que hacia funcionar las páginas web. Mi idea de internet era muy remota. Yo conocía internet del lado del cliente, pero el lado del desarrollo era algo completamente nuevo y excitante.
Empecé a investigar lo que podía sobre el tema, pero muchas veces terminaba confundido y frustrado por no entender muchas cosas. Ahora me doy cuenta que mi error era no saber ni lo que estaba leyendo. Me daba igual leer sobre php, javascript o HTML. Para mí, eran la misma cosa. No fue sino hasta que me leí la especificación de HTML que comprendí realmente lo que estaba haciendo. Afortunadamente, desde el principio de mi carrera como desarrollador web me apegué a la W3C, por lo que aprendí sobre estándares, especificaciones, accesibilidad y otras cosas. También aprendí el nexo entre HTML y CSS. Ya me había devorado la especificación de HTML, y seguramente hacer lo mismo con la de CSS no caería mal. Me pasé, literalmente, un día entero frente a la computadora leyendo la especificación de CSS. Cuando terminé era la madrugada y me dolía la cabeza. Mucha gente se sorprendía de mi manejo que tenía sobre el tema y me preguntaban que como era posible que se me hiciera tan fácil, por lo que, considerando la experiencia de la lectura de las especificaciones de HTML y CSS, decidí crearme una frase: “No es que para mí sea más fácil, sino que yo me esfuerzo más”. Era un poco presuntuosa, pero me hacia sentir bien, porque me recordaba el esfuerzo y empeño que le ponía a esto.
Una vez que dominé HTML y CSS pensé que era suficiente. Decía que jamás aprendería Javascript. Se veía muy complicado y había leído que en las empresas había gente que hacia todo lo relacionado con HTML y CSS y había otros, los llamados programadores, que se encargaban de hacer todo lo demás. Para mí era suficiente con HTML y CSS. De hecho, el solo pensar en XHTML me daba flojera. Ahora que lo pienso, creo que el entusiasmo con el que empecé a aprender se me había ido.Un día, sin embargo, pensé que estaría cool poder abrir pop ups, mandar alertas y hacer rollovers. Sin más, empece con Javascript.
El javascript era otro chango. La información no se encontraba toda en un lugar como era el caso de HTML y CSS cuyos manuales estaban en la W3C. Javascript era una bestia que había que estudiar un poquito aquí y otro poquito aya. Entre tanta búsqueda llegué a desarrolloweb.com. Me sentí iluminado cuando vi que tenían un manual bien detallado de Javascript. Sin perder tiempo lo descargué y lo leí. Por alguna razón me volví bueno en poco tiempo. Hoy en día javascript es uno de mis fuertes.
La historia se repite, cada vez que aprendía algo nuevo, me decía a mi mismo que no aprendería más, que alguien en el mundo se podía encargar de eso. Sin embargo, así como con Javascript, un día descubrí que sería cool poder hacer otra cosa, pero esa otra cosa requería php, luego mysql, luego quise aprender sobre seguridad y luego sobre otros temas.
Han pasado unos cuatro años desde que empecé, en algún momento durante esos cuatro años me tomé un año y medio sin actividad. Hoy en día creo que realmente he avanzado un buen tramo desde aquellos días de ventanas flotantes en los espacios de hotmail, y la verdad me llena de satisfacción ver lo que he logrado. Creo que he ganado un lugar respetable en la comunidad y me siento feliz por ello. He conocido grandes personas como Panino5001, a quien admiro mucho y Jseros, a quien considero un gran amigo, entre muchos otros. Tengo este blog, al que visita gente sumamente agradable en sus comentarios y que me ha permitido conocer a gente como albertox, quien nos sigue muy de cerca (gracias). Mi historia como desarrollador web tiene capítulos obscuros como cuando aprendí flash y me enfoqué en el, pero la verdad no considero esas partes dignas de ser mencionadas. En algún momento me sentí un hombre experto, pero hoy en día con humildad acepto que soy solo un niño jugando a programar en comparación con verdaderos cracks del mundo web. Creo tener mi propio estilo de programación y realmente no sigo a nadie en especifico, es decir, no tengo un programador del que diga que quisiera ser como él. Simplemente quiero marcar mi propio estilo y dejar mi propia huella.
Por supuesto que hay muchísimo más que contar sobre Buzu. Por ejemplo, por que me gusta decir que Buzu es solo la voz dentro de mi cabeza y por que muchas veces hablo en tercera persona como:
“Y el buzu que pensaba que era bueno en javascript”
Pero creo que por hoy ha sido demasiado. Realmente me gustaría conocer su opinión en cuanto a publicar sobre otros temás y no solo web. Les gusta la idea, o preferirían que me abriera otro blog totalmente independiente. También me gustaría que compartieran su historia, si tienes un enlace hacia tu historia o si decides escribirla, avísanos y estaremos encantados de pasar a leerla.
AIR: Estilizando y extendiendo nuestras aplicaciones (CSS y Javascript)
September 7, 2009
NOTA: Es recomendable que antes hayas leído los siguientes artículos:
Hello AIR: desarrollo de aplicaciones usando AIR de forma sencilla
AIR: desarrollando y probando nuestras aplicaciones
Caminando sobre el aire
Hemos visto ya los conceptos básicos de AIR, el uso de las herramientas de desarrollo que vienen incluidas en el SDK de AIR, hablamos sobre seguridad y hasta probamos nuestra primer aplicación usando adl. En esta tercera entrega de la serie de desarrollo en AIR hablaremos un poco más sobre seguridad, como desarrollar haciendo uso de los sandboxes y como aplicar estilos y un poco de javascript a nuestras aplicaciones.
NOTA: Esta serie no intenta por ningún motivo ser una guía sobre CSS o Javascript. Se asume que el lector tiene conocimientos sobre los lenguajes, por tal motivo los códigos serán explicados sin profundizar demasiado y solo cuando el autor lo crea necesario. Si hay mucha demanda, podemos iniciar una serie sobre Javascript y CSS (manifestarlo en los comentarios).
Creando un cliente AIR para twitter
Antes de empezar, veamos un ejemplo muy sencillo, pero que espero nos suba el ánimo. Se trata de una aplicación que lo único que hace es conectarse a twitter y permitirnos actualizar nuestro estado. La aplicación no es muy útil y en ningún momento intenta competir con las aplicaciones ya existentes para twitter. Lo que es más, la aplicación no es pensada para su uso en la vida real, sino más bien para demostrar la sencillez con la que se puede interactuar con servicios como twitter a través de AIR y javascript haciendo uso de las APIs ofrecidas por estos servicios.
El XML:
<?xml version="1.0" encoding="utf-8" ?> <application xmlns="http://ns.adobe.com/air/application/1.0"> <id>com.wordpress.imbuzu.TwitterClient</id> <filename>TwitterClient</filename> <name>Twitter Client</name> <description>Un cliente simple para enviar mensajes a twitter.</description> <version>0.1</version> <initialWindow> <content>TwitterClient.html</content> <title>Twitter Client</title> <systemChrome>standard</systemChrome> <transparent>false</transparent> <visible>true</visible> <minimizable>true</minimizable> <maximizable>true</maximizable> <resizable>true</resizable> </initialWindow> </application>
El HTML, Javascript y CSS
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="es" lang="es">
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8" />
<title>Twitter Client</title>
<script type="text/javascript">
function msjOk(msj){
ok = msj.value.length <= 140 ? true : false;
return ok;
}
function hayMsj(msj){
ok = msj.value.length > 0 ? true : false;
return ok;
}
var form;
window.onload = function(){
form = document.getElementById('formulario');
msj = document.getElementById('mensaje');
error = document.getElementById('error');
form.onsubmit = function(){
if(!hayMsj(msj)){
error.innerHTML = "No hay mensaje para enviar";
return false;
}else if(!msjOk(msj)){
error.innerHTML = "Tu mensaje contiene más de 140 caracteres";
return false;
}else{
xhr = new XMLHttpRequest();
xhr.onreadystatechange = function(){
if(xhr.readyState == 4){
if(xhr.status == 200){
error.innerHTML = 'Twitter actualizado';
}else{
error.innerHTML = 'Ha ocurrido un error. Intenta de nuevo. <br /><b>Twitter Response<\/b> <br />' + xhr.responseText + "<br />Status code: <br />" + xhr.status;
}
}
}
xhr.open("POST", "http://twitter.com/statuses/update.xml", true, 'usuario', 'clave');
xhr.setRequestHeader("Content-Type", "application/x-www-form-urlencoded");
xhr.send('status=' + escape(msj.value));
return false;
}
}
}
</script>
<style type="text/css">
body{
text-align: center;
}
h1{
margin: 0;
color: #FFF;
background-color: #0F0;
}
textarea{
width: 98%;
height: 50px;
}
#error{
color: #F00;
}
</style>
</head>
<body>
<div id="pantalla">
<h1>Twitter Client</h1>
<h2 id="error"></h2>
<form id="formulario">
<p>
<textarea id="mensaje" name="mensaje" rows="20" cols="10"></textarea>
</p>
<p>
<input type="submit" name="enviarTwit" value="enviar" />
</p>
</form>
</div>
</body>
</html>
Esta ocasión he incluido el HTML, CSS y Javascript en un mismo archivo. En la vida real es recomendable que se mantengan separados por cuestiones de mantenimiento.
Si copias y pegas esos dos bonches de código, al primero lo llamas TwitterClient.xml, al segundo TwitterClient.html. Los guardas en un folder llamado TwitterClient y los pruebas como vimos anteriormente, verás algo como esto:
La interfaz es de lo más sencilla y su funcionamiento aún más. Para poder hacer uso tendrás que cambiar lo siguiente antes de probar la aplicación:
xhr.open("POST", "http://twitter.com/statuses/update.xml", true, 'usuario', 'clave');
cambia usuario por tu nombre de usuario en twitter, por ejemplo el mío es imbuzu.
cambia clave por tu clave, por ejemplo la mía es: 0-0 pensaste que te la daría? jajaja.
Como ese es solo un ejemplo no me voy a tomar el tiempo para explicar su funcionamiento, pero en poco tiempo estaremos haciendo aplicaciones aún más avanzadas que esta.
Ahora, hablemos sobre cajas de arena.
Usando el application sandbox:
El application sandbox no presenta restricciones mientras se inicializa el código, es decir, antes del evento onload. Una vez se ha cargado la aplicación, sin embargo, la cosa es diferente. Algunas de las restricciones que puede encontrar son con la función eval, el uso de Function (nótese la F mayúscula), el uso de strings en setTimeout y setInterval, el pseudo protocolo javascript:, el uso de document.write, el uso de innerHTML está limitado a solo texto plano, se prohibe el uso de script.src para apuntar una etiqueta script a otro documento diferente al inicial y algunas restricciones en cuanto al uso de XMLHttpRequest de forma sincrónica. Tener en cuenta estas restricciones nos hará más fácil la vida y dará claves sobre algunos errores que podemos encontrar.
Usando el non-applicattion sandbox:
El código cargado en el non-application sandbox está sujeto a las mismas restricciones que en la web. Además, no tiene acceso a ninguna de las APIs de AIR
Creando un puente entre los dos sandboxes.
AIR nos brinda la posibilidad de crear una interfaz llamada Sandbox Bridge. Este Sandbox Bridge no es más que un puente que nos permite comunicación directa y vi-direccional a través de una API entre el application sandbox y el non-application sandbox. Su uso puede resultar extremadamente útil en algunos casos, ya que nos brinda la posibilidad de comunicar dos extremos de la aplicación que de otra manera son incomunicables. Por ahora basta con saber que existe dicha posibilidad. Ya veremos su uso más adelante.
Usando CSS:
CSS es, como en la web, el componente en nuestra bolsa que nos va a dar la posibilidad de darle una presentación y personalidad a nuestras aplicaciones. Una de las bondades ofrecidas por AIR tanto para CSS como para Javascript es que usa webkit, el motor de Safari. Al ser solo un motor para todos los sistemas operativos, no tenemos que preocuparnos por diferencias en cuento a la implementación de las propiedades, funciones y métodos. Si funciona en Safarí, es 99% probable que funcionará en AIR. Si funciona en tu computadora, funcionará de igual manera en cualquier otra aun cuando tenga un sistema operativo diferente.
Como mencioné hace un momento, es recomendable que el CSS se mantenga completamente aparte del HTML. Una de las características de este lenguaje es que ha sido pensado para funcionar desde fuera del documento que modifica gráficamente. Mantener nuestro CSS de forma separada del resto de la aplicación nos dará la oportunidad de poder modificarlo libremente sin tener que tocar ninguna otra cosa que no sea CSS puro.
Como ya mencioné, CSS en AIR no representa las limitaciones que muchas veces representa en la web, especialmente con navegadores como IE6 o IE en general. Esto es una ventaja enorme ya que podemos usar selectores de forma avanzada y hacer uso de pseudoselectores como :before y :after, además de propiedades extremadamente útiles como content. Una desventaja es que webkit no soporta CSS expressions (exclusivas de IE), pero claro, siempre hay un camino al rededor de esta situación.
Veamos un ejemplo de CSS en AIR.
Continuando con la aplicación AIRHelloWorld que construimos en la entrega anterior, procedamos de la siguiente manera:
1)Abre AIRHelloWorld.html
2)Agrega la siguiente linea justo después de
<title>AIRHelloWorld</title>: <link rel="stylesheet" href="estilos.css" type="text/css" media="screen" />
3)Crea un nuevo archivo y guardalo con el nombre estilos.css en la misma carpeta donde tienes AIRHelloWorld.html y AIRHelloWorld.xml.
4)En el nuevo archivo pon lo siguiente:
body{
background-color: #CC6;
color: #FFF;
margin: 0px;
}
H1{
background-color: #9C3;
margin: 0;
height: 35px;
text-align: center;
}
p{
font-size: 1.5em;
padding: 5px;
border-bottom: 2px #CCC solid;
}
5)Prueba la aplicación usando adl y verás los cambios. La aplicación sigue sin hacer nada, pero ya tiene un formato y un estilo que la hacen ver mejor que antes. Puedes seguir jugando con CSS y probar. Es más, te invito a que estilices tu aplicación y nos muestres una captura de pantalla para ver como queda!
Usando Javascript:
Al igual que CSS, javascript también puede ser implementado en nuestras aplicaciones AIR. Como vimos hace un momento su funcionamiento depende mucho del sandbox en el que se ha cargado, pero la mayor parte del tiempo es muy similar al de la web. Veamos un sencillo ejemplo de como hacer que nuestros elementos “aparezcan” con un desvanecido de entrada.
1)Nuevamente modifica el archivo AIRHelloWorld.html agregando la siguiente linea después del enlace hacia la hoja de estilos que hiciste en el primer paso de la sección anterior sobre CSS:
<script type="text/javascript" src="difuminado.js"></script>
2)Crea un nuevo archivo y guárdalo como difuminado.js dentro de la misma carpeta de tu proyecto.
3)En el nuevo archivo introduce lo siguiente:
//función difuniado
//autor: Buzu
//fecha: agosto 10 de 2009
//primera revisión
//modificada para el tutorial de AIR en MDW
//por hacer: Agregar eventos onInit y onFin
function difuminado(elem, inOut, duracion){
var $elem = (typeof elem).toLowerCase() == 'string' ? document.getElementById(elem) : elem;
var $modo = inOut || 'entrada';
var $duracion = (duracion < 100 ? duracion * 1000 : duracion) || 2500;
if($modo == 'entrada'){
var $alfa = 0;
var $intervalo = setInterval(
function(){
if($alfa < 100){
$alfa += 100 / ($duracion/100);
$elem.style.opacity = $alfa/100;
}else{
$alfa = 100;
clearInterval($intervalo);
$elem.style.opacity = $alfa/100;
};
}, 100
);
}else if($modo == 'salida'){
var $alfa = 100;
var $intervalo = setInterval(
function(){
if($alfa > 0){
$alfa -= 100 / ($duracion/100);
$elem.style.opacity = $alfa/100;
}else{
$alfa = 0;
clearInterval($intervalo);
$elem.style.opacity = $alfa/100;
};
}, 100
);
}else{
return alert('El modo debe ser "entrada" o "salida"')
}
}
window.onload = function(){
difuminado('pantalla');
}
Esta es una función que yo ya tenía y que he modificado para este tutorial. Lo que hace es permitirnos hacer difuminados de entrada y salida. En este caso estamos aplicando un difuminado de entrada a nuestro elemento pantalla que es el que contiene todos los demás elementos. Guarda tu archivo y vuelve a probar la aplicación usando adl y verás como los elementos aparecen poco a poco.
Como ya dije, esta serie no pretende detenerse a explicar conceptos sobre Javascript, pero si tienes dudas sobre el código usado, eres bienvenido a escribirlas en los comentarios y con gusto te ayudaremos.
Como vez, el uso de javascript y CSS es muy similar al uso de estos elementos en la web. Una de las grandes ventajas es que ahora, en AIR, desarrollas para un solo motor de render y no para muchos como en la web.
Por último, si te apetece extender la aplicación de twitter y después compartir con nosotros tus resultados, eres totalmente bienvenido. Dejo el código abierto para su uso, aun que sea una base muy precaria.
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.
Software pirata, vale la pena?
August 23, 2009
En la actualidad hay una creciente demanda de software. Programas como Photoshp, el swite de Office, Dreamweaber, entre otros, son usados por millares. Sin embargo, un porcentaje (muy grande diría yo) de las copias de dicho software corriendo por ahí son piratas. El termino pirata no es nuevo, y tampoco comenzó con el software. Desde que había casetes y beta para las películas ya existía la piratería. Es más, desde mucho antes ya se hacían copias piratas de pinturas, esculturas y otras obras de arte. La pirataría puede ser tan vieja como el hombre mismo, y hasta hoy sigue vigente y popularizandoce gracias a la fácil distribución de material virtual mediante la red.
Si quieres el último hit del pop, lo encontrarás de forma gratuita en la red; la última película? también está en la red; una película que se estrena la semana que viene? también está en la red. Hoy en día todo se encuentra en la red, incluso el software. Desde una simple aplicación que no cuesta más de un par de dolares, hasta sistemas operativos completos y software de varios cientos o miles de dolares. Pero, vale la pena arriesgarse?
Quien va a saber que mi software es pirata? Es la respuesta que muchos dan y la forma en la que se tranquilizan, y es que es cierto, quien rayos va a saber que el software que tienes en tu cuarto donde nadie entra, en tu computadora de escritorio que nunca sale de tu cuarto, es pirata? Aún cuando la computadora esté todo el tiempo conectada a internet, las posibilidades de que alguien detecte que tu software ha sido crackeado son muy remotas. Entonces, en donde está el riesgo?
Pareciera que no hay riesgo verdad? Y siendo así, si que vale la pena ahorrarte aun que sea un par de dolares, y mucho más aún, un par de miles de dolares, pero piénsalo dos veces. Muchos chavitos se piensan que por tener todo, hasta su OS pirata, son unos cracks usando computadoras. Alardean con sus amigos sobre sus “habilidades” para conseguir desde el último CD de shakira, hasta la última versión de phothoshop. Cuando los escucho, me río de sus hazañas.
El verdadero riesgo del software crackeado es que cada que instalas uno de esos, te estas instalando la posibilidad de que aquel que crackeó esa pieza de software, también se tomó el tiempo de amablemente instalar otra cosita. Esa cosita puede ir desde un virus molesto, hasta uno que te deje la computadora inservible. Otra posibilidad, más peligrosa aún, es que el software venga con una puertita trasera que le de de entrada al crackeador a tu computadora. Tu computadora puede volverse un zombie para alguien que se pretende vaciar el banco de america y dejar toda la evidencia apuntando hacia a ti.
Por supuesto que esto no pasa muy seguido, y probablemente no conoces a nadie a quien le haya pasado algo similar. Sin embargo, una de las principales reglas de seguridad informática es ser siempre paranoico hasta cierto grado en ese aspecto.
Obteniendo software gratuito.
Si lo que te gusta es el software gratis, hay opciones. Puedes, por ejemplo, buscar software gratuito en la red, hay mucho. Desde simples reproductores de música y video, hasta software más especializado y avanzado como el que se usa para hacer modelado y animación en 3D.
El software de este tipo se clasifica en varias secciones. Tenemos, por ejemplo, el freeware, que es software completamente gratis. Si descargas de este tipo de software, asegúrate primero de investigar un poco sobre el mismo. Solo ve a google y busca por el nombre del software. Si el software se llama “picplus”, solo ve y busca picplus. En este caso los resultados que te lleven a foros de discusión son los más útiles ya que podrás encontrar info sobre su rendimiento, calidad y seguridad. También podrás saber si el software es confiable. Si quieres estar más seguro, averigua un poco sobre el nombre (ya sea de una empresa o un indibidual) detrás del software, es decir, quien lo ha manufacturado. Hay quienes solo hacen software gratis para poder instalarte software malicioso y tener acceso a tu computadora. Finalmente si has visto que todo está bien, descarga el software desde un sitio confiable. Si es posible, desde la página oficial del producto. Yo por ejemplo, busco en softonic, pero generalmente descargo desde la página oficial del producto (softonic generalmente ofrece un enlace hacia dicha página).
En la mezcla de sabores también tenemos el shareware. Este es software por el que alguien pudo haber pagado o no, pero que tiene una licencia que permite su distribución libre. En este caso también combiene investigar sobre el autor de software y, además, sobre quien lo está distribuyendo. Recuerda, todo software puede ser modificado y representar un riesgo. Mantén los ojos bien abiertos.
Otra opción es el software open source. Este es de mis favoritos, aun que no soy un fanático de Open source. La ventaja de este software es que es un libro abierto, cualquier persona puede hacerse de una copia del código, mejorarlo, y después compartirlo. Por tal motivo, este software está en constante mejoría. Uno de los argumentos que escucho seguido en contra de este tipo de software es que, al ser de código abierto y fácil de modificar por cualquier persona, es muy fácil para alguien modificarlo de modo que represente un peligro. La verdad es que si y no. Mientras es muy sencillo que eso pase, es más sencillo aún que la comunidad lo note y arregle el problema. Además, la comunidad open source está formada por gente que se cuida y cuida a otros. En este caso, las recomendaciones son las mismas, bajar software solo del sitio oficial del producto y si puedes, por que no, mejorarlo un poco y compartirlo.
Hay muchos sabores de software gratuito. Algo que si quiero aclarar es que software libre y software de código abierto no es lo mismo. El primero puede ser gratis y nada más, mientras que el segundo, aparte de todo, brinda la posibilidad de ser modificado sin que es estés infringiendo ninguna ley, además de mantener toda una comunidad, muchas veces de cientos, e incluso miles de desarrolladores respaldando la calidad del producto.
Si aún así no te convences, o si somplemente necesitas si o si el photoshop (por decir algo), hay formas. Puedes buscar como crackearlo tu mismo, puedes buscar un generador de claves para hacerte una licencia como si lo hubieras comprado, puedes buscar en la red por una clave para desbloquearlo, puedes instalarte la versión de prueba si solo lo necesitas para hacer un par de cosas. Hay tantas cosas que se pueden hacer, pero por favor, no instales software pirata o crackeado por alguien más. Estas comprometiendo la seguridad de tu máquina y te estas comprometiendo a ti mismo.
Por último, dejo un enlace a una lista de software gratuito.
http://en.wikipedia.org/wiki/List_of_open_source_software_packages
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.
Javascript Orientado A Objetos Segun Buzu: los métodos
June 14, 2009
Hace ya un buen tiempo que dejé inconclusa una serie de artículos sobre Programación Orientada a Objetos en Javascript. Bueno, aquí traigo esta última entrega, y aun que en la anterior prometí que en esta entrega haríamos una librería, creo que eso quedará más bien fuera del contexto ya que dicha librería no usa mucho los conceptos de POO de los que hemos estado hablando. Sin embargo, ya abriré otra serie para ir creando dicha librería. Más que por el gusto de crear la librería, por el gusto de tocar algunos temas en Js que no se tocan mucho. Bueno, pero eso será en un futuro. Por ahora me limitaré a hablar sobre cuatro tipos de métodos que pueden ser usados especialmente cuando estamos programando basados en constructores do objetos.
Dependiendo de lo que queramos lograr y de la accesibilidad que queramos darle a los métodos de nuestros objetos podemos usar uno de cuatro tipos de métodos: públicos, privado, privilegiados y estáticos. Empecemos analizando de adentro a afuera, es decir, con métodos privados.
Métodos privados:
Lo métodos privados no son accesibles desde fuera del objeto. Como su nombre lo dice, estos métodos son privados. Nos interesa usar métodos privados por ejemplo cuando queremos darle a nuestro objeto una funcionalidad que no nos interesa o que no nos conviene que sea posible acceder desde fuera del objeto. Consideremos el siguiente ejemplo:
Nota: también hay propiedades privadas y son más comunes que los métodos privados.
function miObj(){
var nombre = 'Nombre Privado';//propiedad privada
function privada(){//Método privado
alert('función privada');
}//fin del método privado
}
En este caso, el método privada() no puede ser accedido desde ningún lugar fuera de miObj();, es decir que:
var obj = new miObj(); obj.privada();//tira un error.
No es valido por que no hay nada que ligue privada() con el exterior. Pero entonces por que querías un método que no se puede llamar desde ningún lado? Una de las razones es para mantenerte organizado y seguir una de las mejores prácticas de la programación. Me refiero a que cada función tiene que tener solo un trabajo. Por ejemplo:
function miObj(){
function mostrarOpciones(){
//Codigo para mostrar opciones
}
function crearCanvas(){
//Código para crear canvas
}
mostrarOpciones();
crearCanvas();
}
Esas dos funciones se ejecutan al mismo tiempo por lo que daría igual hacer lo siguiente:
function mi Obj(){
//Código para mostrar opciones
//Código para crear canvas
}
Sin embargo, es mucho más fácil y legible una función que tiene un solo objetivo ya que 1) todo el código está relacionado entre sí, y 2) hay menos lineas de código. Además de que al haber más funciones hay más probabilidades de que un error sea identificado con mayor precisión.
Métodos privilegiados.
Hace un rato vimos los métodos privados. Pero si tienes ojo de debugger, seguro que te diste cuenta que también hemos puesto una propiedad privada (nombre). Al igual que el método privado, la propiedad privada no puede ser recuperada desde fuera del objeto. Es decir que si hace:
alert(obj.nombre);
te va a dar como resultado una alerta que dice undefined. No es un error del navegador. Es simplemente que no tienes los permisos necesarios para acceder a esa propiedad, porque está “encerrada” dentro de las fronteras de miObj(). El uso de propiedades privadas es muy útil cuando quieres establecer valores que no quieres que sean modificados desde fuera del objeto. Por ejemplo, una velocidad que quieres que se mantenga constante cuando realizas una animación, o algún valor que no quieres que sea modificado. Considera el siguiente ejemplo:
function animador(){
var velocidad = .1;
}
var animcion = new animador();
En este caso hemos creado un constructor (animador()) que contiene una propiedad privada (velocidad). Esta propiedad la hemos puesto privada por que no queremos que la velocidad de animador pueda ser cambiada usando:
animacion.velocidad = .5;
ya que probablemente eso causaría resultados inesperados.
Pero entonces si no se puede acceder a la propiedad, para que nos sirve? Bueno, en realidad para nada, por lo que es necesario encontrar una forma de poder acceder a la propiedad. Para eso están los método privilegiados.
Como su nombre lo indica, estos métodos tiene privilegios especiales. Piensa en ellos como si tuvieran su propia puerta para entrar y salid del contexto de su contenedor, en este caso miOBj();
Volvamos a nuestro ejemplo el cual hasta ahora va así:
function miObj(){
var nombre = 'Nombre Privado';//propiedad privada
function privada(){//Método privado
alert('función privada');
}//fin del método privado
}
var obj = new miObj();
Hagamos uno cambios en miObj():
function miObj(){
var nombre = ‘Nombre Privado’;//propiedad privada
function privada(){//Método privado
alert(‘función privada’);
}//fin del método privado
//agregamos método privilegiado
this.obtenerNombrePrivado = function(){
return nombre
}
}
El método obtenerNombrePrivado() es privilegiado, lo cual quiere decir que puede acceder a los métodos y propiedades privados declarados dentro de miObjt(). Esto tiene que ver con lo que se conoce como scope. Trataré de explicarlo:
Al ser declarada dentro de miObj(), otenerNombrePrivado() tiene acceso a las variables locales de miObj(), en nuestro caso solo tenemos una variable local (nombre). Esto por que al ejecutarse obtenerNombrePrivado() se ejecuta dentro del contexto y las fronteras de miObj() en donde nombre si existe.
Ahora podemos acceder a nuestra propiedad privada (nombre) sin ningún problema, pero sigue siendo imposible cambiarla:
function miObj(){
var nombre = 'Nombre Privado';//propiedad privada
function privada(){//Método privado
alert('función privada');
}//fin del método privado
//agregamos método privilegiado
this.obtenerNombrePrivado = function(){
return nombre
}
}
var obj = newObj(); alert(obj.obtenerNombrePrivado());//regresa Nombre Privado
Cabe aclarar que los métodos privilegiados siguen siendo métodos públicos, razón por la cual se pueden acceder desde fuera del objeto.
Métodos Públicos
Los métodos públicos están disponibles desde fuera del objeto. Es decir que son accesibles. Su uso es prácticamente para poder brindar formas de manipular el objeto o de acceder a sus funciones y ejecutar sus comandos. He visto a muchos que hacen lo siguiente para declarar método públicos:
function otroObj(){
this.publico1 = function(){
//código de publico1
}
this.publico2 = function(){
//código de publico2
}
this.publico3 = function(){
//código de publico3
}
this.publico4 = function(){
//código de publico4
}
}
Esto, aun que parezca correcto, es una forma ineficaz de hacerlo. Tener en cuenta que estos no son métodos privilegiados, es decir que no tiene que acceder a ninguna propiedad privada del objeto.
La razón por la que ésta forma de hacer las cosas no es la mejor es por que con cada copia que hagamos de nuestro objeto, estamos “clonando” todas esa funciones y podemos llegar a sobre cargar la memoria. Una de las grandes bondades de Js, es que es un lenguaje basado en prototipos.
Que es un prototipo?
Un prototipo es la forma en que Js nos brinda la oportunidad de extender un objeto. Es decir, a través de un prototipo podemos agregar funcionalidad a un objeto que de otro modo sería poco posible. Al inicio, la palabra prototipo puede sonar un poco intimidatoria. Sin embargo, no hay nada del otro mundo envuelto en esta palabra.
Creando métodos públicos usando prototipos
Para crear un método público de una forma más eficaz, es necesario usar el prototipo de nuestro objeto:
otroObj.prototype.publico1 = function(){
//código de público 1
}
De esta manera evitamos clonar publico1 cada vez que creamos una nueva copia de otroObj ya que el prototipo no se clona. El prototipo más bien permanece al alcance de los objetos creados a partir del objeto base (otroObj) pero no está contenido dentro de ellos. Piensa en el prototipo como una caja de herramientas que es compartida por un numero determinado de carpinteros. Sin importar cuantos carpinteros agregues, siempre va a seguir habiendo una caja de herramientas y todos los carpinteros tendrán acceso a ella.
Una vez que actualices el prototipo de un objeto, todos los objetos creados a partir de dicho objeto tendrán acceso al prototipo actualizado y no al prototipo existente al momento de ser creados. Volviendo a nuestra analogía con los carpinteros, supongamos que al principio ponemos un carpinteros y una caja de herramientas. La caja de herramientas contiene un serrucho y un martillo. nuestro carpintero puede hacer uso de cualquiera de ellos. Después ponemos otro carpintero, quien a su vez puede hacer uso tanto del martillo como del serrucho. Después “actualizamos” la caja de herramientas y agregamos una lijadora. Ambos carpinteros siguen teniendo acceso a las tres herramientas aun que la caja solo tuviera dos herramientas cuando los carpinteros fueron agregados. Esa es mas o menos la forma en que trabajan los prototipos.
Una forma de hacer uso del prototipo de un objeto es mediante OLN.
otroObj.prototype = {
publico1: function(){
//...
},
publico2: function(){
//...
}
}
De esa manera podemos organizar los prototipos de una mejor manera y ahorramos algunos cuantos caracteres.
Métodos estáticos
Por último hablemos de uno de los tipos de métodos menos comunes, los métodos estáticos. Los métodos estáticos no son de ayuda en la mayoría de los casos. La razón de esto es por que no pueden ser usados más que por el objeto base. Estos métodos son más bien de utilidad cuando estamos creando un objeto y no un constructor. Ejemplo:
var obj = new Object();
obj.método1 = fucntion(){...}
pero también se pueden usar cuando se están creando constructores:
function miObj(){
var nombre = 'Nombre Privado';//propiedad privada
function privada(){//Método privado
alert('función privada');
}//fin del método privado
//agregamos método privilegiado
this.obtenerNombrePrivado = function(){
return nombre
}
}
miObj.estatico = function(){
alert('estatico');
}
var obj = newObj();
miObj.estatico();// da una alerta: estatico
obj.estatico();// Causa erro: obj.estatico() is not a function
A diferencia del ejemplo que vimos anteriormente en el que con cada copia del objeto clonabamos todos sus métodos públicos, los métodos estáticos no se copian y pertenecen solo al objeto base. Por lo que en nuestro ejemplo, obj.estatico() nos tira un error ya que no hay ninguna función que se llame estatico() relacionada con obj. Por el contrario, miObj.estatico() funciona perfectamente.
Esto nos puede ser útil en algunas ocasiones, especialmente cuando queremos extender un objeto sin afectar a todos los demás que hayan sido creados a partir del mismo objeto.
Hay más cosas que decir en cuanto a los Métodos de un objeto y todavía se nos a quedado en el teclado conceptos como herencia en Js, pero por ahora me despido esperando que haya sido una buena lectura.
Algunos apuntes sobre funciones Javascript
June 10, 2009
Pues hace ya un rato desde el último articulo. Hoy me he inspirado y he hecho algunas pruebas de funciones en Javascript. Básicamente de diferentes forma de crear funciones, he aquí mis resultados no tan científicos y no tan estudiados ^-^.
Formas de crear funciones:
Hay diferentes formas de crear funciones, y dependiendo de lo que quieras hacer quizá quieras usar una o otra. Aun que generalmente no importa como declares tu función, nada mal hace el saber.
Lo más conocido:
La forma más sencilla y conocida de declarar funciones es la siguiente:
function alertar(){
alert('ups!');
}
De esta manera hemos creado una función, y para llamarla solo necesitamos hacer referencia a ella:
alertar();
Así que, que hay de especial con esta forma de declarar funciones? Probablemente no mucho, excepto claro que te deja llamar a la función aún antes de que esta sea declarada:
alertar();
function alertar(){
alert('ups!');
}
Pero probablemente eso ya lo sabias. Lo que es más, probablemente pensabas que es la forma en que todas las funciones reaccionan. Sin embargo no es así.
Otro metodo:
La siguiente es otra forma también muy conocida de crear funciones, pero que se comporta de forma un poco diferente a la forma que hemos visto anteriormente.
Se puede asignar una función a una variable:
var alertar = function(){
alert('ups!');
}
Solo que a diferencia de la forma que hemos visto anteriormente, esta no te deja llamar funciones que no hayan sido declaradas previamente. Es decir que lo siguiente:
alertar();
var alertar = fucntion(){
alert('ups!');
}
nos tira un error. La razón de esto tienes que ver con la declaración de las variables, pero en este post no voy a entrar en detalles con respecto a ese asunto. Así que si esta forma de declarar funciones tiene ese “problema” por que querríamos usarla? bueno, hay momentos en los que esa es la forma en que queremos declarar una función. Por ejemplo, cuando agregamos métodos a un objeto como veremos más adelante, o cuando queremos crear funciones auto ejecutables.
Funciones auto ejecutables
También se pueden crear funciones que se auto ejecutan al momento de ser leídas.
var alertar = function(){
alert('ups!');
}();
Los paréntesis al final de la función le dicen al motor de javascript que la función debe ser ejecutada tan pronto sea leída. Esto probablemente no parezca útil al principio ya que la función deja de existir al momento en que se ejecuta, pero hay ocasiones en las que eso es lo que queremos hacer. Para comprobar esa temporalidad de la función puedes intentar lo siguiente:
var alertar = function(){
alert('ups!');
}();
alertar();
Para poder crear funciones auto ejecutables es necesario usar la sintaxis:
var variable = function(){}
ya que si queremos usar la sintaxis del primer ejemplo (function funcionName(){}) obtenemos un error. Esta es una de las ocasiones en que queremos usar esta sintaxis que parece tener una desventaja al no dejarnos llamar a las funciones antes de que sean declaradas.
Pero ya en serio, por que queríamos hacer una función que se va a perder en el limbo tan pronto sea leída, lo que quiere decir que no la podemos volver a llamar en ningún otro momento? Una de las utilidades que yo le he encontrado es para solucionar problemas con el ámbito de las variables mediante closures, pero ese es otro tema. Lo único que voy a dejar es el siguiente ejemplo:
var alertar = function(){
return function(){
alert('ups!');
}
}();
alertar();
De esta manera la función auto ejecutable puede ser llamada en cualquier momento, aun que al ejecutarse al inicio, cuando es leída, no ejecutará el alert ya que esta en la función que es regresada al ejecutarse la función exterior. Este es otro ejemplo que se ve sin sentido, pero sin embargo, es muy útil en ciertas ocasiones.
Funciones anónimas
También se pueden crear funciones anónimas de la siguiente manera:
(function(){
alert('ups!');
});
Solo que como esta función es anónima no hay forma de llamarla después, por lo que la única forma de poder usarla es haciéndola auto ejecutable:
(function(){
alert('ups!');
})();
Esta sintaxis es especialmente útil cuando queremos crear pseudo namespaces para evitar problemas de compatibilidad cuando usamos diferentes librerías. Aún que no es la única forma de lograr esto, si es una forma elegante y que a más de un novato lo hará verse como un “pro”.
El constructor
Por último veamos la forma menos recomendable, pero probablemente más poderosa, de crear funciones. Esta función es usando el operador new para crear un objeto Function. Esta es una bestia peligrosa y recomiendo que sea evadida, pero de cualquier modo vamos a tocarla por el simple gusto de hablar de ella.
Para declarar una función de esta manera se hace de la siguiente forma:
var alertar = new Function('arg1','arg2','alert("ups1");');
en donde arg1 y arg2 son los argumentos que le queramos pasar a la función. Se pueden pasar tantos como se desee. El motor de Js sabe que el último set de comillas es el que contiene las instrucciones a ejecutar. Esta sintaxis es especialmente útil cuando se quieren crear funciones al vuelo o dar la oportunidad al usuario de crear sus propias funciones. Como dije, esto es una bestia y es mejor alejarse de ella a menos que sepas lo que estas haciendo y no tengas otra opción.
Ys estaré escribiendo un poco más sobre funciones ya que hay un par de cosas que se quedan pegadas al teclado por el momento. Espero sus comentarios.
