Validación nativa de formularios en HTML5

Seguimos con las virtudes de HTML5, y el como en principio este nuevo standar nos facilitará la vida a los programadores web. Porque una de las evoluciones más potentes que incorpora es la validación de formularios de forma nativa, sin necesidad de Javascript (da la impresión de que a largo plazo la idea es cargarse este lenguaje cliente).

Como ya sabéis, tenéis varios tipos de input, que paso a listar debajo:

  • search: Para cajas de búsqueda
  • number: Para añadir o restar números mediante botones.
  • range: Para seleccionar valores dentor de un rango.
  • color: Para seleccionar un color.
  • tel: Para números de teléfono.
  • url: Para direcciones web.
  • email: Para direcciones de correo electrónico.
  • month: Para meses.
  • date: Para fechas.
  • week: Para semanas.
  • time: Para horas.
  • datetime: Para una fecha exacta, absoluta y con hora
  • datetime-local: Para fechas locales y frecuencia

Al definir el tipo de campo la validación de formato ya se realiza de forma nativa sin necesidad de tener que recurrir a una expresión regular. Pero si queréis una validación más compleja (por ejemplo, que el teléfono sólo pueda empezar por 6, 9 u 8, que son las tres posibilidades en España) podéis recurrir al atributo pattern, que nos permite insertar un patrón, con el estilo de una expresión regular, para validar el contenido. Y eso no es todo, si queréis que el campo sea obligatorio basta con añadir el atributo required, y ya de forma nativa se comprueba que haya datos. Con el atributo title podéis introducir el texto que queréis que se muestre en el tool tip que saldrá para informaros del error. Podéis ver varios ejemplos:

<input type="email" title="Use el siguiente formato: direccion@mail.com" required/><!--Esto validaría un correo electrónico de forma nativa-->
<input class="hiddenSpellError" type="text" />type="text" pattern="^[a-zA-Z0-9.!#$%&'*+/=?^_`{|}~-]+@[a-zA-Z0-9-]+(?:\.[a-zA-Z0-9-]+)*$" name="email" required/> <!-- Esto validaría un correo electrónico con una expresión regular -->
<input class="hiddenSpellError" type="text" />type="date" /> <!--Esto nos sacaría un "datepicker" para seleccionar una fecha (varía según navegador)-->

Ya lo veis, la validación es fácil. Pero además, resaltar los campos erróneos se facilita también con CSS3, ya que aparece una nueva pseudo-clase: invalid. Esto nos ahorra tener que andar jugando con javascript para marcarlos. Con la pseudoclase, basta con una sencilla regla CSS para conseguirlo, sin tener que capturar ningún evento:

input:invalid{
  border: 1px solid red;
  color: red;
}

Sólo con ese código los campos inválidos ya se pondrán automáticamente en rojo, quedando resaltados.

De momento no todos los navegadores dan soporte a la validación nativa en HTML5, pero es evidente el potencial de esta característica, que proveerá de gran productividad y comodidad al programador.

Vídeo en HTML5 (básico)

Utilizando HTML siempre nos encontramos con el problema de tener que depender de QuickTime y AdobeFlash para insertar audio o vídeo. HTML5 nos da las etiquetas AUDIO y VIDEO que nos permiten, con mayor facilidad, insertar este tipo de recursos multimedia en nuestra página.

En esta ocasión nos centraremos en la etiqueta VIDEO, que como habréis podido deducir nos permite insertar vídeos en nuestra página. El uso de esta etiqueta es tan simple como lo que podéis ver en el siguiente ejemplo:


<video src="example.mp4" width="600" height="320" controls preload></video>

Ya ves que no es complejo, aunque requiere una cierta explicación. Estos son los atributos que tienes a tu disposición:

  • SRC: Enlaza con el archivo de video que queremos reproducir
  • WIDTH: El ancho del video en pixeles.
  • HEIGHT: El alto del video en pixeles.
  • CONTROLS: Nos permite incluir los controles del reproductor del navegador como el botón de play o el volumen.
  • AUTOPLAY: Permite especificar si el archivo de video se reproduce desde que se carga la pagina.
  • PRELOAD: Carga un poco el archivo de video en el buffer antes de iniciar la reproducción, para que no se trabe mientras se reproduce.

Todo parecía muy fácil hasta aquí, pero, mi querido programador web, ya sabes que NUNCA es tan fácil. Si los problemas para conseguir la compatibilidad de tu maquetación en CSS en todos los navegadores te ha hecho envejecer prematuramente varios años ya sabes lo que viene ahora: Los distintos navegadores dan soporte a distintos formatos de vídeo (seguro que no te sorprende, seguro que te lo venías oliendo). Las compatibilidade de los motores de los navegadores con los codecs de vídeo son:

  • H.264 :: Soportado por Safari, Google Chrome e Internet Explorer 9. Se trata de un codec propietario
  • OGG Theora :Soportado por Firefox, Opera y Google Chrome. Es libre, pero menos eficiente que H.264, ya que ofrece menor calidad y mayor tamaño de los archivos.
  • WebM : Soportado por Google Chrome, Firefox y Opera, aunque Google también ha creado un plugin para que funcione en IE9, y en Safari debería funcionar ya que usa como base QuickTime para reproducir vídeo. Es libre, ofrece una calidad similar a H.264 pero además consigue una mejor compresión, creando archivos más ligeros. Incluso el FlashPlayer de Adobe soportará este formato.

Todo esto provocado por el enfrentamiento entre los consorcios WHATWGs (apoyado mayoritariamente por Google, Mozilla y varias empresas del campo de software libre) y MPEG-LA (este apoyado por el eje del mal: Apple/Microsoft). Tal cual está el tema de las licencias a día de hoy, en 2016 el codec H.264 podría pasar a ser de pago, así que habrá que tener ojo con eso.

Entonces ¿cómo consigo la compatibilidad entre varios navegadores? Tampoco es difícil. Lo que tienes que hacer es no poner el atributo src dentro de la etiqueta VIDEO. En su lugar, tienes que crear etiquetas SOURCE con los distintos src y especificando en cada uno el codec, y ponerlas entre la apertura y el cierre de VIDEO, como en el siguiente ejemplo:

<video width="600" height="320" controls preload>
  <source src="ejemplo.ogv" type='video/ogg; codecs="theora,vorbis"' />
  <source src="ejemplo.mp4" type='video/mp4; codecs="avc1,mp4a"' />
  <source src="ejemplo.webm" type='video/webm; codecs="vp8,vorbis"' />
</video>

Como ves, la etiqueta SOURCE tiene como argumentos el src y type, donde definís el tipo de vídeo y el codec a reproducir.

En fin, el futuro próximo de la web está aquí, en HTML5. Haciendo uso de CSS además podréis lograr un reproductor más personalizado, más «bonito» y visible. Id pegándole un ojo.

¿Quién sustituye a Ricky?

Aunque quedan meses para los juegos olímpicos, el «Gominas» empieza a tener problemas. Ricky Rubio es baja segura desde que hace unas semanas Kobe Bryant le desgració los tendones de la pierna. Por otra parte Rudy Fernández es duda por la operación de espalda a la que se ha sometido estos días (aunque podría estar recuperado). Decía David Blatt en 2009 que para ganar «tienen que estar todos» (tenía las bajas de Kirilenko, Khryapa y JR Holden en la selección rusa). En el caso de España, con el engominado de entrenador, eso es muy cierto porque su nula capacidad táctica y estratégica hace que la selección necesite todo su potencial. No se si dejarán llevar a un solo nacionalizado como en el Eurobasket o podrán ir más (lo que avivaría un debate ¿Mirotic o Ibaka?), pero lo seguro es que, respecto al equipo campeón el pasado año en 2011, habrá que cambiar a uno de los bases. ¿Qué opciones hay para sustituir a Ricky?

  • Sergio Llull: El balear, MVP de la copa del Rey, irá seguro a la selección. La cuestión es ¿base o escolta? Llull es lo que ahora llaman un «combo guard», puede ocupar ambas demarcaciones. Dando por hecho que repetirán Sada y Calderón ¿hace falta otro base puro o mejor llevar a un alero y que Llull ocupe el puesto de base si es necesario? Será uno de los puntos a tener en cuenta en la fase de preselección.
  • Raül López: También fue un producto de la Penya, también fue una estrella en las categorías inferiores (campeón del mundo sub-20), también fue el base más prometedor de Europa en su momento y también sufrió una lesión de ligamentos. Ahora la lesión de Ricky podría devolver a Raül a la selección. El de Vich se ha reconvertido en un jugador de equipo, tiene talento, tiene experiencia y sigue siendo un gran base. Las lesiones le lastraron, pero todavía puede aportar mucho a este equipo.
  • Carlos Cabezas: Compañero de generación de Raül, fue uno de los «Juniors de Oro». A día de hoy es el base que mejor valoración está firmando en la ACB ahora mismo, dirigiendo al CAI Zaragoza con solidez y regularidad. Aunque parece que nunca tuvo suerte con la selección estuvo presente en la victoria del mundial 2006, la plata en Madrid 2007 y el oro de Polonia 2009.
  • Pedro Llompart: Sus números son similares a los de Cabezas esta temporada y está siendo uno de los mejores bases ACB, aunque se trata de un jugador que ha explotado tarde y, a pesar de sus 30 años, no tiene experiencia en competiciones importantes con la selección.
  • Josep Franch: El joven base de Badalona, con una increíble trayectoria en categorías inferiores, es posiblemente el base del futuro para esta selección junto a Ricky (que confío en que se recuperará perfectamente de la lesión). La cuestión es ¿es el base del presente? ¿Tiene cabida a día de hoy Franch en la selección? No ha hecho números como para ir pero ¿podría ir para foguearse y traer savia nueva al equipo?

¿Veteranía o juventud? ¿Seguridad o explosividad? El debate está servido de aquí al verano. Mientras, habrá que esperar y ver cómo progresa la lesión de Ricky.

Encriptando en MD5 con java

Todavía no he buceado mucho en JavaSE7, pero que yo recuerde JSE6 no incluía ninguna función que encriptara en MD5, y a la hora de trabajar con contraseñas (a nivel de seguridad web, por ejemplo) este algoritmo es muy útil. Normalmente en mis desarrollos en PHP suelo encriptar en el cliente usando una función md5 en Javascript, pero en Java podréis hacerlo con el siguiente código. Se trata de una función que recibe una cadena y devuelve su hash md5.

Bueno, primero tendréis que incluir estas dos librerías:

import java.security.MessageDigest;
import java.security.NoSuchAlgorithmException;

En todo caso, si usáis Eclipse o NetBeans para programar en Java ya os pedirá que importéis dichas librerías al añadir referencias a ellas en el código. La función es la siguiente:

        public static String cryptMD5(String textoPlano)
	{
		try
		{
		   private static final char[] HEXADECIMALES = { '0','1','2','3','4','5','6','7','8','9','a','b','c','d','e','f' };

		   MessageDigest msgdgt = MessageDigest.getInstance("MD5");
		   byte[] bytes = msgdgt.digest(textoPlano.getBytes());
		   StringBuilder strCryptMD5 = new StringBuilder(2 * bytes.length);
		   for (int i = 0; i < bytes.length; i++)
		   {
		       int low = (int)(bytes[i] & 0x0f);
		       int high = (int)((bytes[i] & 0xf0) >> 4);
		       strCryptMD5.append(HEXADECIMALES[high]);
		       strCryptMD5.append(HEXADECIMALES[low]);
		   }
		   return strCryptMD5.toString();
		} catch (NoSuchAlgorithmException e) {
		   return null;
		}
	}

La he testeado y ha ido funcionando, así que creo que os puede hacer un buen servicio a la hora de trabajar con contraseñas de forma segura.

Las 25 bandas de metal que no debieron existir jamás

Tras ver esta lista, he decidido elaborar la mía propia. Pero como ya sabéis que me encanta destilar mala baba, en luga de las 25 mejores bandas voy a poner las 25 más prescindibles (con los apodos con los que les bauticé en su día). Grupos más peñazo que el cagar cuya aparición sólo me ha aportado ardor de estómago, dolor de cabeza y otros efectos secundarios chungueros. Ok, let’s go!:

  1. Stratovarius (EscrotOvarios)
  2. Edguy (Emotobias)
  3. Avantasia (Acagarsia)
  4. Opeth (Los pesados esos suecos)
  5. HIM (El Vile Falo)
  6. Sonata Arctica (Patata Artica)
  7. Hammerfall (Jamonfall)
  8. Primal Fear (la copia chunga esa de los Judas del Painkiller)
  9. Rhapsody (Crapsody)
  10. Tierra Santa (Tierra Facha)
  11. Kamelot (Cágalos)
  12. Dream Theater (Aburriater)
  13. Dragonforce (Ratonforce)
  14. Cellador (Felador)
  15. Children of Bodom (Children of Bodrio)
  16. Orgy (Ñorgy)
  17. Jaded (las tías chungas que teloneaban a los WASP)
  18. Tarja (la pesada de opereta)
  19. Terroristars (la mierda esta del Curtonates)
  20. Arch Enemy («miradme, hago guturales»)
  21. XWild (Copia Wild)
  22. Dimmu Borgir (Dimmu Burguer)
  23. Cradle of Filth (Caca de Phil)
  24. Bon Jovi (Fan Jovi)
  25. Amon Amarth (A monte y Mar)

Iba a poner «heavy metal» en el título, pero lo he dejado en metal, que es manchar el adjetivo «heavy» con algunos de estos grupúsculos

Elaborando tu licor de chocolate casero.

Seguramente alguna vez vierais en el supermercado una botella que parece un Ferrero Rocher gigante. Se trata del popular licor de crema de chocolate Mozart, popular y relativamente caro (sobre 15 euros la botella de medio litro). Cierto es que un buen whisky de malta cuesta más, pero ese precio para una crema (cuya elaboración no requiere los años de un buen whisky) me parece excesivo.

En cualquier caso, elaborar un licor de textura y sabor similares en tu casa no sólo es fácil, sino mucho más barato. ¿Tiempo? Unas tres o cuatro horas. Pero primero te doy la lista de ingredientes:

  • Dos litros de leche entera
  • Un cuarto de litro de agua
  • Dos botellas de whisky (o una de litro y medio)
  • Un kilo de azúcar
  • 400 gramos de chocolate negro para postres (dos tabletas)

Como utensilios básicamente una pota donde quepa todo eso, un colador, un cucharón de madera (para revolver), un embudo y suficientes botellas para guardar el contenido. Un consejo, no os gastéis mucha pasta en el whisky, el sabor y el aroma van a quedar muy tapados por el chocolate, así que optad por uno barato y fuerte (yo he usado DYC, en España es de los más baratos y no demasiado malo)

Como preparación previa simplemente cortad el chocolate en trozos pequeños, como para hacer un atemperado, para que se funda bien. Usad chocolate negro, del de postres, porque si usáis chocolate con leche es probable que os quede empalagoso de cojones. Si queréis usar chocolate con leche o blanco hacedlo por vuestra propia cuenta y riesgo, sólo os recomiendo que en ese caso reduzcáis la cantidad de azúcar en consecuencia.

Bueno, ya con todo el instrumental reunido poned el kilo de azúcar en la pota, echadle el cuarto de litro de agua y removed mientras se calienta a fuego rápido. Cuando el azúcar esté ya bien mezclado con el agua añadid los dos litros de leche y seguid calentando hasta que hierva. Tras el primer hervor bajad la intensidad del fuego y, sirviéndoos del colador, retirad la nata que quede arriba. En ese momento añadid el chocolate y removed para que se deshaga. Cuando creáis que está más o menos fundido, subid el fuego otra vez para que hierva y retirad la nata again (and again, and aaaaagaaaain, que diría Ronnie James). Volved a bajar la intensidad del fuego y dejad cocer todo un rato, para que reduzca un poco la mezcla, revolviendo de vez en cuando. Llevad a ebullución una tercera vez, retirad de nuevo la nata y apagad el fuego.

Ok, has preparado un delicioso chocolate… ¿y el licor? Caaaalma. Si hubieras añadido el whisky al principio te habrías encontrado con la gracietta de que el alcohol se habría evaporado (se evapora a los 78 grados centígrados), así que espera a que el líquido esté a temperatura ambiente y añade el whisky.

Ahora ya estás listo para embotellar. Aprovecha para volver a colar de nuevo la mezcla mientras embotellas y guárdalo en la nevera. De momento lleva 8 días en la nevera de mi casa y no se ha estropeado, así que ya ves que más o menos dura.

Lo ideal es servir esta crema muy fría, si puede ser sin hielo para que no se le añada agua. Ahora mis próximos proyectos es experimentar a hacer licor de leche merengada y de vainilla, a ver qué sale.

Utilizando el cache de páginas con PHP

Cuando desarrollamos una página en PHP que necesita cargar información desde una base de datos nos encontramos que, en principio, se lanza una petición a la base de datos con cada recarga, que luego se procesa con el código PHP. Si tenemos una página web con poco tráfico (un blog, la página web de un grupo musical o un negocio), una web cuya información no cambie mucho, nos puede interesar crear un archivo de cache para evitar esta recarga. Esto ralentizará un poco la primera carga de la web, pero agilizará las sucesivas recargas de la misma, facilitando la navegación. En caso de páginas web optimizadas para dispositivos móviles (smartphone y tabs), que suelen depender de redes más lentas que los PC (por tirar de conexión 3G) es una opción muy válida.

Lo primero es crear una carpeta con permisos de escritura a la que llamaremos cache/ para almacenar ahí los archivos. Ok, allright, yeah man. Cuando nos metamos con el código (que pondré en un ejemplo más abajo) tenemos que pensar que hay que establecer un tiempo de expiración de la página, ya que si no no se recargaría nunca. Lo mejor es darle un tiempo que creamos prudencial para que sea eficiente sin llegar a dejar desactualizado al usuario. En fin, teniendo en cuenta todo esto, el código sería el siguiente:

$archivoCache = "cache/".$elnombrequecorresponda.".html"; //El archivo con el caché
$tiempoCache = 600; // el parámetro va en segundos, así que serían 10 minutazos

if (file_exists($archivoCache) && (time() - $tiempoCache
< filemtime($archivoCache)))
{
    include($archivoCache);
    echo "\n";
    exit;
}
ob_start(); //inicialización del buffer de salida

//Aquí iría el código PHP y HTML que corresponda

$fp = fopen($archivoCache, 'w'); //Abrimos el archivo con el cache

fwrite($fp, ob_get_contents());//Escribirmos el archivo
fclose($fp);//Cerramos el archivo IMPORTANTE!!!!! que mucha gente se olvida
ob_end_flush(); //limpiamos el buffer para evitar errores

En fin, creo que con estas instrucciones comentada ya os vais pispando todos de cómo funciona la cosa. Par el ejemplo di un tiempo de 10 minutos (ajustad vosotros según creáis conveniente) y la variable $elnombrequecorresponda pues… eso, que ahí ponéis el nombre que corresponda al archivo que queréis cachear.

En fin, chavatares, con esto me voy a dormir, que es tarde… o puede que no, porque no se si mi ordenador a cambiado o no la hora automáticamente. Si mañana llego tarde a todas partes le echaré la culpa. Un cibersaludo!!

Ventanas modales con jQueryUI

Como soy masoquista, tras un duro día desarrollando en PHP/Javascript creo que voy a hacer una entrada sobre informática en mi blog… por seguir esta racha.

Hoy he tenido mi primera experiencia con jQueryUI, una biblioteca para el framework jQuery. Lo he utilizado para crear un formulario de correo en una ventana modal y… oye, qué fácil, qué productividad reporta esta librería. En este enlace tenéis a vuestra disposición dicha librería, con muchas demos y documentación.

Para el caso de las ventanas modales tendremos que recurrir al widget «dialog», que nos permitirá hacer desde una suerte de alert más sofisticado hasta introducir todo un formulario (como era mi caso).

El uso de dialog() puede resumirse con facilidad en el siguiente ejemplo:

<html>
    <head>
        <link rel="stylesheet" href="css/darkness/jquery-ui-1.8.18.custom.css">
        <script type="text/javascript" src="js/jquery-1.7.1.min.js"></script>
        <script type="text/javascript" src="js/jquery-ui-1.8.18.custom.min.js"></script>
        <script>
            $(function(){
                $("#ventanaModal").dialog({
                   title:"Título a elegir",
                   modal: true
                });
            })
        </script>
    </head>
    <body>
        <div id="ventanaModal"></div>
            <p>Aquí metes lo que quieras</p>
        </div>
    </body>
</html>

Con esto tenéis lo mínimo para tener una ventana modal: un div con el contenido al que aplicáis el método dialog pasándole como parámetros el título y el parámetro modal como true (si no le pasárais modal: true se abriría también, pero no bloquería los elementos del fondo, como debe hacer una ventana modal). Pero esto queda muy soso, así que vamos a ir haciendo cosillas.

Lo primero es meter algo más de contenido, para que veas las posibilidades. Por ejemplo, una pregunta que requiera confirmación (como en un window.confirm de los de antaño):

<div id="ventanaModal">
<span class="ui-icon ui-icon-alert" style="float:left; margin:0 7px 20px 0;"></span>
    ¿Acepta usted las condiciones de uso y que le espiemos impunemente?
</div>

Ahora ya tenemos un aviso de seguridad, vamos con lo siguiente, meterle algún efectillo a la página para que quede chulo cuando se despliega en pantalla:

               $("#ventanaModal").dialog({
                   title:"Título a elegir",
                   modal: true,
                   show: "slide",
                   hide: "explode"
                });

Con esto aparecerá deslizándose y desaparecerá explotando en mil pedazos (bueno, realmente en nueve pedazos). En cualquier caso te habrás fijado en que no hay botones dentro del div. ¿Por qué? Porque los creó la desde javascript definiendo la propiedad buttons, que recibe como parámetro un objeto json con la información y con su función:

           buttons: {
            "Sí": function(){
                alert("has aceptado, tu alma es nuestra");
            },

            "No": function(){
                alert("no has aceptado, te jodes y te quedas sin servicio");
            }
        }

Como resumen entonces el javascript completo quedaría tal que así:

$("#ventanaModal").dialog({
   title:"Título a elegir",
   modal: true,
   show: "slide",
   hide: "explode",
   buttons: {
            "Sí": function(){
                alert("has aceptado, tu alma es nuestra");
            },

            "No": function(){
                alert("no has aceptado, te jodes y te quedas sin servicio");
            }
        }
});

En este caso son dos alerts chorras, pero sirve para que te hagas una idea del potencial que tiene este widget si ya has trabajado antes con javascript.

Nos queda añadir un botón, mismamente, en el html que llame a la ventana y la abra (es decir, el botón en el marcado y el script con la acción). Algo tipo:

<input type="button" name="accept" id="accept" value="Aceptar"/>
<script>
    $("#accept").button().click(function() {
	$("#ventanaModal").dialog("open");
    });
</script>

Y con esto y un bizcocho… se acabó el ejemplo. Ahora te recomiendo que te pelees un rato con esta librería, porque parece que puede dar muchas alegrías.

Firebug, tu mejor amigo.

¿Eres desarrollador web? ¿Estás interesado en serlo? ¿Buscas herramientas que te simplifiquen la vida? Entonces necesitas Firebug

¿Qué es Firebug? te dirás. Firebug es una herramienta cojonuda, Open Source y con licencia BSD (y además gratis), que puedes instalar como un add-on en Mozilla Firefox. Si conoces otras herramientas como el Firefly de Opera, ChromeInspector, o las herramientas de desarrollo web de Internet Explorer te puedo decir que Firebug se las merienda. Mucho más simple, claro, usable y productivo.

¿Qué nos permite Firebug? Nos permite inspeccionar el código HTML de las páginas, depurar código javascript, comprobar la comunicación con el servidor, testear ciertos aspectos de la seguridad de la página, inspeccionar DOM, probar modificaciones en el CSS (con la seguridad de que no te cargas nada)… Todo con pasmosa facilidad, y además, para los hispanoparlantes, disponemos de él en castellano (y es posible que aparezca próximamente una versión en gallego pero… de momento dejadlo en rumore)

¿Su principal defecto? Mayormente que no haya una versión para cada navegador, de momento sólo dispones para él en Mozilla Firefox

Existen inclusive parches que te permitirán utilizarlo para testear código flash, e incluso decompilar los archivos swf.

Tienes también a tu disposición una wiki con diversa información (en inglés) sobre este plugin en el siguiente enlace. Y me reitero, Firebug es una herramienta que me ha salvado el culo en muchos desarrollos, tanto como autónomo como en empresas, no es un juguete, sino una buena herramienta de trabajo. No podía dejar de declararle mi amor en este blog, es un proyecto que merece mucho la pena y que, si lo sabes utilizar, te facilitará mucho el trabajo. No dejes de probarlo.

Introduciendo Prototype // Combinar jQuery con Prototype

Aunque me había planteado llevar mi debate de Twitter con mi colega Jumnper sobre el «Rock the Rebel, Metal the Devil» de Volbeat a este blog (a él le encanta, a mi me recuerda terriblemente al Load de Metallica), creo que mejor seguiré un poco más con entradas centradas en informática, por «comercialidad» porque son las más leídas (curiosamente tengo un montón de visitas desde México en este tipo de entradas)

Más de una vez he hablado de jQuery aquí, un gran facebook que nos da gran productividad en javascript, pero que no es la única opción. Prototype desde un primer momento ha protagonizado una encarnizada batalla con jQuery por la corona de «framework más usado». Podéis descargarlo en este enlace para trastear con él.

Al igual que en jQuery existe una función $, que en Prototype nos permite seleccionar los elementos por su ID. Dirás «en jQuery es mejor porque permite cualquier selector CSS», cierto, pero también existe una función para eso, que es $$

Otros métodos intersantes son $F, que accede al valor de un campo de un formulario, $A, que convierte listas de nodos o colecciones HTML en arrays, $H, que permite crear arrays asociativos o $R, que permite crear rangos de valores.

A la hora de trabajar con cadenas tenemos el método escapeHTML(), que permite transformar los caracteres problemáticos en su entidad HTML. También puedes usar toArray(), que convierte la cadena en un array de caracteres, y dispones de camelize(), que convierte una cadena separada por guiones a notación CamelCase.

Los métodos .show() y .hide() son lo que parecen ser, ocultan o muestran el elemento seleccionado (como sus homónimas en jQuery). En cambio .toogle() lo que hace es cambiar el estado entre show y hide dependiendo de en cual esté el elemento.

En cuanto a métodos para campos de formulario lo más interesante me parece .clear(), que vacía el valor de un campo, y .present(), que es cojonudo para validar campos, dado que devuelve false si el campo está vacío. Y si aplicas .disable() a un formulario lograrás desactivar todos sus campos.

Pero es con Ajax con lo que Prototype realmente te facilita la vida. Tienes Ajax.Updater(), que recibe tres parámetros: el ID del elemento a recargar por ajax, la página php que generará el código y varias opciones, y con Ajax.PeriodicalUpdater sólo tendréis que pasarle el parámetro frecuency seguido de un número ({frecuency:30}) para que realice una recarga automática por cada intervalo de ese número de segundos.

Y trabajando con DOM tampoco os dejará tirados este framework. El método .insert(), por ejemplo, os dejará elegir si queréis ponerlo detrás de, delante de, antes o encima de, y después o debajo de un elemento en concreto.

¿Mejor jQuery o Prototype? Bueno, cada uno tiene sus debilidades y sus potenciales. Yo uso más jQuery, por conocerlo mejor, pero incluso los podéis usar a la vez. Pero cuidado, tenéis que hacer un apañito antes para evitar conflictos, dado que ambos tienen un método $. La forma de evitar el conflicto es usando el método .noConflict() como en el ejemplo:

var $jQ = jQuery.noConflict();

A partir de ese momento la abreviatura de jQuery (que por defecto es $) pasar a ser la que tú has definido en la variable (en este caso $jQ), permitiéndote usar ambos frameworks sin conflicto entre ellos.

De todas formas, no suele ser práctico utilizar dos frameworks, aunque evites los conflictos siempre estás metiendo más carga a la web (aunque por otra parte, pesan bastante más muchas imágenes que los archivos .js de estos frameworks).