Backbone.js

MVC es un patrón omnipresente en el lado del servidor. Existe en todas las plataformas web: JSF, Struts o Spring MVC en JavaEE, ASP.NET MVC en .NET, CakePHP, Symphony, Codeigniter y otros en PHP, Rails en Ruby, Django en Python,…​

A finales de los 90, Sun propugnó lo que dio en llamar "modelo 2" como patrón básico de arquitectura para aplicaciones web basadas en servlets y JSPs. Con mayores o menores modificaciones, este modelo fue la base de Struts y otros frameworks MVC del mundo JavaEE como Spring MVC. En el modelo 2, las peticiones del cliente las recibe un servlet, que hace el papel de controlador, y que delega la lógica de negocio en un conjunto de JavaBeans (el modelo). Finalmente el control se transfiere a un JSP (la vista), que muestra los resultados al usuario. No obstante, Sun nunca llegó a estandarizar un API o un framework para implementar MVC en nuestras aplicaciones.

En la actualidad, en un mundo de aplicaciones web convertidas en "simples" APIs en el lado del servidor, la antigua preponderancia de MVC en el servidor parece haberse difuminado un poco. Lo que es lógico, ya que la vista se ha trasladado al cliente. Así, la "necesidad" de usar MVC para estructurar la aplicación ha acabado trasladándose también al lado del cliente.

Cuando el uso de Javascript se limitaba a cosas como validación de formularios, pequeños cálculos y algunos efectos visuales MVC en el cliente no hacía una gran falta. El interfaz ya venía construido desde el servidor en forma de plantillas, y asímismo el servidor ya generaba casi todos los datos que se le mostraban al usuario. Pero en la actualidad se tiende a ir hacia SPAs (Single Page Applications), en las que básicamente la interfaz se construye dinámicamente con Javascript, lo que incluye también el formateo y presentación de los datos que está viendo el usuario, y la gestión de los nuevos que crea. Esto implica que desde Javascript también debemos poder manipular el modelo y ejecutar lógica de negocio. El servidor se queda como una especie de fuente de datos remota. Como vemos, prácticamente todo el esquema del antiguo "modelo 2" se ha trasladado al cliente.

Backbone fue uno de los primeros frameworks MVC en hacerse popular. Su filosofía va en la línea de lo que los anglosajones llaman "non opinionated", es decir, un framework que da libertad al desarrollador para hacer las cosas con su propio estilo, y no impone cierta forma de trabajar. Esto si lo queremos ver desde el punto de vista negativo, hace que el proceso de aprendizaje esté mezclado con cierta inseguridad para el desarrollador, ya que nunca acaba de tener claro "si lo está haciendo bien".

Otro aspecto que define el carácter de Backbone es la simplicidad. Es pequeño en términos de número de líneas de código y por tanto las funcionalidades que ofrece "tal cual" son limitadas. No ofrece facilidades "automágicas", casi todo está bajo control del desarrollador. Esto ha hecho que surjan multitud de plugins para cubrir las funcionalidaes que Backbone no tiene y sí tienen otros frameworks más complejos.

Cuando se habla de MVC, siempre surge la duda de exactamente de qué tipo de MVC se está hablando. Desde que apareció la versión original del patrón en los 70, en el contexto de aplicaciones de escritorio desarrolladas en Smalltalk, han surgido multitud de variantes, en las que cambian los roles que desarrolla exactamente cada uno de los componentes "Modelo/Vista/Controlador" o el flujo de información que hay entre ellos. Incluso hay versiones en las que alguno de los componentes del trío original desaparece y es sustituído por otros, como MVP (Model/View/Presenter), MVVM (Model/View/ViewModel),…​

Backbone no es exactamente MVC, más que nada porque directamente carece de controladores. En cuanto a qué es entonces, exactamente no lo vamos a responder aquí, más que nada porque es una discusión probablamente infructuosa y que en cualquier caso no va a ayudar a comprender mejor su funcionamiento. Nos conformaremos con llamarlo MV*, como dicen los anglosajones, MV- whatever, o MV- loquesea.

Teniendo presente lo que acabamos de decir, la siguiente figura mostraría una posible estructura conceptual de una aplicación Backbone (posible porque también podríamos estructurar las cosas de otro modo y tampoco "estaría mal"). La figura está tomada del libro de Addy Osmani "Developing Backbone Applications", que además está disponible en Github

Como vemos en la figura, en el "corazón" de Backbone están los modelos y las vistas. Además, para reflejar el hecho de que típicamente en una aplicación vamos a manejar más de una instancia del mismo tipo de modelo (clientes, libros, mensajes,…​) Backbone modeliza también la idea de colección de modelos.

Las colecciones de modelos interactúan (se sincronizan, sync) con una fuente de datos, típicamente un API REST en el servidor.

Por otro lado, la vista interactúa con el HTML de la página. La vista actualiza el DOM, modificando así el HTML "en tiempo real" y en el sentido contrario, los eventos del DOM se procesan en la vista.

Vista y modelo se comunican mediante eventos. Esto se hace así para reducir el acoplamiento entre ambos. Es normal que la vista tenga que conocer ciertos detalles del modelo para poder interactuar con él, pero en general el modelo no debería tener que conocer cómo es la vista para comunicarse con ella. Así podremos reutilizar los modelos cambiando una vista por otra. Para solucionar este problema se usa el paradigma de comunicación "Publicar/Suscribir" (Publish/Subscribe o Pub/Sub). En este paradigma el objeto que quiere comunicarse con otro sin acoplarse con él no lo hace directamente sino emitiendo eventos. El objeto interesado se suscribe a esos eventos. En Backbone veremos que la vista se suscribe a los eventos que le interesan del modelo.

Para terminar, el router es un componente que asocia URLs con código Javascript. La idea es que cada operación o cada estado de nuestra aplicación debería identificarse con una URL, lo que permitiría que el usuario creara sin problemas sus bookmarks.

Como ya hemos visto, el modelo es el conjunto de objetos que forman el dominio de nuestra aplicación y por tanto depende enteramente de su naturaleza: en un "campus virtual" tendremos profesores, alumnos, notas, …​ mientras que en una red social tendremos usuarios, mensajes, fotos, …​

Los modelos son realmente las mismas entidades que usamos en la capa de negocio de la aplicación. En ellos encapsulamos por tanto dos aspectos: los datos y la lógica de negocio. En nuestro ejemplo del tiempo los datos serán los parámetros que definen el estado actual del tiempo (temperatura, humedad, descripción en modo texto: - "soleado", "nublado", …​-). La lógica de negocio se ocuparía de la comunicación con el servicio web remoto que nos ofrece los datos.

Backbone nos ofrece una "clase" base, Backbone.Model, que podemos extender para crear nuestros propios modelos. No es necesario especificar por adelantado las propiedades del modelo, se pueden crear en cualquier momento, igual que con los objetos Javascript convencionales

Antes de ver cómo implementamos la lógica de negocio, necesitamos saber cómo funciona el API del servicio web. Básicamente hay que hacer una petición GET a http://api.openweathermap.org/data/2.5/weather con el parámetro q igual al nombre de la localidad y el valor de nuestra API KEY como valor del parámetro APPID (podemos obtenerla registrándonos en OpenWeatherMap) . Podemos hacer pruebas provisionales con APPID=1adb13e22f23c3de1ca37f3be90763a9.

Si además añadimos los parámetros units=metric&lang=es obtendremos el resultado en español usando unidades del sistema métrico. La respuesta será un JSON del estilo

Como vemos, la descripción del tiempo está en el campo weather[0].description. El weather[0].icon es el icono que lo representa gráficamente. Como indica la documentación, para obtener el icono hay que ponerle delante a este nombre una URL base.

Con esto ya podemos implementar la llamada al servicio web desde nuestro modelo. La lógica de negocio la implementaremos normalmente con propiedades de tipo function(). Como la funcionalidad la deben tener todas las instancias de la clase, le asignaremos la propiedad a la clase:

Podemos probar el funcionamiento del código anterior tecleando algo como lo que sigue en la consola Javascript:

La vista en Backbone tiene la misión de generar el HTML que represente el modelo en pantalla. Es decir, de dibujar el widget. También debe responder a los eventos del usuario. En nuestro caso el único evento es la pulsación en el botón "ver tiempo".

Las vistas heredan de la clase Backbone.View, y deben tener asociada una instancia de un modelo (también podrían tener varias instancias, como veremos en la siguiente sesión).

Como ya hemos dicho, tenemos un pequeño problema: ¿cómo hacemos que el modelo avise a la vista de que actualizarTiempo ya ha acabado y que por tanto se puede ejecutar el renderData()? podría ejecutarlo el propio modelo, pero necesitaría mantener una referencia a la vista y esto haría que dejara de ser genérico y se "atara" a la vista (asumiera que siempre va a estar asociado a una vista que tiene un método renderData).

La solución más limpia para comunicar del modelo hacia la vista es no tocar el código del modelo en absoluto y usar la idea de "Publicar/Suscribir". Por defecto, los modelos de Backbone emiten eventos cuando se dan ciertas situaciones, por ejemplo que cambia una propiedad, o que el modelo se sincroniza con el estado del servidor. Lo único que debe hacer la vista es encontrar el evento apropiado y suscribirse a él. En este caso, el evento que nos viene que ni pintado sería que la propiedad dt del modelo adquiera un nuevo valor. Recordemos que esta propiedad es un timestamp que nos indica cuándo se han obtenido los datos.

En el initialize de la vista, que se usa para inicializar valores por defecto y otros elementos, podemos suscribirnos al evento del modelo. Esto se puede hacer con el método listenTo, indicando a qué objeto queremos suscribirnos, qué evento nos interesa, y cuál va a ser el manejador de evento:

El resto del código de la vista quedaría igual que antes. Como vemos, la función que dispara la actualización del tiempo no necesita llamar a renderData ella misma. Si la operación de actualización cambia el atributo dt del modelo se llamará a renderData automáticamente.

Este ejercicio debes entregarlo en una carpeta llamada mi_tiempo_backbone.

En este ejercicio vamos a modificar el modelo del widget del tiempo para incluir también la temperatura actual, y crearemos una nueva vista que incluya esta información.

Este ejercicio debes entregarlo en una carpeta llamada UAdivino.

Crear una aplicación de Backbone que funcione al estilo de la conocida "bola 8 mágica", a la que se le "hace una pregunta" en voz alta y nos responde algo al azar.

El widget tendrá un aspecto similar al siguiente:

Los modelos en Backbone siguen la filosofía de Javascript: son dinámicos y podemos añadir y eliminar atributos sobre la marcha. Para añadir un atributo, o cambiar su valor si este ya existe, usamos set(nombre, valor). Para obtener el valor, get(nombre). Continuando con el ejemplo anterior:

También podemos fijar los valores de los atributos al instanciar el objeto con new. Se los pasamos a este método en forma de hash:

Si deseamos eliminar un atributo podemos usar unset(nombre), aunque este método lo único que hace es borrar el atributo usando delete. Podríamos hacer lo mismo accediendo directamente a la propiedad de la clase llamada attributes, que es la que contiene los atributos en sí

Podemos comprobar si un objeto tiene un determinado atributo con has(nombre), que devolverá un valor booleano indicándolo.

Como ya hemos dicho, cuando creamos una clase que hereda de Backbone.Model podemos definir propiedades en forma de objeto Javascript, normalmente usando notación literal. De hecho podemos definir propiedades de instancia y propiedades de clase. Las primeras serían propias de cada instancia de nuestro modelo. Las segundas serían de la clase del modelo en sí. En Backbone ya vienen definidas por defecto unas cuantas propiedades de instancia. Por ejemplo cada objeto tiene un cid que es un identificador único y se va generando secuencialmente.

Lo habitual es usar las propiedades especificadas en el extend para definir métodos. Un método no va a ser más que una propiedad que resulta ser una función. Por ejemplo:

Todos los modelos tienen una propiedad por defecto cid (client id) que actúa como identificador y cuyo valor va generando automáticamente Backbone. Como luego veremos, cuando el modelo se almacena en el servidor también pasa a tener una propiedad id, con valor asignado por este.

Podemos ejecutar un determinado código cuando se cree el modelo, poniéndolo en el método initialize

Aunque si lo que queremos es simplemente inicializar atributos con valores por defecto es más directo usar la propiedad defaults. A esta propiedad se le pasa un objeto en notación literal con los nombres de los atributos y sus valores por defecto:

La solución es hacer que defaults sea una función que devuelva un objeto con los valores deseados, así, cada instancia tendrá su propia copia de valores por defecto.

Backbone ofrece un método validate() para la validación de datos, pero el código tenemos que escribirlo nosotros por completo, no existe ningún tipo de validación declarativa.

Si la validación es correcta el método validate() no debería devolver nada. En caso de que sea incorrecta, corre por cuenta del desarrollador qué devolver, mientras se devuelva algo. Por ejemplo:

validate() recibe como parámetro un objeto con los atributos que se están validando. Backbone llama automáticamente a validate() al guardar un objeto en el servidor. En ese caso los atributos recibidos en validate() son los actuales del objeto.

Además validará el cambio de valor de un atributo si pasamos la opción validate:true. En este caso los atributos recibidos en validate() son los nuevos valores que estamos intentando fijar.

Para crear el modelo en el lado del servidor llamaríamos al método save().

La creación del objeto en el servidor implica una petición POST. Antes de hacer esta petición se llama a validate(), y si la validación falla, save() devuelve false.

Una vez hecha la petición, Backbone espera que el servidor le devuelva un JSON incluyendo al menos la propiedad "id" con el identificador del nuevo recurso creado. Si esto se cumple, la librería establece la propiedad id del modelo a este valor.

Si el servidor usara una propiedad con nombre distinto a id para devolver el identificador del objeto, podemos poner este nombre como valor del atributo idAttribute del modelo.

Para tener más información sobre la respuesta devuelta por el servidor debemos pasar dos callbacks en el save(), uno para llamar en caso de éxito (código de estado en el rango 200-299) y otro en caso de error:

También podemos usar la sintaxis de promesas. En caso de superar la validación, save devuelve un objeto jqXHR, que es un wrapper de jQuery para el XMLHttpRequest nativo que además implementa la interfaz de promesas, así que podemos simplificar un poco la sintaxis y por ejemplo hacer más sencillo el encadenamiento de operaciones:

El método fetch() le pide al servidor los datos del modelo, sobreescribiendo los actuales. Asume que la respuesta va a venir en forma de objeto JSON. Para poder usar este método el objeto ya debe tener un id asignado, ya que la URL a la que se va a lanzar la petición get es la urlRoot + /id.

Si los valores de los atributos procedentes del servidor difieren de los actuales se disparará un evento change. Posteriormente veremos cómo hacer que un objeto determinado observe un evento que genera otro.

La última línea imprimirá undefined ya que no habrá dado tiempo a que el servidor responda y a rellenar el objeto con los valores de la respuesta. Sin embargo si depuramos el código ayudándonos de un debugger paso a paso, daremos tiempo a que se procese la respuesta y sí mostrará el login correctamente, con el consiguiente WTF! por nuestra parte. Para poder enterarnos de cuándo se ha rellenado la información del objeto tenemos que usar callbacks en fetch() o bien usar eventos, como veremos al final de la sesión.

La actualización se dispara con el mismo método que sirve para crear un objeto en el servidor: save(). Backbone asume que un modelo que tiene valor asignado a la propiedad id ya existe en el servidor, y por tanto al llamar a save() lanzará un PUT a urlRoot + /id.

Para eliminar un objeto del servidor se usa destroy(), que lanzará una petición DELETE a urlRoot + /id, salvo que todavía no haya sido guardado en el servidor (no tenga id), en cuyo caso no hará petición y devolverá false.

Podemos obtener el modelo en una posición con el método at(). Como los arrays, las colecciones mantienen una propiedad length con el número de elementos.

Si conocemos el id o el cid del modelo, podemos obtenerlo directamente con get().

para iterar por la colección podemos usar el típico bucle for que vaya incrementando un índice y usar at(), pero también podemos usar un iterador:

Al forEach se le pasa una función, que será llamada conforme se vaya iterando por la lista. Como argumento la función recibirá el objeto en la posición actual. Este y otros métodos de manejo de colecciones y eventos procede en realidad de la librería underscore, que como ya hemos comentado es un prerrequisito de Backbone.

En principio el orden de los elementos al recorrer la colección es el de inserción, pero también podemos especificar un criterio de ordenación. Para casos sencillos podemos darle al atributo comparator el nombre del campo usado para clasificar.

Si necesitamos usar un criterio más complejo le podemos asignar a comparator una función con un único argumento que a partir del objeto devuelva el criterio de ordenación.

También podemos usar una función con dos argumentos que actúe como un comparador: dados dos objetos a comparar devuelve -1 si el primer argumento es menor que el segundo, +1 si es mayor y 0 si son iguales.

Podemos filtrar una colección ayudándonos de la función filter de underscore. Por ejemplo, aquí vemos cómo podríamos filtrar una colección de usuarios obteniendo solo los que tienen un password de menos de 6 caracteres.

Podemos añadir un nuevo modelo o array de modelos a la colección con add(). El modelo se añadirá en la posición especificada por el criterio de ordenación actual. Si queremos añadir por la cabeza usaríamos unshift() y por la cola push(). Podemos eliminar un modelo o un array de ellos con remove(), o eliminar el de la cabeza con shift() y el de la cola con pop().

El método set() se usa para "actualizar" una colección. Si un modelo de la nueva colección no existe en la actual se añadirá, si estaba en la antigua pero no en la nueva se eliminará, y si existe en ambas se mezclarán sus atributos (los que existan en antigua y nueva se actualizarán al valor de la nueva).

Para obtener una colección del servidor se usa el método fetch(), igual que con los modelos. Si la colección no está vacía no se elimina completamente, sino que se usa el método set() para actualizar la del cliente.

Para guardar la colección en el servidor, actualizarla o eliminarla tendremos que ir procesando los modelos uno a uno. No obstante en los modelos incluidos en colecciones no es necesario especificar la urlRoot de cada uno por separado, se usa automáticamente la url de la colección como URL base.

En Backbone cualquier componente (modelo, vista, colección o router) puede observar los eventos emitidos por cualquier otro componente. Pero también podemos hacer que cualquier objeto Javascript pueda emitir y recibir eventos. También podemos hacer que cualquier objeto Javascript sea capaz de observar eventos de Backbone haciendo un mixin del objeto con la clase Backbone.Events. Es tan sencillo como llamar al método _.extend de Underscore pasándole como parámetros el objeto y la clase Events:

Hay varias posibilidades para suscribirnos a los eventos que nos interese. La más usada es el método listenTo, al que se le pasa como parámetro el objeto a observar, el nombre del evento y la función handler. Por ejemplo, supongamos que desde un modelo queremos observar cuándo cambia algún atributo de otro:

Recordemos que si el observador no es un componente de Backbone, primero tenemos que hacer un mixin con Backbone.Events. Lo demás es idéntico.

Para dejar de escuchar todos los eventos que emite un objeto podemos usar stopListening pasando como parámetro el objeto que queremos "ignorar" de ahora en adelante.

Habitualmente los observadores de los eventos no serán objetos propios como en nuestro ejemplo, sino componentes de Backbone. Típicamente son las vistas las que observan el comportamiento del modelo, lo que permite comunicarlos sin introducir acoplamiento entre ambos. El modelo puede indicar que ha cambiado para que la vista muestre los nuevos datos, sin necesidad de mantener una referencia a la vista, ni siquiera saber cómo se llama el método de la vista que procesa los cambios.

Antes hemos visto el caso de la operación fetch, para actualizar un modelo/colección con los datos del servidor, que al ser asíncrona continúa la ejecución sin haber recibido todavía los datos. Podríamos saber cuándo se han recibido por ejemplo suscribiéndonos al evento sync, que se dispara cuando los datos locales se sincronizan con el servidor.

Podemos también generar un evento manualmente, incluso eventos propios. En caso de ser un evento propio lo único que tenemos que hacer es inventar un nombre para el evento. Por convenio se usa el tipo de componente y el nombre dado al evento separados por :. Por ejemplo model:miEvento

Disparamos el evento llamando a trigger desde el objeto que emite el evento:

trigger admite un número variable de argumentos. El primero es el nombre del evento a generar y el resto son los parámetros que se le pasarán al handler.

Ya hemos comentado que Backbone necesita que cada modelo tenga un id para poder identificarlo de manera única en el servidor. Si los objetos que devuelve nuestro API siguen la misma convención no tendremos que hacer nada en especial, pero hay algunas plataformas en las que el identificador no es el atributo id sino que se usa otro nombre. Por ejemplo como veréis en la asignatura de NoSQL, en MongoDB se usa el campo _id como identificador. En ese caso lo único que tendremos que hacer es asignar a la propiedad idAttribute del modelo el nombre del atributo que actúa de identificador.

Si el API devuelve un identificador más complejo (por ejemplo formado por dos atributos, o por parte de un atributo) no podemos establecer esta simple correspondencia. En ese caso lo que podemos hacer es sobreescribir el método url(), que debería devolver la URL del modelo, y que por defecto se obtiene como la URL "base" más el id. La URL base de un modelo se define bien como la url de la colección, si el modelo está incluido en una, bien como el valor de la propiedad urlRoot del modelo (que por defecto es vacío y tenemos que especificar si lo deseamos).

Por ejemplo supongamos que un API usara como identificador el atributo id pero luego la URL de un objeto se formara concatenando la URL base + el id + el sufijo /data (de acuerdo, es un ejemplo un poco raro pero podría ser). En el modelo haríamos algo como:

Por defecto Backbone toma la respuesta del servidor como un objeto JSON y asigna sus propiedades "de primer nivel" como atributos del modelo. Esto es porque la implementación por defecto de la función parse(), que es la que se usa para analizar la respuesta del servidor, simplemente devuelve tal cual el cuerpo de la respuesta:

Sin embargo hay muchos APIs que en los listados "envuelven" los resultados en un objeto que actúa como wrapper y los resultados en sí están dentro de él. Esto es típico de las operaciones de búsqueda o listados, por ejemplo al buscar repositorios en el API de GitHub. En este caso lo que haría Backbone es guardar el wrapper dentro del modelo, que no es lo que queremos. Tendremos pues que sobreescribir parse(). En el ejemplo de búsqueda en GitHub, el wrapper tiene una propiedad items donde están los resultados como un array. De modo que si tuvieramos una colección Repositorios tendríamos que hacer algo como:

Todos los APIs en los que podamos modificar información van a requerir que nos autentifiquemos de una forma u otra. Incluso muchos APIs en los que solo se puede leer información requieren del uso de una api key para identificar al "usuario" y evitar que un mismo usuario haga un número de peticiones excesivo. Por defecto Backbone no incorpora ningún mecanismo de autentificación, así que tendremos que añadirlo de algún modo.

Para los APIs que no sean del todo REST tendremos que sobreescribir el método sync(), que es el "corazón" de la comunicación con el servidor. Evidentemente esto va a ser mucho más complicado que todas las configuraciones que hemos visto hasta ahora. No obstante, hay ciertos casos de uso típicos para los que se han desarrollado plugins de terceros.

Por ejemplo, hay APIs de terceros que permiten sincronizar los datos con el LocalStorage del navegador en lugar de con un servidor remoto. Esto es muy interesante para aplicaciones que puedan trabajar offline por ejemplo agendas, listas de tareas, notas, …​ el más conocido es Backbone localStorage Adapter, que nos permite sincronizar una colección automáticamente con el LocalStorage, sin más que definir una propiedad localStorage

Incluso hay plugins, como DualStorage que permiten trabajar con el API REST remoto por defecto y cambiar de manera transparente al LocalStorage cuando se detecta que estamos offline.

Este ejercicio debes entregarlo en una carpeta llamada star_wars.

Vamos a probar cómo comunicarnos mediante Backbone con el API de Star Wars que ya has usado en otros ejercicios. Como sabes, el API solo permite hacer peticiones GET, por lo que vamos a centrarnos en listar y filtrar datos.

Tendremos que adaptar la persistencia REST que implementa Backbone por defecto a las peculiaridades de este API.

Este ejercicio debes entregarlo en una carpeta llamada alquiler_coches. Seguiremos trabajando sobre la misma carpeta en más sesiones.

Vamos a ir creando en sucesivas sesiones una aplicación para una compañía de alquiler de coches. En concreto vamos a ir desarrollando solo la parte de administración en la que se podrá listar los vehículos, darlos de alta/baja, editarlos,…​

Para no tener que programarnos el backend desde cero, ya que no es el objetivo de la asignatura, usaremos una plataforma de tipo BaaS (Backend As A Service), con la que podemos crear un backend de tipo REST de manera sencilla.

Todas las vistas tienen una propiedad predefinida llamada el, que representa el nodo del DOM que es la raíz del HTML de la vista. La vista genera HTML y lo lo coloca dentro de el (luego veremos cómo se hace esto habitualmente). Después nosotros somos los responsables de tomar esa propiedad el e insertarla en el lugar que queramos del DOM.

Por defecto, el es una etiqueta <div>. Si ejecutamos el código anterior veremos que por tanto se le añade un <div> a la página con el mensaje que hemos puesto.

Podemos darle el valor que queramos a el si no nos interesa el valor por defecto. De hecho podemos configurarla totalmente a nuestra medida con una serie de atributos

Al ejecutar el código anterior al cuerpo de la página se le añadirá un HTML como este

Hasta ahora hemos observado que la vista genera el HTML pero nosotros somos los responsables de incluirlo en la página. Hay otra posibilidad: darle al el como valor el id de algún nodo de la página. Así, al poner

El contenido ya aparecería insertado en el DOM de la página actual.

Como ya hemos dicho en otras ocasiones Backbone facilita el trabajo con jQuery. En este caso tiene predefinida una propiedad $el que representa lo mismo que el pero es un objeto jQuery en lugar de un nodo DOM estándar, por lo que podemos usar el API de jQuery si nos resulta más cómodo:

Ya hemos visto que la inclusión de la vista en el DOM se hace manualmente o bien poniendo como valor de el un nodo ya existente en el DOM. Para eliminar la vista del DOM se usa el método remove().

Hasta ahora hemos estado manipulando directamente el el para incluir contenido en la vista, pero esta forma de trabajar no es muy "limpia" que digamos. La convención habitual en Backbone es sobreescribir el método render(), que debería rellenar el contenido del el, generando el HTML de la vista. Y decimos convención ya que si examinamos los fuentes de Backbone veremos que el resto del código no llama a render() en ningún momento, y la implementación por defecto no hace nada (salvo devolver this, hablaremos ahora sobre esto).

Así, los ejemplos que hemos puesto hasta ahora quedarían mejor como:

Nótese que:

Las vistas que solo muestran contenido estático no son muy divertidas. Normalmente nos interesará que sean interactivas y respondan a eventos. La gestión de eventos también es responsabilidad de la vista, y se define en un objeto en formato JSON llamado events. Las propiedades son nombres de eventos (y de manera opcional un selector CSS indicando el nodo o nodos DOM al que afecta). Los valores son cadenas con el nombre del manejador correspondiente. Por ejemplo:

El selector CSS se busca únicamente dentro de la vista. En el ejemplo, si en la página (fuera de la vista) hubiera otras etiquetas con class="boton" no se verían afectadas por esta gestión de eventos. Esto es interesante porque hace a las vistas modulares y autocontenidas.

Podemos modificar dinámicamente la gestión de eventos llamando al método delegateEvents() y pasándole un objeto JSON con el nuevo valor a darle a events.

Hasta ahora hemos hablado de vistas, pero ¿qué relación mantienen con los modelos?. La idea es que cada vista normalmente tiene una referencia al modelo o colección que representa. Hasta ahora en los ejemplos que hemos visto no había modelo, pero esto en realidad no es lo habitual. Es más habitual algo como:

Código en JSbin.com

Con la propiedad collection podemos pasarle una colección a la vista.

El data binding es la vinculación entre ciertos componentes del modelo y de la vista, de modo que cuando cambia uno de ellos el otro se actualiza automáticamente. La vinculación puede ser solo en un sentido o en ambos. La de un solo sentido suele funcionar del modelo hacia la vista (si cambia el primero se actualiza la segunda) pero no al contrario. La bidireccional se suele usar en formularios, cuando estamos editando los datos del modelo.

Backbone no tiene data binding propiamente dicho, ya que el único momento en que están vinculados los datos del modelo y la vista es justo cuando se hace un render de la vista.

En Backbone es habitual vincular el modelo con la vista usando eventos. Las vistas pueden suscribirse a eventos del modelo. Al recibir el evento la vista debe hacer un rendering parcial, modificando únicamente la parte que no varía. Backbone no va a ayudarnos en esto último, tendremos que hacerlo nosotros mismos. Por ejemplo, supongamos que tenemos un widget que monitoriza el estado de un servidor y debe actualizar la vista automáticamente cuando cambie éste:

Si ahora cambiara el valor de la propiedad `estado `del modelo el estado se actualizaría sin tener que redibujar totalmente la vista. Podemos probarlo de manera sencilla tecleando en la consola del navegador:

Aunque ya hemos dicho que Backbone tal cual no tiene binding automático, existen varios plugins que proporcionan esta funcionalidad. Uno de los más conocidos es stickit, que vamos a ver aquí brevemente. Hay otros como por ejemplo backbone UI, que además incluye widgets o backbone baguette.

Veamos un ejemplo de cómo conseguir data binding automático desde el modelo hacia la vista. Hasta cierto punto la idea es similar a lo que hacíamos antes con los eventos: en la vista debemos tener ciertas secciones del HTML marcadas indicando que ahí van los datos que queremos vincular. La diferencia es que stickit los actualizará automáticamente por nosotros sin necesidad de gestionar los eventos ni implementar el rendering parcial.

Si ahora modificamos el modelo, la vista se actualizará automáticamente, por ejemplo podemos ejecutar en la consola Javascript la siguiente línea para ver cómo se actualiza la vista

Stickit soporta también el data binding bidireccional. Lo único que hay que hacer en el ejemplo anterior es cambiar las etiquetas <b> y <em> por campos de formulario de tipo texto, por ejemplo. Podremos observar que cuando se modifica el contenido del campo el atributo del modelo refleja el cambio.

Los ejemplos anteriores son con la configuración de la librería por defecto. Podemos forzar el tipo de vinculación que queramos (por ejemplo solo de una dirección en campos de formulario), configurar los eventos de vista que disparan los cambios en el modelo, incluir nuestros propios handlers,…​. La librería es bastante completa y flexible, aquí solo queremos mostrar una pequeña introducción a cómo funcionaría el data binding integrado con Backbone.

La idea básica es que una plantilla más un "objeto" formado por pares propiedad-valor va a generar el resultado final. En la plantilla se toma todo como literal excepto las partes entre dobles llaves ({{ }}), que representan variables o indican secciones especiales, como ahora veremos.

La sintaxis del lenguaje se puede consultar en el manual online. Vamos a ver un ejemplo que incluye todas las características típicas que vamos a necesitar aquí:

Estando en el lado del cliente, y usando HTML+JS veamos dónde almacenaríamos la plantilla, de dónde sacaríamos los datos y cómo uniríamos ambos elementos para obtener el resultado final.

Como Backbone en sí no prevé ni aporta nada con respecto a las plantillas, en realidad no hay una "forma correcta" de usar plantillas en el código Backbone, pero hay algunos fragmentos de código típicos que se repiten más o menos literalmente en muchas aplicaciones Backbone. Vamos a ver un par de casos de uso.

Para crear un router debemos extender la clase Backbone.Router. Dicha clase tiene una propiedad básica, routes, que es un conjunto de pares clave/valor, al estilo del events de las vistas. La clave es la ruta, y el valor el nombre de la función a ejecutar. Por ejemplo:

Suponiendo que la página que contiene el código anterior fuera index.html si en la barra de direcciones del navegador cambiamos la URL por index.html#hola, veremos aparecer el mensaje en la consola Javascript.

Nótese que en las rutas tal y como las ve el usuario, lo que cambia entre una ruta y otra es el hash fragment, es decir, la parte que va detrás del símbolo #. Para usar URLs convencionales habría que configurar la parte del servidor, como veremos luego.

Podemos definir partes variables en una ruta poniéndoles un nombre precedido del símbolo ':'. La función Javascript asociada a la ruta recibirá tantos parámetros JS como partes variables tenga la ruta.

Podemos poner varias partes variables en una ruta. La siguiente ruta encajaría con #hola/Pepe/Pérez.

Para especificar alguna parte como opcional la pondríamos entre paréntesis:

En el ejemplo anterior, la ruta encajaría tanto con #hola/Pepe/Pérez, como simplemente con #hola/Pepe. En este último caso, el parámetro Javascript asociado a los apellidos sería null.

Las partes variables de las rutas se tratan al estilo de las expresiones regulares. Por ejemplo podemos poner una parte fija mezclada con la variable, o usar el símbolo * para indicar cualquier secuencia de caracteres. Esto último es útil si queremos recoger un path completo, o sea una cadena que contenga también el carácter /.

La ruta #hola/Pepito encajaría con la primera expresión, por lo que la variable adquiriría el valor ito. Si fuéramos por ejemplo a #adios/mas/cosas/por/aqui, el parámetro JS asociado a la variable var tomaría el valor mas/cosas/por/aqui

Es conveniente definir un par de rutas por defecto en cualquier aplicación: la ruta vacía '', que se usa cuando el hash fragment está vacío, y *default, que se usará con la URL actual si esta no encaja con ninguna de las definidas en el router.

En cualquier momento podemos navegar a una URL determinada con el método navigate de la clase Router:

Esta operación añadirá la nueva URL al historial del navegador. No obstante, navegar a una URL por defecto no disparará la función asociada a la ruta correspondiente, salvo que lo especifiquemos con {trigger:true}

Al contrario, podemos detectar en nuestro código que se ha disparado una ruta determinada respondiendo a los eventos con prefijo route:. El nombre completo del evento se obtiene añadiendo a este prefijo el nombre de la función asociada. Por ejemplo:

Usar una URL con hash fragments simplifica la gestión para Backbone, ya que en realidad no estamos cambiando de página. Pero puede parecer "algo rara" para el usuario. Podemos configurar Backbone para usar URLs convencionales, pero hay que solucionar dos pequeños problemas:

Implementa un formulario que sea una vista de Backbone y que permita dar de alta un nuevo vehículo. - El modelo asociado a la vista será una instancia de Coche - Puedes crear una plantilla Mustache para la vista, pero ten en cuenta que será totalmente estática (solo HTML), ya que no sirve para mostrar datos, sino para introducirlos. - La vista debería escuchar el evento sync sobre el modelo, que indicará que el alta en el servidor se ha producido correctamente. En ese caso se debería mostrar un mensaje indicándolo (muéstralo en algún lugar del HTML, y pon algún botón o enlace para eliminar luego el mensaje. Recuerda que es más sencillo con jQuery). Escucha también el evento error que indica un error, y muestra también un mensaje adecuado en el HTML.

Implementa una vista de Backbone que muestre un listado con todos los coches. El listado será totalmente estático salvo por el hecho de que cuando se inserte un nuevo coche en el formulario de alta debe aparecer también aquí. Para ello:

Cada subvista será una instancia de la clase VistaContacto, y será responsable de renderizarse "ella misma" y procesar sus eventos. El código Javascript sería algo como lo que sigue:

La plantilla Mustache asociada sería la siguiente:

Esta vista no tiene nada sustancialmente diferente de las que hemos usado hasta el momento. La clave, pues, está en la vista global.

La plantilla Mustache asociada a la vista no es excesivamente interesante, únicamente contiene la parte "externa" a la lista de contactos en sí: un título y un formulario para dar de alta un nuevo contacto:

La parte realmente interesante es el código del método render(). Además de renderizar la plantilla asociada, debe ir creando una subvista por cada elemento del listado, haciendo el render() de dicha subvista y añadiendo el resultado al HTML propio.

El código anterior tiene un pequeño problema. Ya hemos visto alguna vez que cuando desde una función de una clase de Backbone llamamos a otra, this no tiene como valor el objeto actual, sino el objeto global (window). Para resolverlo, en la inicialización de la vista enlazamos (bind) la función renderContacto con la vista:

En el código Backbone típico se suele usar el _.bindAll de Underscore para vincular una función con un objeto, más que nada porque es cómodo y nos asegura el soporte en navegadores antiguos. También podríamos haber usado el bind de Javascript estándar:

Marionette es una extensión de Backbone. Le añade una serie de funcionalidades interesantes para el trabajo cotidiano con el framework. Por ejemplo ya hemos visto que Backbone "aporta poco" en cuanto a la gestión de las vistas, prácticamente lo tenemos que hacer todo nosotros. Marionette automatiza mucho más el trabajo con las vistas, implementando un render que a diferencia del de Backbone sí hace algo por defecto: serializa el modelo en JSON, aplica la plantilla, …​. Además incluye clases pensadas para representar explícitamente jerarquías de vistas. Enseguida veremos una pequeña introducción a estas funcionalidades. Por otro lado Marionette también incluye funcionalidades no relativas a vistas como por ejemplo la definición de módulos, que nos permiten organizar mejor nuestro código, o la ampliación del sistema de eventos de Backbone.

Marionette tiene dos tipos de vista pensados para resolver nuestro problema. La clase ItemView nos sirve para representar un único modelo, mientras que CollectionView representa una colección. Un CollectionView tendrá un conjunto de ItemView como vistas "hijas".

Continuando con el ejemplo del apartado anterior, para representar cada contacto usaríamos un ItemView. Marionette implementa un render por defecto que:

Una vez hemos definido la vista para un item de la lista, ya podemos definir la vista "global" para la lista de elementos. En Marionette para esto se usa un CollectionView, que incluirá como vistas "hijas" varias ItemView. Siguiendo con nuestro ejemplo, para presentar la lista de contactos: (mostramos solo lo que hay que añadir al código anterior)

Como vemos, lo único que necesitamos para definir la vista asociada a la colección es especificar qué clase va a actuar como vista para cada elemento. En nuestro caso es la clase VistaContacto. El render de la CollectionView creará automáticamente una VistaContacto por cada elemento de la colección si es necesario, llamará a su render y concatenará todos los HTML resultantes, es decir, lo mismo que antes teníamos que hacer de modo manual.

Nótese que una CollectionView no tiene HTML "propio", su HTML es el formado por la concatenación del de sus vistas hijas. Si queremos que la vista "madre" contenga información propia deberíamos usar una CompositeView, que es como una CollectionView pero se le puede asociar también un model y una template.

Marionette hace un re-render automático cada vez que se modifica la colección asociada a una CollectionView. Si nos vamos a la consola Javascript y tecleamos

veremos cómo se redibuja automáticamente la vista y aparece el nuevo contacto. Es decir, el CollectionView implementa un data binding unidireccional, del modelo hacia la vista.

En Marionette podemos definir una vista que sea una composición de otras extendiendo la clase LayoutView. Esta clase tiene una propiedad regions en la que daremos una lista de las secciones (o como las llama Marionette, regiones) que componen la vista. Para cada sección especificamos un nombre simbólico y un selector que identifique la región dentro de la página.

Una vez creada la instancia de LayoutView podemos acceder a sus regiones por identificador y mostrar una vista en cada una de ellas con show. Podemos eliminar la vista con empty.

Para anidar vistas dentro de otras podemos hacer que la vista mostrada en una región sea a su vez una LayoutView. Supongamos que ahora queremos que la región principal se divida a su vez en un título y en otra subregión para el texto del cuerpo principal.

Vamos a usar plantillas para modularizar las regiones:

Ahora el código sería algo como lo que sigue:

Para este ejercicio haz una copia de la carpeta alquiler_coches que ya tenías, y llámala alquiler_coches_subvistas.

Usando solamente Backbone, sin Marionette, cambia el listado "estático" que ya tenías y que usaba una sola vista por un listado dinámico en el que se puedan eliminar coches, y cada coche se muestre con una subvista. Cada coche debería aparecer con un botón o enlace "eliminar" que:

Para este ejercicio deberás coger tu código JS (solo los modelos, no las vistas) y juntarlo con la plantilla de aplicación Marionette que tienes en las plantillas de la asignatura. Entrega el ejercicio en una carpeta alquiler_coches_marionette.

Usando Marionette implementar las mismas funcionalidades del ejercicio anterior. Ten en cuenta que como la vista global debe mostrar el formulario de alta no te valdrá con una CollectionView sino que debes usar una CompositeView que sí puede tener una template asociada.

La plantilla usa espacios de nombres y módulos al estilo "patrón módulo". Tienes ya implementado un modelo (Comic) y una colección (Comics). Esta última ya implementa la comunicación con el API de Marvel, para buscar comics por título. Puedes ir a la consola Javascript y teclear:

Pasados unos segundos si examinas la variable "lista" debería contener un conjunto de modelos Comic cada uno con los datos de un comic. Aunque el API está paginado y podríamos irle solicitando resultados de 20 en 20 como mucho, para simplificar la aplicación nos "conformaremos" con listar solo los 20 primeros (podría haber menos), no es necesario implementar paginado.

Dividiremos la pantalla en tres secciones, representadas con tres div en el index.html

Estas tres secciones estarán controladas por una "vista global" de Marionette, que gestionará a las vistas "hijas". Pero vamos por partes. Primero vamos a ver y probar las vistas básicas, para ver un solo comic y un listado de comics.

La clase ya la tienes definida, ya que en Marionette solo hace falta referenciar dónde está la template, el render lo implementa Marionette. Eso sí, tendrás que definir tú la template usando Mustache en el script id="VistaComicTmpl", que ahora está vacío. Muestra al menos el title y la description del comic. Además muestra una imagen a tamaño reducido. Las imágenes se obtienen concatenando:

Para comprobar que funciona, desde la consola de Javascript lanza una búsqueda de comics como has hecho antes, asegúrate de que ya ha respondido el servidor (la colección no está vacía) y luego crea una vista pasándole una posición de la colección y renderízala en la página. Algo como:

Deberían aparecer en pantalla los datos del comic.

Esta vista es del tipo CollectionView, lo que quiere decir que no tiene HTML propio, su HTML es solo una concatenación de los HTML de las vistas "hijas" (del tipo VistaComic). Por tanto no tiene template.

No obstante para asegurarte de que todo es correcto puedes hacer una prueba similar a la que has hecho para VistaComic, pero ahora para mostrar un listado completo

Vale, ya estamos seguros de que al menos las piezas básicas con los datos de los comics funcionan. Vamos con las piezas de "alto nivel".

Tienes el esqueleto en js/views/VistaGlobal.js. Es una vista de tipo LayoutView, o sea compuesta. El esqueleto únicamente especifica las secciones que controla (con el objeto regions, que establece la correspondencia entre nombres simbólicos de secciones y nodos del HTML).

Fijate que en el archivo js/main.js, cuando se carga el documento (evento $(document).ready) se crea una instancia de la vista global y se muestra una vista con el formulario de búsqueda en la sección formBusqueda. Pero por ahora el formulario no hace nada. Vamos a solucionar esto enseguida.

Esta vista debe ser la encargada de mostrar el formulario, disparar la búsqueda y obtener los resultados, que le pasará a la vista global. Por ahora solo muestra el formulario.

Está representada en el código por:

Para que esta vista haga su trabajo completo, tienes que:

Ahora para que la vista global escuche el evento completed:search y en respuesta muestre una vista con la lista de comics encontrados puedes añadirle lo siguiente:

Nuestro objetivo ahora es que cuando pulsemos en "ver detalles" de un comic se sustituya la lista de comics por los datos detallados del comic elegido. Luego al "cerrar detalles" aparecerá de nuevo la lista.

Ahora tendremos que modificar el código de la vista global, que es la que tiene que recibir el evento show:details. En respuesta a este evento, sustituiremos la vista con la lista de comics por una vista para mostrar los detalles (clase VistaDetallesComic). Pero como cuando cerremos los detalles queremos volver a la lista, le diremos a Marionette que no destruya la vista de lista, y la guardaremos en el objeto vista global.

Cuidado, si quieres probar esto, lo primero que debes hacer es rellenar la template asociada a la VistaDetallesComic, para que aparezca información en pantalla. Coloca los datos que quieras, y una imagen a mayor tamaño que la que aparece en el listado.

En la template asociada a la clase VistaDetallesComic tiene que haber un botón o enlace "Cerrar". Ahora es similar al proceso seguido para mostrar los detalles. En la clase VistaDetallesComic

Finalmente, modifica el código de la vista global para que reciba el evento hide:details (o como lo hayas llamado) y vuelva a poner "en su sitio" la lista de comics.

Usar como componente de nuestra aplicación directamente uno de los predefinidos en React puede ser divertido (ejem) pero tiene un alcance limitado, ya que la posible personalización se limita a especificar los atributos de la etiqueta HTML. Es mucho más útil poder controlar también su comportamiento, y para eso necesitaremos crear nuestra propia clase de componente.

Como vemos la función render del componente es similar en espíritu a la del mismo nombre de Backbone. Con la diferencia, eso sí, de que con React no manipulamos directamente el DOM de la página, sino que trabajamos con una capa de abstracción por encima.