Me mudo

Este blog no recibirá ya más actualizaciones. Ve al nuevo blog enricflorit.com o averigua por qué me mudo.

viernes, 26 de octubre de 2012

Mejora tu código adoptando una guía de estilo

La mayoría de veces, un proyecto de código es mantenido por mas de una persona. Aunque sea un equipo pequeño, cada programador tiene una forma de entender, leer y escribir el código, de la misma manera que cada uno tiene una forma de hablar y expresarse.
En estos equipos de mas de una persona mantener código escrito por cualquiera del equipo puede llegar a ser una pesadilla. Y ya no hablemos del código libre/open source, en el cual la mayoría de los programadores están dispersos por el planeta y conectados solo por una lista de correo o un tracker de bugs.
La mejor manera de solucionar estos problemas de comprensión en el código es bastante lógica: establecer unas normas que cada desarrollador deberá seguir, de modo que todo el código presente más o menos consistencia independientemente del programador autor de cada parte del código.
Algunos grupos de programadores incluso han dado un paso mas, publicando el estándar que siguen internamente bajo el nombre de "Guías de estilo”. Estas guías son una serie de normas a seguir para un código legible y unificado, y suelen tratar estos puntos de la sintaxis y el formateo del código:
  • La indentación del código
  • El tamaño máximo de una línea
  • La separación mediante líneas en blanco
  • La codificación de caracteres
  • Uso de sentencias específicas del lenguaje
  • Escritura de comentarios
  • Formato de las estructuras (if, while, for, switch, catch...)
  • Uso de las expresiones lógicas &&, ||, !==/!=
  • Nombres para variables y funciones
Como se puede ver, en estas guías se tratan casi todos los aspectos a tener en cuenta a la hora de programar en un lenguaje específico.
Por si os interesa, os pongo algunas de las guías que se pueden encontrar por la red (si queréis más simplemente id a Google):
Qué método usáis vosotros? Os “auto-definís” unas reglas propias o seguís fielmente una de estas guías de estilo?

lunes, 22 de octubre de 2012

Aplicaciones con AJAX

Hola!

Hace poco me he mudado de blog, ahora mis posts están en enricflorit.com. Para ver este post:

http://www.enricflorit.com/aplicaciones-web-con-ajax/

miércoles, 17 de octubre de 2012

Detección del navegador vs. detección del soporte

Un problema que se han planteando los desarrolladores web desde que la web existe es la compatibilidad con navegadores. Hablo del código para JavaScript, donde en ocasiones podemos llegar a multiplicar el código necesario para cualquier aplicación por dos o tres. Por suerte, la mayoría de problemas más básicos se están solucionando al introducir nuevas versiones en los navegadores. O tal vez no?
Algo de historia
Antaño, los desarrolladores web (en aquellos tiempos, “webmasters”) tenían que preocuparse por dos plataformas: Internet Explorer y Netscape Navigator. Pero era algo casi normal, y tenías tres opciones:
  • Soportar ambos navegadores
  • Soportar uno de los dos. El que te hiciera menos rabia, el que te gustara más o el preferido por tus visitantes.
  • No soportar ninguno de los dos. Las webs no tenían tantas necesidades multimedia como hoy, y la mayoría de efectos JS solían ser puras chorradas.
Pero claro, con el tiempo fueron llegando más necesidades, más soluciones... y los navegadores modernos. Es decir, la popularización de los navegadores modernos. Navegadores que respetaban los estándares (todavía a medias, pero empezaba a existir esa idea). Y algunos de los webmasters empezaron a ver que era mucho mejor adaptar sus aplicaciones para estos navegadores e Internet Explorer.
La gran pérdida de tiempo
Como IE lo hacía todo al revés, era sencillo diferenciar entre el código moderno y el antiguo. Bastaba detectar el navegador, y se popularizaron el uso de scripts cortos como /*@cc_on!@*/false o '\v'=='v', basándose en errores del motor de JavaScript de IE.
Pero poco a poco, sucedió que las versiones nuevas de IE (que no modernas) empezaron lentamente a soportar formas estándar y de acuerdo con los navegadores modernos. Problemas? Sí, muchos. Se fueron cambiando los métodos de trabajo, y era asunto del desarrollador meterse en problemas de cómo se soluciona cada caso en cada navegador.
Una solución parcial: las bibliotecas JavaScript
Con la llegada de bibliotecas como jQuery, Mootools, etc., el problema de la compatibilidad parecía que se arreglaba por completo. Está demostrado que no es así, pero se acortó sustancialmente el tiempo de mejoras de compatibilidad en una web.
Así que, ¿porqué nos seguimos complicando la vida? ¿No tenemos suficientes herramientas con estas bibliotecas, como para que aún queramos más? La respuesta es no, y tiene explicación en algo de lo que se habla mucho en estos tiempos: HTML5.
La llegada de HTML5, un quebradero de cabeza (otro más)
HTML5 mola, ya lo he dicho alguna que otra vez. Pero como todo lo nuevo, tardará un tiempo en ser aceptado por todos los navegadores. Algunos puede que no lo lleguen a soportar nunca, pero qué le haremos. Hay un montón de cosas nuevas: etiquetas semánticas, vídeo y audio nativos, canvas, svg, nuevas API de JavaScript, nuevo código CSS...
Parece ser que vuelven los problemas... Que si este navegador soporta esto, que si no lo soporta... Ha llegado el momento de ser más selectivos, escribir nuestro código en función del soporte de una característica y no del navegador y/o su versión (como hacíamos con Internet Explorer). Pero cómo lo hacemos?
Sencillamente, con bibliotecas de test. Modernizr es una muy famosa y que se ha sabido desenvolver bien, es pequeña y sencilla. Además es modular, así que podemos compilar nuestra propia versión desde la web para que solo haga lo que necesitamos. Os recomiendo que la descarguéis para probarla: http://www.modernizr.com/
Para acabar, parece que tenemos solucionado el tema de la compatibilidad, con algunos baches (de escribir varias versiones del código no nos libramos), pero lo que sí que nos es útil es el uso de bibliotecas.
Aún así, creéis que hay algún asunto pendiente en el tema de la compatibilidad? Cuál?
Un saludo! ;-)

domingo, 14 de octubre de 2012

Reescribir código o reutilizarlo?

"Contemple desecharlo; de todos modos tendrá que hacerlo." (Fred Brooks, The Mythical Man-Month, Capítulo 11)
Esta es una frase que leí referenciada hace algún tiempo en un artículo del hacker Eric S. Raymond, "La Catedral y el Bazar". En ese artículo se habla sobre el éxito de un desarrollo al estilo linux, pero no es el tema que traigo hoy. Hoy quiero hablar de algo distinto: ¿Es necesario desechar totalmente código de un proyecto (o parte de él) en el momento en que nos damos cuenta que hay una solución y/o implementación mucho mejor que la actual?
Difícil decirlo, ¿verdad?. Este es un tema que me suele preocupar bastante en mis desarrollos web. Como es lógico, jamás podrá nadie a estas alturas aprender todo cuanto se ha descubierto, escrito o dicho alguna vez. En cualquier ámbito pasa esto, excepto si nos metemos en un tema muy específico y limitado (y aún tendría serias dudas). Es imposible conocer absolutamente todo lo que está disponible en Internet, por ejemplo. ¿Tiene Google indexadas todas las webs del mundo? No, y cada día se crean aún más.
Pasemos a un ámbito más concreto, dejando de lado reflexiones existencialistas. El desarrollo web. Podríamos decir que esta parte de la informática incluiría, a grandes rasgos y sin contar la especialización, algunos pilares: HTML, CSS, algo de JavaScript, las bases del protocolo HTTP... Cualquiera que sepa esto se puede llamar desarrollador web? Lo dejaremos en que se le podría empezar a llamar así.
Ahora dejemos de lado los conocimientos básicos sobre la web, y diré que siempre existe la especialización. Pongo mi caso personal: estoy especializado en PHP y en su relación con AJAX. Ni de lejos soy el más bueno, ¡Me queda mucho por aprender! Pero cada vez que descubro algo nuevo que realmente me interesa, lo primero que quiero hacer es implementarlo. Probarlo. Experimentar con ese "algo" que me fascina, del cual quiero tener más conocimiento.
Ahí entramos en el problema: qué pasa si descubrimos algo que nos permitiría tener grandes beneficios (a nivel de código) en una parte de nuestra aplicación? Pondré un ejemplo práctico y de relativa actualidad (aunque aún no se ha manifestado demasiado): Backbone.js
Si habéis oído hablar de Backbone.js, sabréis que es un framework destinado a trabajar con proyectos web de gran complejidad del lado del cliente (aunque también se puede usar con node.js). Uno de los modos de uso que se proponen en la web del proyecto es la combinación con jQuery. Ahora supongamos que tienes un proyecto enteramente hecho con jQuery, y es bastante grande. ¡Backbone.js parece ser tu solución! Pero, espera un momento... La solución a qué? No está tu web acabada?
La decisión depende de tu situación
Si tu proyecto no está acabado, plantéate en qué estado de desarrollo está. Si te encuentras en una fase avanzada, no cambiarás, no? Lógico, sería desechar mucho trabajo.
Pero si hablamos de un código pequeño, que de momento es solo el esbozo de una idea, o incluso una parte a medias de una idea, contempla reescribir el código usando la herramienta nueva. Aquí es donde quería llegar con la frase del principio - si ya has resuelto un problema una vez, o ya sabes en qué dirección apuntar, será mucho más fácil resolver el problema con un nivel de complejidad mayor: la nueva herramienta. Es decir, en este caso SÍ reescribiríamos.
Pero, ¿Qué pasa si el proyecto está terminado? Excelente pregunta. Y creo que no debería quedar sin responder. Pero de nuevo daré la respuesta (o mejor, mi opinión) con condicionales. Si es un proyecto no demasiado grande, no tienes ideas para mejorarlo y/o tienes tiempo para reescribirlo... Hazlo, seguramente el cambio será para mejor. Pero si estás en lo contrario de uno de estos tres casos, lo mejor sería desarrollar cualquier parte nueva usando lo último que hayas aprendido, y aceptar que, lentamente, la parte antigua de tu código la irás modificando y modernizando con el tiempo. Dicho de otro modo, REUTILIZA tu código.
Cuál es tu opinión? Qué haces frente a un problema de cambio de código?

jueves, 11 de octubre de 2012

Cómo subir archivos al servidor con AJAX - Parte 1

Me he mudado! Este blog pasa a llamarse enricflorit.com. Puedes encontrar esta entrada aquí:

http://www.enricflorit.com/como-subir-archivos-al-servidor-con-ajax-parte-1/

lunes, 8 de octubre de 2012

Cómo usar correctamente el RewriteEngine (parte 1)

En este primer post sobre configuración de servidores Apache voy a empezar a hablar del RewriteEngine, posiblemente uno de los casos en que más usamos el fantástico archivo .htaccess (otro sería la creación de errores personalizados).
Aviso que en este post no pondré ningún ejemplo, así que habrá que esperar a otro en el que sí pondré ejemplos de cada una de las maneras de usar el mod-rewrite que menciono :).
Saber si lo tienes activado
Lo primero que necesitas saber es si puedes usar RewriteEngine en tu servidor. Si no lo está y no tienes acceso a la configuración de apache, lo siento pero tendrás poco que hacer. Así que para no perder el tiempo con el resto de ejemplos, primero haz lo siguiente:
  1. Crea un archivo llamado .htaccess en la carpeta raíz de los archivos de tu servidor.
  2. En el archivo, introduce estas líneas:
    RewriteEngine On
    RewriteRule prueba\.html http://www.google.es [R]
  3. Guarda, sube el archivo al servidor remoto
  4. Abre la dirección http://tudominio.com/prueba.html
  5. Si se abre la página principal de Google, ¡Enhorabuena! Tienes RewriteEngine disponible. Si no es así... Lo siento, tendrás que usar otra forma de crear URLs amigables (que las hay ;)).
Usos de RewriteEngine
El uso más común que se le da a esta opción de configuración de Apache es para reescribir URLs y hacerlas más amigables, es decir, más sencillas para el usuario y para los motores de búsqueda. Pero también tiene otros usos, menos conocidos, y sobre todo, menos extendidos.
  • Como ya he dicho, la reescritura de URLs. Está claro que es mucho más legible /noticias/23 que ?id=23, y más cuando tenemos más de dos o tres variables que recoger de la URL. Esta aplicación no es, en principio, complicada, siempre que tengamos disponible el mod-rewrite de Apache.
  • Protección contra el robo de ancho de banda: puede que visitando algún foro hayas visto alguna vez una imagen que no aparece. En su lugar, una advertencia y, normalmente, una URL con la página original de la imagen. Esta imagen está protegida con RewriteEngine, y es una buena manera de proteger tu contenido propio de apropiamientos fáciles (al menos, que se tengan que descargar el archivo!).
  • Exclusividad de un enlace a un archivo o página: el caso anterior tiene otra aplicación. Pongamos que tienes un archivo PDF, pero no quieres que otros puedan enlazar directamente al archivo, sino solo a una página de aterrizaje que a su vez incluye un enlace al archivo. Esto es posible gracias también al RewriteEngine...
  • Sentencias para el mod-rewrite Para usar este módulo de apache, solo tenemos que activarlo desde un archivo .htaccess. Este archivo deberá estar dentro de la carpeta a la que queremos aplicar el mod-rewrite y las opciones que escribamos.
    La línea para inicializar el módulo es sencilla:
    RewriteEngine On A partir de aquí, podemos pasar directamente a las espresiones regulares, o bien definir algunos parámetros más:
    RewriteBase [directorio base de las url reescritas]
    RewriteCond [variable] [regexp a comparar con la variable]
    RewriteRule [regexp] [url a reescribir]


    *(regexp = expresión regular)
    Aplicando estos conceptos, y con la ayuda de flags (condiciones adicionales para las RewriteCond y RewriteRule), podremos aplicar RewriteEngine a los casos de más arriba. Nos vemos en la segunda parte del post!
    Saludos ;)

jueves, 4 de octubre de 2012

Webs para móviles: diseño propio desde cero

Este es el primero de una serie de artículos donde voy a comparar las diferentes opciones que se nos presentan a la hora de crear una web adaptada a móviles. Hoy empezamos con los diseños desde cero, partiendo solo de los tags html más básicos y de una hoja de estilos css vinculada. ¿Algo a decir?
Evidentemente, este método es uno de los más costosos a nivel de tiempo. Si lo comparamos con el uso de librerías o frameworks, hay que tener en cuenta que tendremos que crear la web absolutamente sin nada, como mucho, la idea del diseño que vamos a implementar.
También se nos presenta el problema del soporte. Por dos lados: el primero es el soporte de etiquetas HTML5 y estilos CSS3 por parte de los diferentes navegadores móviles. Este problema suele ser aún más grande con las fuentes de letra y su tamaño. Pese a tener disponible la opción @font-face, lo más normal es tener algún tipo de problema relacionado con esto.
Por otro lado estan las interfaces táctiles. Si queremos crear un menú que se deslice o una cabecera fija, la tendencia es a tener grandes problemas. Si en los navegadores de escritorio la compatibilidad ya es una pesadilla, aquí se multiplica por cuatro. Estamos tratando con dispositivos muy distintos entre sí, y el manejo de eventos táctiles es lo que más quebraderos de cabeza suele llevar.
Pero hay que tener en cuenta las ventajas. Ante todo, el diseño que vayamos a crear será, con toda seguridad, muy parecido a la versión de escritorio de nuestra web. Si la tuviéramos que crear con una librería, esto no sería para nada así.
Y como siempre (no me canso de decirlo), la velocidad. Las librerías no siempre son la mejor opción. En un móvil esto cuenta mucho más que en un ordenador. El uso de librerías siempre aumenta el peso de una web, y si la mayor parte de nuestros visitantes van a usar redes 3G para entrar a la web, no les hacemos un gran favor. Una web sencilla será siempre mucho más rápida que una pesada y con archivos grandes, así que es mejor no complicarse la vida en el campo móvil.
En resumen, si queremos una web móvil con la información básica sobre la web en sí, deberíamos optar por un diseño desde cero. Y si lo que queremos es una web con funcionalidades, con el sistema de usuarios activo... Tal vez sea mejor apostar por las demás opciones.
Hasta pronto!

jueves, 6 de septiembre de 2012

Porqué usar características que no son cross-browser

Últimamente hay mucho revuelo en el mundo del desarrollo web. Constantemente aparecen nuevas funciones en los navegadores, algunas quedan obsoletas por las nuevas especificaciones del HTML5, CSS3 y JavaScript. Lo cierto es que a veces puede ser un auténtico lío implementar determinadas cosas en un sitio web.
Pongo un ejemplo: el audio/vídeo nativo en todos los navegadores aún no termina de ser una realidad. Pongo otro: las fuentes CSS que son compatibles en IE no lo son en FF, Chrome y viceversa. Aún hay más: el método matchesSelector de JS requiere un mínimo de 4 prefijos para funcionar correctamente.
Podríamos seguir así indefinidamente... Pero a veces, puede ser bueno usar funciones nuevas que sabemos que no serán soportadas por todos los usuarios. Y sí, tengo razones para afirmar esto:
  • Exclusividad. Convence a tus usuarios de la mejor experiencia que obtendrán actualizando su navegador. Así lo hace gmail, por poner un ejemplo. Y ahora es muy fácil mandarlos a browsehappy para que descarguen un navegador más nuevo.
  • Estética y/o decoración. Border radius es una propiedad CSS soportada por el 79% de los usuarios web. El resto ve unos bonitos bordes de 90º. Pero en la mayoría de los casos, el uso de border-radius (y su uso con prefijos) se limita a razones estéticas. A los usuarios que no lo vean no les pasará nada por no ver del todo bien tu sitio.
  • Funcionalidades no imprescindibles. Sólo Chrome y Safari 6 soportan las notificaciones web. ¿Imprescindibles? No lo creo, son sustituíbles por un <div> que aparezca en una esquina de la página o por la función alert(). Pero evidentemente, queda mucho mejor si se ve de forma nativa en el navegador.
  • Fallbacks. Si pones un input type="search/email/number/date/url/range" (etc), los navegadores que no lo soporten mostrarán una caja de texto normal y corriente. Y como igualmente en el lado del servidor es prácticamente obligatorio comprobar los datos introducidos, no supone un problema.
    Otro ejemplo son los de los degradados en CSS. Definimos un color de fondo por si acaso, y luego creamos el degradado.
  • Alternativas (polyfills). Muchas veces, para hacer funcionar una determinada característica, función o API en nuestra web no tenemos más que ir a google, buscar un poco y descargar un script. Y la mayoría de estas veces, habremos tardado 2 minutos en poder avanzar en nuestra aplicación con garantías.
  • Soporte progresivo. Lo que hoy no está soportado por la mayoría, lo estará mañana. Un buen ejemplo es Internet Explorer 10: hace unos años era impensable que el navegador de Microsoft pudiera llegar a soportar ni la mitad de estándares web (aparte de los que ellos mismos introdujeron, claro).
Riesgos
Está muy bien usar nuevas funciones: aportan un aire de avance tecnológico a la web y una mejor experiencia para el usuario. Pero no todo son ventajas. Por ejemplo, una web con un diseño muy catastrófico en navegadores antiguos hará que los nuevos visitantes huyan más rápido. Un visitante que llega a tu web a través de una búsqueda quiere respuestas. Luego si acaso (y no siempre) ya se interesará por el resto del contenido de tu web.
Así que hay que tener en cuenta una cosa: siempre mostrar la información de manera adecuada, pese a que el diseño y/o los efectos "extra" no estén soportados en todas las plataformas.
Por último, una recomendación: HTML5 Please. Esta web tiene como lema "Utiliza lo nuevo y brillante responsablemente" (Use the new and shiny responsibly). Tiene muy buenos consejos y recomendaciones sobre qué es mejor usar (o no usar) en el campo de las últimísimas nuevas tecnologías web. No dejéis de visitarla: html5please.com.
Un saludo! ;-)

lunes, 3 de septiembre de 2012

Cómo crear paletas de colores en PHP

Hoy me he despertado con una idea en mente: crear un script que imprima marcas de agua (con un copyright, url de una web o similar) en las fotos que se vayan a mostrar en una web. Pero planteando el problema más detenidamente, nos encontramos con que:
  1. La imagen no siempre tendrá los mismos colores, por lo que el color del texto deberá variar,
  2. Puede que el texto tape algún detalle de la foto que no nos interese, así que deberíamos poder cambiar la posición del texto,
  3. Si el texto va a ser semitransparente, tal vez no sea necesario lo anterior.
Fijándome en el primer punto, me he decidido a buscar un poco por internet para encontrar una función que pudiera solucionar el problema del color.
He encontrado más que eso: una función que crea paletas de colores. Devuelve los valores hexadecimales de los colores predominantes por orden de importancia. Una maravilla salida de los foros de StackOverflow. Aquí tenéis el enlace. El código de la función es el siguiente:
function colorPalette($imageFile, $numColors, $granularity = 5) {
    $granularity = max(1, abs((int)$granularity)); 
    $colors = array(); 
    $size = @getimagesize($imageFile); 

    if( $size === false ){ 
        user_error("Unable to get image size data"); 
        return false; 
    }

    $img = @imagecreatefromstring(file_get_contents($imageFile));

    if( !$img ){ 
        user_error("Unable to open image file"); 
        return false; 
    } 

    for($x = 0; $x < $size[0]; $x += $granularity){ 
        for($y = 0; $y < $size[1]; $y += $granularity){ 
            $thisColor = imagecolorat($img, $x, $y); 
            $rgb = imagecolorsforindex($img, $thisColor); 

            $red = round(round(($rgb['red'] / 0x33)) * 0x33); 
            $green = round(round(($rgb['green'] / 0x33)) * 0x33); 
            $blue = round(round(($rgb['blue'] / 0x33)) * 0x33); 
            $thisRGB = sprintf('%02X%02X%02X', $red, $green, $blue); 

            if(array_key_exists($thisRGB, $colors)){ 
                $colors[$thisRGB]++; 
            }else{ 
                $colors[$thisRGB] = 1; 
            } 
        } 
    } 
    arsort($colors); 
    return array_slice(array_keys($colors), 0, $numColors); 
}
A este código se le pueden dar múltiples aplicaciones, a parte de servirme para el script de marcas de agua:
  • Poder crear un mosaico de imagenes (teniendo una buena base de datos).
  • Crear paletas de colores para sitios web.
  • Obtener los colores predominantes de una web, combinándolo con un script de captura de pantalla.
¿Qué otras aplicaciones se os ocurren para este tipo de scripts?

Descarga el ejemplo en Dropbox

viernes, 31 de agosto de 2012

Porqué no usar jQuery?

Sí, es cierto. jQuery mola. Todos los frameworks para JavaScript molan. Permiten interactuar con el DOM. Permiten animaciones. Facilitan el uso de ajax. Algunos frameworks hacen esto y mucho más (véase Backbone y otros) incluyendo patrones MVC y modelos de objetos. Pero no siempre es recomendable usar una librería o framework.


Que conste que me gusta jQuery. En los desarrollos web que hago lo suelo usar, incluso hay momentos en los que por "pereza" lo uso. Pero como el resto de la web lo usa, no me importa (al fin y al cabo, somos libres de hacer lo que queramos.

Pero no siempre se debe usar jQuery. Hay gente que te pondría jQuery hasta en la sopa (a lo mejor se puede usar para hacer una ;)...). Por ejemplo, no usarás jQuery para sumar, a pesar de la imagen que aparece arriba.

Y porqué jQuery no es siempre LA opción? Preguntarán algunos. Pues porque...
  • Ocupa mucho. Si nuestro código es pequeño (no sobrepasa las 100, 150, o incluso 200 líneas sin comprimir), no vale la pena usar ayuda. Piensa que jQuery tiene unas 9.000 líneas de código. El usuario pasará más tiempo descargando la librería que nuestro código.
  • Animaciones con CSS. Aún no están extendidas, algunos navegadores no las soportan... pero si la animación es puramente estética, vale la pena limitarse al css y pasar de JavaScript.
  • Interacción con el DOM. Aunque tu script sea largo, considera lo siguiente. Muchos navegadores ya soportan los selectores CSS de forma nativa en JS. Usando document.querySelectorAll harás lo mismo que con jQuery en IE8+, FF3.5+, Chrome, Safari, Opera10+, Android, incluso en BlackBerry7+. Esto representa el 93% de los navegadores...
  • Validación de formularios: con HTML5, le pones un atributo required a un input y él solito se valida.
  • Añadir clases, quitar clases. Hay un script de unas 15 líneas que permite cambiar clases fácilmente:
 function hasClass(obj,cls){
   return obj.className.match(new RegExp('(\\s|^)'+cls+'(\\s|$)'));
 }

 function addClass(obj,cls){
   if(!hasClase(obj,cls)) {
     obj.className+=" "+cls;
   }
 }

 function removeClass(obj,cls){
   if(hasClass(obj,cls)) {
     var exp =new RegExp('(\\s|^)'+cls+'(\\s|$)');
     obj.className=obj.className.replace(exp,"");
   }
 }

Estas son algunas de las razones por las que no usar jQuery. Y es que muchas veces es mejor usar JavaScript nativo, aunque no se vea tan "limpio" para algunos. Como se comenta en este tema: Javascript !== jQuery.

Hasta aquí mis argumentos... Para qué diríais que hay que usar/no usar librerías y/o frameworks como jQuery?

Captura de pantalla (parece ser que no existe el mensaje en StackOverflow).

También hay un lado bueno... Haz click para ver los pros de jQuery

miércoles, 29 de agosto de 2012

Las innovaciones de Internet Explorer

Cualquiera que haya hecho un diseño para una web se habrá encontrado con un enorme quebradero de cabeza: Internet Explorer. Casi parece increíble que un navegador pueda funcionar tan mal, hablando claro. Pero soportarlo, hasta hace poco, era imprescindible, porque todos los equipos con Windows lo tenían de serie. Ahora esto está cambiando con la fuerte campaña de Google Chrome, la popularización de Firefox y el avance en el mercado de OSX.
Pero lo más sorprendente son las funcionalidades que, a modo de experimento, Internet Explorer ha ido introduciendo en versiones anteriores. Estos cambios se están convirtiendo en estándares adoptados por HTML5 y las nuevas API de javascript:
  1. AJAX. En 1999 se introdució el objeto XMLHttp en IE5. Fue desarrollado por Alex Hopmann para el cliente web de Exchange 2000. En 2006 se creó un borrador para estandarizarlo.
  2. Drag and Drop. Fue añadido en IE5. Con la llegada de HTML5 se revisó y se le añadieron cambios importantes.
  3. innerHTML. La propiedad usada al manejar objetos DOM vino al mundo con Internet Explorer 4.
  4. Eventos. IE5-6 introducieron 7 eventos que hoy en día ya son estándares de la especificación DOM: contextmenu, beforeunload, mousewheel, mouseenter, mouseleave, focusin, focusout.
  5. Acceso al Portapapeles. Apareció en IE6, luego Safari lo implementó con algunos cambios, y finalmente ha sido adoptado por los grandes navegadores, excepto Opera.

  6. ContentEditable. Introducida con IE5.5 en Julio del 2000. Cinco años más tarde se empezó a introducir en la especificación de HTML5.
  7. Atributo defer para scripts. Esta característica es poco conocida, y no deberías usarla (aún). Se trata de un atributo que se escribe en las etiquetas <script>. Hace que el script no corra hasta que la página no esté cargada. Se introdució en IE4.
  8. iframe. Esta etiqueta se creó en IE3 para competir con el frameset de Netscape, y fue adoptada en la especificación de HTML4. Vale, puede que nadie la use ya... Pero qué hay de los vídeos de YouTube?

  9. Propiedades css. La mayoría están aún poco usadas, pero están soportadas por los navegadores más modernos. Son: text-overflow, overflow-x y overflow-y, word-break, word-wrap y overflow-wrap
Lo más sorprendente de todo es que casi todas estas innovaciones son parte de HTML5 y CSS3...
¿Conclusiones para este post? No es que debamos adorar a IE (hay bastantes motivos para despreciar a sus versiones antiguas), pero sí es importante tener presente que en un futuro no demasiado lejano (versiones 10, 10.x y/o 11), Internet Explorer estará a la altura de los navegadores modernos. Incluso Mozilla lo ha dicho...
Hasta pronto! ;-)

Fuentes

lunes, 27 de agosto de 2012

XMLHttpRequest2, el futuro de AJAX

AJAX funciona gracias al objeto XMLHTTP. Curiosamente, fue creado por el ingeniero de Microsoft Alex Hopmann para Internet Explorer 5. Desde entonces, miles de aplicaciones web y páginas dinámicas han sido creadas. Ejemplos de ello son Gmail, Google Maps, Facebook, Twitter podrían ser los más conocidos. Se han creado cientos de frameworks y librerías de JavaScript que lo implementan, hacen más fácil y rápido su uso. Parece que cada vez es más imprescindible conocer el uso de esta tecnología.
En Abril del 2006, el W3C empezó el primer borrador para un estándar del objeto XMLHTTP. Éste ha ido evolucionando, se han creado múltiples versiones de este borrador. En Febrero de 2008, se empezó a escribir un nuevo borrador. Estaba dedicado a la evolución de XMLHTTP, el objeto XMLHttpRequest 2.
Esta nueva especificación (todavía se está trabajando en el borrador) incluye nuevos eventos, añade la posibilidad de establecer límites de tiempo a la conexión y da información adicional sobre el progreso de la transferencia HTTP. También aporta una mejora muy interesante, la posibilidad de subir archivos al servidor. Y como estamos hablando de AJAX, lógicamente sin recargar la página.
Nuevos eventos
Parece ser que desde ahora ya no usaremos el evento onreadystatechange. Eso sí, se mantendrá por razones históricas, nada más.
  • loadstart. Producido al empezar la carga.
  • progress. Se produce después del loadstart. La función usada al producirse puede recibir un objeto con las propiedades lengthComputable, loaded y total.
  • abort. Salta al interrumpirse manualmente la conexión.
  • error. Si se produce un error.
  • timeout. Si se ha definido un tiempo límite, este evento saltará cuando se supere.
  • load. Cuando se complete el progreso.
  • loadend. Se lanza una vez parado el progreso (después de load, error, abort o timeout).
Nuevos atributos
Para poder usar la carga de archivos y facilitarla, se han añadido los siguientes atributos:
  • upload. Permite manejar los eventos de progreso y carga.
  • timeout. Tiempo límite en milisegundos para la conexión.
Objeto FormData
Para poder manejar formularios fácilmente, se ha añadido el objeto FormData. También se puede usar para enviar datos fácilmente. Con el siguiente código:
var data = new FormData();
data.append('id','4');
data.append('nombre','Mi Nombre');
De esta manera, nos evitamos tener que codificar cadenas de petición de la forma id=4&nombre=Mi%20Nombre, etc.
Y aunque no todos los navegadores lo soporten, tenemos una solución cross browser...
En definitiva, que es cuestión de tiempo que se empiezen a generar códigos en la comunidad aprovechando estas nuevas características para el desarrollo de aplicaciones web, que seguro que serán el futuro de la web.
Hasta pronto! ;-)

domingo, 26 de agosto de 2012

Cómo subir archivos al servidor con PHP

Me he mudado! Este blog pasará a llamarse enricflorit.com. Puedes leer esta entrada aquí:

http://www.enricflorit.com/como-subir-archivos-al-servidor-con-php/

sábado, 25 de agosto de 2012

Primeros pasos con jQuery mobile: páginas básicas

Desde que salió la primera versión oficial de jQuery Mobile habrán pasado ya unos seis meses, y la verdad es que ha mejorado mucho: me acabo de pasar por las demos oficiales y he visto que han incluido muchas mejoras, y evidentemente, ahora debería ser más estable.

Creo que para poder apreciar las posibilidades de un framework o una librería lo mejor es verlo en acción, así que pasaos por aquí para ver los muchos usos que se le han dado a jQm - incluso grandes empresas como Disney, Verizon, Jeep... lo usan!

Así que si quieres meterte de lleno en esta librería, vamos a empezar creando algunas páginas básicas.


La plantilla base
Lo bueno que tiene jQuery es que tiene una gran comunidad detrás, así que la documentación es muy buena - lo mismo sucede con jQuery mobile. Para empezar a crear "algo", es tan sencillo como copiar este código:


<!DOCTYPE html> 
<html> 
<head> 
<title>My Page</title> 
<meta name="viewport" content="width=device-width, initial-scale=1"> 
<link rel="stylesheet" href="http://code.jquery.com/mobile/1.1.1/jquery.mobile-1.1.1.min.css" />
<script src="http://code.jquery.com/jquery-1.7.1.min.js"></script>
<script src="http://code.jquery.com/mobile/1.1.1/jquery.mobile-1.1.1.min.js"></script>
</head> 
<body> 

<div data-role="page">

<div data-role="header">
<h1>My Title</h1>
</div><!-- /header -->

<div data-role="content">
<p>Hello world</p>
</div><!-- /content -->

</div><!-- /page -->

</body>
</html>

Con esto tendremos una página con una barra superior (toolbar) con un título de prueba. Y lo bueno es que la librería viene con 5 temas de prueba, de la a a la e. Para cambiar el tema de cualquier elemento, solo hay que añadirle:

data-theme="a"

(O cualquier otra letra), y ya está. Pero lo bueno es que esto casi no tiene límites. Por ejemplo, para cambiar el tema de la página:

<div data-role="page" data-theme="b">

El tema predeterminado para todos los elementos es el "c". Para entendernos mejor, el tema "a" es el más oscuro de todos, y el tema "e" es el más claro (con tonos amarillos).


Creando múltiples páginas
Evidentemente, con jQm podemos crear páginas como siempre, una página un archivo. Pero para hacer más rápida una página, se nos ofrece la opción de tener varias vistas en el mismo archivo. Así que dentro del <body> podríamos tener:


<!-- Inicio de la primera página -->
<div data-role="page" id="foo">

<div data-role="header">
<h1>Título de la primera página</h1>
</div><!-- /header -->

<div data-role="content">
<p>Primer párrafo. Como esta página está primero, es la que se verá por defecto, y no la #bar.</p>
<p>Ver la página interna <a href="#bar">bar</a></p>
</div><!-- /content -->

<div data-role="footer">
<h4>Pie de página</h4>
</div><!-- /footer -->
</div><!-- /page -->


<!-- Start of second page -->
<div data-role="page" id="bar">

<div data-role="header">
<h1>Título de la segunda página</h1>
</div><!-- /header -->

<div data-role="content">
<p>Esta página está segunda, así que no se verá a menos que se haga click en el link de la primera</p>
<p><a href="#foo">Volver a foo</a></p>
</div><!-- /content -->

<div data-role="footer">
<h4>Pie de página</h4>
</div><!-- /footer -->
</div><!-- /page -->


Evidentemente, esto es el ejemplo más básico, se podría poner mucho más: más páginas, contenido...

En la siguiente entrada de "Primeros pasos con jQm" explicaré las toolbars (barras de título y pie de página) a fondo. No dejéis de visitar el blog!

Un saludo ;-)

viernes, 24 de agosto de 2012

10 plugins útiles de jQuery

jQuery está de moda, y quien lo niegue miente. Lo cierto es que cada vez más programadores de js deciden empezar a usar una librería que les solucione las funciones de selección de elementos en el DOM, pues está más que demostado que los selectores CSS3 son el futuro de la web.
Lo bueno de casi todas las librerías de js que existen son de código libre, y muchas permiten escribir plugins para facilitarnos la vida. Así que hoy os traigo una selección de plugins muy buenos desarrollados por la comunidad que seguro que os servirán ;). Ademas, todos son gratis, así que podréis probarlos fácilmente.
  • Color animation. Este curioso y pequeño script (comprimido ocupa solo 1.9Kb) hará que podamos cambiar los colores de cualquier elemento del DOM usando la función .animate() de jQuery.
  • Elastic. Este plugin hará que un textarea se haga más grande a medida que escribas en él, en lugar de crear una barra de scroll.
  • jPlayer. Un reproductor de audio y vídeo, compatible con HTML5. Ideal si no queremos complicarnos la vida con los tags
  • Nivo Slider. Un bonito formato de presentación de imágenes, ideal para la portada de nuestra web. Es de pago en su versión para WordPress, pero por suerte el plugin de jQuery es gratis.
  • jQuery Star Rating. Quería poner solo un valorador por estrellas, pero como los dos que encontré son muy buenos, os pongo los dos. Sencillamente geniales.
  • jRating. El segundo valorador por estrellas que he encontrado. Dos pequeñas joyas con un modo de trabajar distinto: lo difícil va a ser decidirse por cuál usar...
  • ScrollTo. Haz scroll de la ventana, de una capa, un iframe o lo que quieras.
  • IE6 Reject. Cuando un usuario de Internet Explorer 6 te visite, le saltará una advertencia diciéndole que su navegador no está soportado y que descargue uno nuevo.
  • Simple Email Validate. Valida los emails introducidos en inputs con solo $('input[type="email"].email_validate() .
  • Booklet. Añade un efecto de pasar página. Es ideal para simular una revista o un periódico.
Espero que hos hayan gustado estos plugins de jQuery. Recordad, hay muchos más, y también podéis desarrollar los vuestros... Un saludo!
¿Qué plugins usais vosotros en vuestras webs?

jueves, 23 de agosto de 2012

Intercambio de información entre servidor y cliente: JSON

Hace poco que empezó en la sección de Javascript de Foros del Web una discusión interesante: qué era mejor a nivel de rendimiento en AJAX al enviar datos del servidor al cliente: en JSON, XML o HTML. En realidad, todo el mundo tiene su método (el que le resulta más cómodo), así que en este post y alguno más intentaré explicar (con ejemplos) el uso de cada uno.

Hoy le toca al JSON. Son las siglas de JavaScript Object Notation, es decir, Notación de Objetos en JavaScript. Se está convirtiendo en un modo de transmitir información muy interesante por su fácil escritura y legibilidad. Y no solo en el ámbito web (ver sección de lenguajes).

Para empezar, crearemos un objeto xmlhttp:
if( window.XMLHttpRequest ){
  var xmlhttp = new XMLHttpRequest();
}else if(window.ActiveXObject) {
  var xmlhttp = new ActiveXObject("Microsoft.XMLHTTP");
}
Abrimos la conexión con un archivo PHP que nos devolverá el JSON:
xmlhttp.open('GET', 'json.php', true);

Ahora pasamos al código PHP. Por suerte, este lenguaje incluye una librería básica de JSON a partir de su versión 5.2.0, así que en la mayoría de casos no tendremos problemas para implementar lo siguiente. Se trata de hacer un array que luego convertiremos a json usando json_encode.
<?php 
$array = array(
  'Hola mundo!',
  'Esta es una aplicación ajax',
  'Estoy usando json ;)'
);

echo json_encode( $array ); 
Sencillo, no? A partir de estos datos, vamos a crear una lista en el lado del cliente, usando js. Haremos uso del evento onreadystatechange:
xmlhttp.onreadystatechange = function(){
  if( xmlhttp.readyState == 4 && xmlhttp.status == 200 ){
    var r = xmlhttp.responseText,
    //Convertimos la cadena a JSON
    json = eval('(' + r + ')'),
    ul = document.createElement( 'ul' );

    if( json.length ){
      for( var i in json ){
        var li = document.createElement('li');
        li.innerHTML = json[i];
        ul.appendChild(li);
      }
      document.getElementById('response').appendChild(ul);
    }
  }
}
Finalmente, no queda más que enviar la petición al servidor:
xmlhttp.send( null );


Montando todo el código

Aquí os pongo cómo ha quedado nuestro script al final, incluyendo un enlace para llamar a la función ajax y una capa que hará de receptora.
<!doctype html>
<html>
<head>
  <title>AJAX</title>
<script>
function cargarLista(){
  var xmlhttp;
  if( window.XMLHttpRequest ){
    xmlhttp = new XMLHttpRequest();
  }else if(window.ActiveXObject) {
    xmlhttp = new ActiveXObject("Microsoft.XMLHTTP");
  }else{
    return false;
  }

  xmlhttp.open('GET', 'http://localhost/dev/json.php');

  xmlhttp.onreadystatechange = function(){
    if( xmlhttp.readyState == 4 && xmlhttp.status == 200 ){
      var r = xmlhttp.responseText,
      //Convertimos la cadena a JSON
      json = eval('(' + r + ')'),
      ul = document.createElement( 'ul' );

      if( json.length ){
        for( var i in json ){
          var li = document.createElement('li');
          li.innerHTML = json[i];
          ul.appendChild(li);
        }
        document.getElementById('response').appendChild(ul);
      }
    }
  }

  xmlhttp.send( null );
}
</script>
</head>
<body>
<a href="javascript:;" onclick="cargarLista()">Cargar lista</a><br />

<div id="response">
</div>
</body>
</html>

El código PHP queda como lo habíamos puesto arriba.

A partir de aquí, se podría desarrollar mucho más, comprobar si ya se había cargado la lista, modificar el script PHP para que se muestren los datos guardados en una base de datos... Pero la esencia es esto.

En una entrada de la semana que viene escribiré sobre pasar información del servidor al cliente usando XML. Hasta otra!

Un saludo a todos ;-)

miércoles, 22 de agosto de 2012

Cómo empezar a colaborar con un proyecto de software libre

Hoy os presento algunos consejos que podéis poner en práctica si queréis colaborar en un proyecto de software libre y no sabéis por donde empezar:


  • Elige un proyecto que conozcas. Es más, elige uno que uses, pues ya estarás familiarizado con él. Si usas Linux, freeBSD o cualquier otro Unix libre, el 98% de las aplicaciones serán open source, por lo que no tendrás problemas. Si usas Windows o OSX, también tienes opciones: piensa que no todos los proyectos open source son programas de escritorio; y si no se te da bien la programacion web, también existen programas libres para estos sistemas operativos.
  • Localiza el grupo de correo del proyecto y suscríbete. Así te mantendrás informado de las últimas novedades en el desarrollo, y podrás enviar mensajes al grupo. Eso sí, piensa que en la mayoría de casos el idioma de trabajo será el inglés.
  • Envía tus comentarios, sugerencias... Si usas frecuentemente el programa, seguro que tienes algo que decir. No tengas demasiado miedo y envía tus sugerencias al grupo de desarrollo: serán bien recibidas.
  • Reporta bugs. Para reportar errores, primero hay que encontrarlos, así que si no te atreves con el código, haz lo siguiente: usa el programa de diferentes formas, probando todas las opciones y comprobando los resultados... seguro que consigues algo!
  • Intenta leer y comprender partes del código. Esto suele ser costoso, pero si comprendes el lenguaje en el que está escrito el proyecto, tarde o temprano lo conseguirás. A partir de aquí, puede que incluso tú mismo puedas aportar código al proyecto... ;-)
Así que, lo dicho: suerte en vuestros proyectos open-source!

Saludos ;-)

martes, 21 de agosto de 2012

Consejos para usar HTML5 y que todos vean bien tu pagina

Últimamente se esta hablando bastante del HTML5, CSS3 y las nuevas funciones de javascript. Pero lo cierto es que sigue habiendo algo de miedo para dar el salto. El desconocimiento y pensar que los usuarios de Internet Explorer no veran bien tu sitio pueden ser razones para no querer empezar. Si sigues estos consejos, no te sera dificil iniciarte en la nueva generacion de paginas web:


  • No empieces tus proyectos desde cero. Tienes herramientas muy buenas como html5boilerplate, que ya estan listas para ser usadas con facilidad. Y además la web está en español.
  • Ten a mano una chuleta. Nunca se sabe cuando te olvidaras de alguna etiqueta nueva, que hay muchas.
  • Dales la propiedad display="block" a las nuevas etiquetas semánticas. Eso si no usas html5bp, claro. La plantilla lo incluye por defecto.
  • Comprueba la compatibilidad. Si vas a usar caracteristicas poco frecuentes, mira antes en caniuse para ver que opciones tienes. Recuerda también que visitar html5please puede ser una buena idea ;).
  • Exprime al maximo las soluciones de compatibilidad creadas por otros. Html5shiv, Modernizr, Selectivizr y curvy corners son solo algunos ejemplos de la gran comunidad de gente que dona su codigo para el bien de todos. 
  • Crea un enlace hacia browsehappy. Si aún no estás convencido de que todos los usuarios van a ver bien tu web, puedes crear un enlace a la web Browse Happy para que tus visitantes puedan actualizar su navegador web. Seguro que funciona.
  • Hazte con un conversor de vídeo y audio. Si quieres incluir elementos multimedia en tu web, necesitarás varios formatos para que todos los navegadores los puedan reproducir. Para audio los formatos son MP3 y Ogg Theora. Para vídeo son MP4 y WebM.
Espero que estos consejos os ayuden a comenzar con HTML5.

Y vosotros, qué consejos daríais a alguien que todavía no ha empezado? Hasta pronto!

lunes, 20 de agosto de 2012

5 características de CSS3 que ya deberías estar usando


Si tienes una web o quieres diseñar una, lo que ahora está de moda es HTML5. Porque ofrece muchas nuevas opciones, un diseño "fácil", todo el potencial de CSS3... Así que manos al código, y empieza ya a escribir webs con estos consejos:


  • Border-radius. Excepto IE 8 e inferior, todos tus visitantes veran unos bonitos bordes redondeados. No olvides usar los prefijos -moz- y -wekit-. Y además, tienes esto y esto que hará que los usuarios de Internet Explorer vean estos bordes.
  • Gradients. Los degradados son muy versátiles: botones, fondos... (en un futuro también bordes y texto). Pero no te compliques, existen herramientas muy buenas como colorzilla que te harán la vida muy fácil.
  • Box shadow. Añadir algo de sombreado a cualquier capa la hace más atractiva visualmente, tus diseños se verán más profesionales. Es tan simple como esto:
#div-id {
  background: #FFF;
  border: 1px black solid;
  -moz-box-shadow: 5px 5px 5px #888;
  -webkit-box-shadow: 5px 5px 5px #888;
}

Y también existe una solución (aunque algo compleja) para mostrar sombras en Internet Explorer: http://dev.opera.com/articles/view/cross-browser-box-shadows/


  • Fuentes (@font-face). Es muy curioso que esto esté soportado por el 92% de los usuarios, es decir, casi todos lo verán bien. Se trata de usar cualquier fuente de letra en tu página web. Aquí tienes un repositorio bastante grande de fuentes libres donde, además, te explican cómo usarlas.
  • Opacidad. La propiedad css opacity hará que cualquier elemento sea un tanto por ciento transparente, el que tu le indiques. Y además tienes soporte para IE! Aquí tienes el código:

.mi-estilo {
  filter: alpha(opacity=60);/* IE */
  -khtml-opacity: 0.6;/* KHTML, Safari antiguo */
  -moz-opacity: 0.6;/* Firefox antiguos */
  opacity: 0.6;/* Navegadores modernos */
}

Espero que podáis aprovechar al máximo estas nuevas funciones de css3 ;-).

Saludos!

sábado, 18 de agosto de 2012

Enviar formularios con AJAX y FormData

Me he mudado! Para leer este post haz click en el siguiente enlace:

http://www.enricflorit.com/como-enviar-formularios-con-ajax-y-formdata/

sábado, 26 de mayo de 2012

#weareatwar: La guerra no se hará sola


He estado leyendo estos días en el blog bonillaware sobre la nueva iniciativa que, supuestamente, tiene que revolucionar el mundo de la informática en España: #weareatwar.

Tengo que decir, antes de empezar a hacer autocrítica, que estoy completamente de acuerdo con esta iniciativa, y que pienso dedicarme a ella todo lo que pueda (teniendo en cuenta que soy estudiante de ESO).

Para ser claros: esto no debe quedar en comentar en twitter con el hashtag #weareatwar, ni poniéndose un logo en el blog... Aquí habrá que trabajar de verdad, iniciar algún proyecto, quien no lo tenga; seguir mejorándolo y promocionándolo, el que ya lo haga. Pero esto no puede convertirse en una simple tendencia y/o moda de ponerse un logo molón en el avatar de twitter.

Así que manos a la obra... Yo por mi parte pienso aumentar el ritmo de posts en este blog, con scripts, comentarios y ayudas sobre mis bibliotecas, seguiré creando nuevos programas y scripts... Es decir, quiero luchar, y lo haré. Suerte a todos!



El post original | http://www.bonillaware.com/weareatwar

viernes, 25 de mayo de 2012

jUri - Qué es, y cómo se usa

Hace relativamente poco empecé un proyecto que necesitaba para poder desarrollar el tipo de webs en las que estoy metido normalmente (con AJAX, por ejemplo). Estuve unas dos semanas añadiendo funciones cada día según mis necesidades, y el resultado fue el siguiente: una biblioteca de funciones en JavaScript para manejar cómodamente la URL del navegador (entre otras cosas).



A partir de aquí, la he ido actualizando en GitHub y creo que ya va siendo hora de que lo explique un poco a la comunidad.

Básicamente, quise crear este script porque no había (o no encontré) una biblioteca que hiciera exactamente lo que yo quería, así que me puse a investigar el objeto window.location de JS, para empezar a escribir funciones a partir de los datos que nos proporciona. A continuación os explico las cosas para las que se puede usar el script...


Parseo de URL

La biblioteca tiene como único objeto jUri, que tiene diferentes métodos y propiedades para intentar cubrir las necesidades que suelen ser básicas referentes a la uri/url. El objeto jUri es parecido a window.location, pero está extendido. Estas propiedas son exactamente las mismas que el window.location:
  • jUri.host
  • jUri.hostname
  • jUri.href
  • jUri.pathname
  • jUri.port
  • jUri.protocol
Además, para facilitar el acceso a las variables GET, existe la función jUri.get(), que devuelve un objeto con todas las variables.


Manejo de #hash

La función más importante es jUri.hash(), ya que tiene varios usos:
  • Si no le pasamos argumentos, nos devuelve el hash actual
  • Si le pasamos un argumento como expresión regular, lo compara con el hash actual y nos devuelve true/false. También le podemos pasar un callback como segundo argumento, que será ejecutado si coincide la RegExp.
  • Si le pasamos una cadena (string) como argumento, definirá la cadena como #hash
También existe soporte para el evento hashchange (soportado nativamente en algunos navegadores).  Su uso es jUri.hashchange(function(){});.


Anclas <a> animadas

Una de las características más útiles y que requieren menos programación (una sola línea de código) es la de animar los enlaces que llevan a una ancla <a name=""/> de la página. Con animado quiero decir el desplazamiento suave, al contrario de lo que  sucede cuando hacemos click en un enlace de este tipo.

La función para generar este efecto es jUri.animateAnchorLinks();. Le podemos pasar, eso sí, un string con los nombres de las anclas que queramos animar (individualmente), separadas por comas.


Generador de anclas

Esto es automático solo con incluir el script de jUri: se genera una ancla automáticamente justo antes de cualquier elemento con el atributo data-name="". Esto es útil si queremos incluir una ancla rápidamente en nuestro código html ;).


Enlaces retardados

También podemos usar el atributo data-after en los enlaces, para poder definir el retardo en milisegundos antes de ir a la dirección del enlace.


De momento, ya he explicado bastantes de las características de esta biblioteca, jUri. Por supuesto, iré publicando más entradas sobre el proyecto conforme vaya añadiendo cosas nuevas ;).

Un saludo!



Este proyecto en GitHub | https://github.com/3nr1c/jUri.js
Si quieres contribuir al proyecto | efz1005[at]gmail[dot]com

miércoles, 9 de mayo de 2012

Reemplazando a Flash – curso de animación con jQuery


Hoy voy a empezar con algo de lo que últimamente se está hablando bastante en la red, pero que aún no se está llevando demasiado a la práctica: las alternativas a Flash usando Javascript. Supongo que, si todavía no se ha extendido demasiado el uso de JS, es por la “mala fama” que se ha ido generando: al haber una gran multitud de plataformas que lo soportan, pero todas en distinto grado de soporte, da algo de miedo tener que adaptar las aplicaciones a cada navegador.

Pero, por suerte, hay herramientas que nos ahorran este tedioso trabajo de adaptación y comprobación, reduciendo las aburridas tareas antiguas a un simple vistazo para ver que todo funciona a la perfección.

Y por esto he decidido empezar este curso, para demostrar que jQuery y Javascript pueden ser muy buenas alternativas al uso de Flash.

Empezamos...

Como primera práctica del curso, empezaremos con algo relativamente sencillo, un banner animado. De tamaño estándar (o, al menos, el que con el uso de Flash se ha ido estandarizando), es decir, 468x60.

Para realizarlo, solo un par de cosas. Necesitaremos tres fotos, del tamaño que queráis, pero si son más anchas que el banner, tardarán en cargar. Lógicamente, también usaremos nuestro programa de edición de código habitual (en mi caso Sublime Text 2) para generar los tres archivos (uno HTML, uno CSS y uno JS) y el código fuente de jQuery.

En primer lugar, crearemos esta estructura de archivos en nuestra carpeta de proyectos:

  • jquery_banner (carpeta)
    • index.html
    • assets (carpeta)
      • banner.css
      • banner.js
    • img (carpeta)

Dentro de la carpeta img guardaremos nuestras tres imágenes, a ser posible, con formato *.jpg y numeradas del 1 al 3 por nombre de archivo.

Abrimos el archivo index.html y escribimos el siguiente código:

<!doctype html>
<html>

<head>

<title>Banner con jQuery - reemplazando a Flash</title>

<link rel="stylesheet" href="assets/banner.css" media="all"/>

<script src="assets/jquery-1.7.2.min.js"></script>
<script src="assets/banner.js"></script>

</head>

<body>

<div class="banner" id="my_banner">

<img src="img/1.jpg"/>
<img src="img/2.jpg"/>
<img src="img/3.jpg"/>

</div>

</body>

</html>

Como veis, nos hemos descargado la versión comprimida de jQuery en la carpeta assets y hemos incluido ya nuestros archivos. Ahora pasamos a ver los estilos css:

.banner {
height:60px;
width:468px;
overflow:hidden;
}

.banner>img {
position:relative;
top:0px;
width:100%;
display:none;
}

.banner>img:first-child{
display:inline;
}

/*

OPCIONAL: un borde redondeado para nuestro banner

.banner, .banner>img {
border-radius:7px;
-moz-border-radius:7px;
-webkit-border-radius:7px;
}*/

En el archivo css hemos definido el tamaño de nuestro banner, así como los diferentes estilos para que se vean bien las imágenes. Como veis, también hemos añadido (como comentario, es decir, no hará efecto) un borde redondeado, para que combine bien con el estilo de la web, si conviene.

Finalmente, aquí tenemos el código Javascript. Se podría mejorar bastante, pues se usan demasiadas funciones, pero creo que así se verá mejor el mecanismo de repetición.

$(document).ready(function(){

var frame = $('.banner'),
images = frame.children(),
p1 = $(images[0]),
p2 = $(images[1]),
p3 = $(images[2]),

animate1 = function(){
p3.css({top:'0px'});
p1.fadeIn(2000);

p1.animate({
/*introducir aqui los píxeles de alto de la imagen*/
top:(-351
+60)+'px'
},10000,function(){
p1.fadeToggle(1000,animate2);
});
},

animate2 = function(){
p1.css({top:'0px'});
p2.fadeToggle(2000);

p2.animate({
/*introducir aqui los píxeles de alto de la imagen*/
top:(-351
+60)+'px'
},10000,function(){
p2.fadeToggle(1000,animate3);
});
},

animate3 = function(){
p2.css({top:'0px'});
p3.fadeToggle(2000);

p3.animate({
/*introducir aqui los píxeles de alto de la imagen*/
top:(-351
+60)+'px'
},10000,function(){
p3.fadeToggle(1000,animate1);
});
};

animate1();

});

Eso es todo, espero que os sea útil. Próximamente trabajaremos efectos más avanzados (también con jQuery), y pasaros dentro de poco para ver el nuevo script de buscador instantáneo (también en Javascript) que estoy preparando.

Un saludo!






© 2012 Enric Florit (3nr1c)
Related Posts Plugin for WordPress, Blogger...