Translate

jueves, 11 de abril de 2013

HTML5 y WebStorage. Almacenamiento de datos en local

Hasta el momento, los datos almacenados desde una página HTML solo podían tratarse en 4KB de una coockie o bien, debían tratarse en una base de datos del servidor web.

HTML5 rompe esta limitación y se apoya en navegadores más evolucionados que soportan esta funcionalidad; por tanto, se pueden implementar ya perfectamente en los sitios web que realizamos en la actualidad.

Esta soportado por las siguientes versiones o superiores de cada navegador:
  • IE 8.0+
  • Firefox 3.5+
  • Safari 4.0+
  • Chrome 4.0+
  • Opera 10.5+
  • iPhone 2.0+
  • Android 2.0+

El API WebStorage se divide en dos vertientes, el "SessionStorage", para guardar información que caducará al final de la sesión y el "LocalStorage", que permite almacenar datos que perduren entre distintas visitas del mismo usuario al sitio web.

Ahora un poco de teoría.

API: INTERFAZ STORAGE

Permite acceder a una serie de pares clave/valor, también llamados ítems. Está implementada por los objetos SessionStorage y LocalStorage, explicados más adelante.

Se podría pensar en el objeto como un array asociativo, es decir, un array al que se puede acceder a través de un índice de tipo string (clave) y no necesariamente una posición.

ATRIBUTOS:

length: devuelve el número de pares clave/valor que contiene el objeto. Es de sólo lectura, no es modificable.

MÉTODOS:

key(pos): devuelve la clave que se encuentra en la posición indicada en la variable "pos" que se pasa como parámetro. El parámetro puede ser un literal, es decir, un número, o bien una variable que contenga un valor numérico.

Si la posición es mayor que el número de elementos (length - 1), entonces devuelve null.

getItem(clave): obtiene el ítem del objeto que contiene como clave el valor que se le pasa como parámetro. 'clave' puede ser una cadena de caracteres o una variable de tipo string.

También se puede obtener la clave tomando el objeto como si se tratase de un array asociativo, es decir, storage['clave'] o accediendo como objeto storage.clave.

setItem(clave, valor): comprueba si la clave existe en el objeto, si no existe la inserta y en caso de existir, actualiza su valor al valor que se le pasa como segundo parámetro.

También se puede asignar una clave como si se tratase de un array asociativo, es decir, storage['clave'] = 'valor' o actualizando como objeto storage.clave = valor.

Como curiosidad, decir que los datos se guardan en orden alfabético.

removeItem(clave, valor): comprueba si la clave existe en el objeto, si no existe la inserta y en caso de existir, actualiza su valor al valor que se le pasa como segundo parámetro.

clear(): elimina todos los pares clave/valor del objeto.

SESSIONSTORAGE

Puede guardar información referente a una ventana/pestaña en la que el usuario lleva a cabo una transacción simple, pero podría llevar a cabo múltiples transacciones en diferentes ventanas/pestañas al mismo tiempo.

Para ello se utiliza el atributo sessionStorage. Cabe destacar que los datos se pierden al cerrar el navegador.


LOCALSTORAGE

Puede almacenar información útil para múltiples ventanas/pestañas, que perdura en el tiempo. No se puede compartir de navegador a navegador. Para ello se utiliza el atributo localStorage. En este caso los datos no desaparecen aun cerrando el navegador, únicamente se borrarán haciendo un borrado manual, mediante código, a través de la consola del navegador o borrándolas directamente desde la carpeta en la que se guardan en el SO.

EJEMPLO:

Creamos una página HTML5 y crearemos un ejemplo con LOCALSTORAGE :








<html lang="es">
<head>
.....
<script>
function save()
{
var vnombre = document.getElementById('nombre').value;
var vedad = document.getElementById('edad').value;
var vemail = document.getElementById('email').value;
localStorage.setItem('text_nombre', vnombre);
localStorage.setItem('text_edad', vedad);
localStorage.setItem('text_email', vemail);
}

function load()
{

if (window.localStorage) {

alert(localStorage.length);

var storedValue = localStorage.getItem('text_nombre');
if(storedValue) {
document.getElementById('nombre').value = storedValue;
}
var storedValue = localStorage.getItem('text_edad');
if(storedValue) {
document.getElementById('edad').value = storedValue;
}
var storedValue = localStorage.getItem('text_email');
if(storedValue) {
document.getElementById('email').value = storedValue;
}
} else {
alert('Actualice navegador!!!');
}
}

function remove()
{
document.getElementById('nombre').value = '';
document.getElementById('edad').value = '';
document.getElementById('email').value = '';
localStorage.removeItem('text_nombre');
localStorage.removeItem('text_edad');
localStorage.removeItem('text_email');

// tambien vale
localStorage.clear();
}
</script>

.....
</head>
<body onload="load()">
<form name="formulario">
<label for="nombre"&gtNombre&lt/label&gt&ltinput type="text" name="nombre" id="nombre" />
<label for="edad"&gtEdad&lt/label&gt&ltinput type="text" name="edad" id="edad" />
<label for="email"&gtMail&lt/label&gt&ltinput type="text" name="email" id="email" />
<input type='button' value='guardar' onclick="save()">
<input type='button' value='eliminar' onclick="remove()">
</form>
</body>
</html>

Es un ejemplo muy funcional y sencillo, cada vez que se recarga la página load() preguntará si el navegador soporta LOCALSTORAGE con if (window.localStorage) e indicará cuantos elementos están almacenados alert(localStorage.length); y a continuación carga los datos desde LOCALSTORAGE y los muestra en el formulario.

Solo tiene un botón GUARDAR y otro ELIMINAR, para guardar y eliminar los datos almacenados respectivamente. Cada dato se guardará como una clave/valor diferente, en este caso guardaremos tres claves/valores, aunque con un poco de código es posible guardar muchos valores en una sola clave si fuera necesario.

Cuando la base de datos ha llegado al límite de su máximo contenido ( 5Gb ), se puede comprobar con :

try {
localStorage.setItem('foo', 'bar');
} catch (e) {
if (e == QUOTA_EXCEEDED_ERR) {
alert('el almacén local excede el tamaño máximo permitido');
}
}

RECOMENDACION

Si aún no has encontrado un buen EDITOR para HTML y otros (también útil para PYTHON), te recomiendo SUBLIME TEXT


miércoles, 10 de abril de 2013

Desmontar la Torre de Babel

Es sencillo recorrer el camino que todos pisan, es cómodo, solo debes adaptar tu velocidad, algúnos dirían que llegas antes...todo son ventajas. Otros, los más inquietos, buscarán salirse del camino, orientarse en libertad, disfrutarán con nuevos paisajes antes nunca vistos, huirán del camino marcado que estará demasiado transitado para su gusto.

Mi propuesta intenta tomar lo mejor de los dos, estudiar, copiar, crear e innovar. Para mejorar es necesario aprender y copiar del mejor o de los mejores, trazar nuestro rumbo hacia la innovación y crear algo nuevo a partir de algo antiguo. Aplicando estos conceptos a la construcción de un marco de programación web en PYTHON y después de leer sobre Bottle, Flask, Django, Twisted, Tornado, Werkzeug...estudiar su código, comprobar cómo se resuelven problemas que ni sabía que existían, busco un nuevo camino a mi medida, que me permita aprender y el final del viaje será volver a empezar uno nuevo.

Planificar una serie de módulos que serán muy necesarios para nuestro framework personal, es esencial :
  • (1)¿Cómo gestionar los accesos en el servidor web ? WSGI, SOCKET...
  • (2)¿Cómo crearemos nuestras páginas html, javascript, css?
  • (3)¿Cómo trataremos las solicitudes de rutas y parámetros de nuestro proyecto ?
  • (4)¿Cómo vamos a reconocer a los usuarios que acceden y mantendremos su identidad a salvo?
  • (5)¿Deberíamos adaptarnos a los distintos dispositivos que pueden conectarse a nuestra información de forma dinámica?
  • (6)¿Necesitamos aplicar geobloqueos?¿O redirigir a los usuarios a servicios específicos según su origen?
  • (7)¿Cómo realizaremos una compresión de los datos que proporcionemos?
  • (8)¿Necesitamos un tratamiento en profundidad de imágenes?
  • (9)¿Necesitamos realizar pagos seguros?
  • (10)¿Cuántas conexiones esperamos? ¿Necesitamos un sistema de alto rendimiento para varios millones de accesos?
Más allá de la perfección, pretendo responder a unas necesidades sencillas. Por tanto, buscamos un sistema sencillo y efectivo, lejos de una sobrecarga de módulos :

(1) He decidido usar WSGI sobre un servidor web ( APACHE ), evitaré las complicaciones de un servidor de aplicaciones.

(2) Debemos implementar HTML5, CSS3, JAVASCRIPT y personalizar las respuestas en función del dispositivo que acceda a la información. Es más acertado crear un módulo completo para templates que me proporcione todas estas facilidades.

(3) El sistema debe ser capaz de redirigir la petición de forma correcta y traducir sus parámetros p.ejemplo : www.prueba.es/20130410/francia/editorial/, al recibir esta solicitud podremos comprobar los parametros 20130410, FRANCIA y EDITORIAL, buscando una respuesta válida según una plantilla y en caso contrario, buscar una respuesta por defecto.

(4) Existen varias formas de identificar a un usuario. Principalmente se utiliza una sesión que se almacenará en el servidor y en una cookie en el cliente. También es posible que el navegador del cliente no admita cookies, en este caso deberíamos marcar todas las páginas con el código de la sesión en un datos HIDDEN, de forma que cuando recibamos la respuesta de la página, nos enviará el dato oculto que contrastaremos con la sesión guardada en el servidor.

Con HTML5 se abren otras posibilidades más extensa con sessionStorage, localStorate o genéricamente webStorage. Con las nuevas incorporaciones de HTML5 podríamos almacenar en modo local (CLIENTE) información en tablas de una base de datos local y persistente (persistente por dominio), podríamos aplicar mejoras en carros de compra, agendas, webmail,...

(5) Un módulo específico que sabe leer las cadenas de identificación de cada navegador 'user agent', donde se puede obtener el idioma o idiomas aceptados, sistema operativo, dispositivo, motor, navegador y versión. Toda esta información puede ser complementaria de otras que obtengamos mediante javascript, como tamaño de la pantalla y resolución. Adaptando la información de salida, para la que también se tendrá en cuenta, la información obtenida de otros módulos.

(6) Cada día es más importante tratar información geográfica en las comunicaciones, a veces para evitar ataques, otras para cumplir la legislación de algunos países o para comunicar información adaptada.

(7) Habitualmente los navegadores tienen módulos preparados para comprimir los datos enviados y acelerar la información. También podíamos incluir aquí parte del módulo (8), enviar imágenes adaptadas a tamaños o compresión, permitir o negar el cacheo de la información en el cliente, ...etc.

(8) Con un tratamiento de imágenes, me refiero a permitir corregir tamaños de imagen, transformar datos binarios de una imagen a una cadena en BASE64 para incrustarla en código HTML o CSS3 (estas imágenes no se cachean y tienen un plus de protección), permitir adaptar imágenes dinámicamente a cada pantallas de dispositivos,...etc.

(9) Si necesitáramos una plataforma de pago, deberíamos crear un módulo con las funcionalidades necesarias.

(10) Esto todavía está muy lejos de nuestras necesidades, tendrá respuesta a su debido tiempo.

Es posible desanimarse antes de empezar, pero si conseguimos un desarrollo de framework adaptado a nuestras necesidades, habremos contruido nuestra propia herramienta y podremos dotarla de mejoras en un futuro. Por contra, cualquier framework al uso, nos exigirá una mínima formación, práctica y desarrollar nuestros proyectos en función de la disponibilidad de módulos.

Es necesario que tengamos en cuenta unas reglas básicas, un framework o marco de desarrollo, nunca estará totalmente terminado. Se incorporarán nuevos añadidos en función de nuestras necesidades o de proyectos futuros. Y cada módulo siempre será objeto de mejoras en código y eficiencia, lo que permitirá realizar mejoras de forma indirecta en proyectos pasados.

Para escribir todos estos datos, he realizado todo el proceso que indico de forma efectiva y ha concluido con un desarrollo real PYMETRICK, aunque como indico anteriormente, nunca finalizado, y ahora en fase de pruebas. Con el tiempo, los módulos serán objeto de artículos más detallados.
PYMETrick