[Auges] Vídeo y materiales del webcast sobre SignalR. ¡uau!

SignalR, ¡uau!Como sabéis, el pasado jueves tuve el placer de hablar sobre SignalR en un Webcast organizado por Auges, el grupo de usuarios de ASP.NET de España.

Ante todo, agradeceros a los asistentes que decidierais pasar esa tarde con nosotros. Una audiencia bastante numerosa para estos tiempos que corren, y un gran número de amigos que os quedasteis hasta el final las dos horas que estuvimos hablando sobre esta pequeña maravilla. Incluso hubo quien comentó que se le habían hecho cortas 😉 Muchas gracias a todos.

La charla la empezamos hablando sobre HTTP, y las limitaciones de éste en escenarios en los que el tiempo real era un requisito imprescindible. Sobrevolamos soluciones tradicionales como el polling, presentamos el concepto Push, revisamos los estándares que están en la cocina por parte de IETF y W3C, y explicamos técnicas que podemos usar hoy en día para implementar aplicaciones en las que el servidor debe tomar la iniciativa en la comunicación con el cliente.

Seguidamente, tras una breve presentación de SignalR, entramos de lleno en terreno práctico, implementamos desde cero varias demostraciones de las capacidades del framework y revisamos otro buen número de ellas, mediante las cuales intenté mostrar las bases de la programación con esta joya: conexiones persistentes, hubs, acceso a clientes desde procesos externos, e incluso llegamos a implementar un cliente con Windows Forms.

El cliente siempre manda, incluso en HTTPUn total de ocho demos que espero que hayan conseguido transmitir mi entusiasmo por este framework, y las posibilidades que brinda a la hora de dotar a nuestros sistemas de la espectacularidad que sólo los sistemas colaborativos, multiusuarios y en tiempo real son capaces de proporcionar.

Bueno, a lo que iba en el post… el caso es que ya está disponible el vídeo y los materiales de la charla:

¡Hasta la próxima!

Publicado en Variable not found.

[Auges] Webcast sobre SignalR: ¡uau!

AUGES: ASP.NET User Group EspañaSimplemente informaros de que el próximo jueves 24 de mayo a las 19:00h (hora peninsular española), participaré en una charla con AUGES sobre SignalR, esa pequeña maravilla de la que ya os he hablado por aquí en varias ocasiones, una ayuda imprescindible a la hora de crear sistemas interactivos, multiusuario y en tiempo real para la web.

El “cartel” oficial del evento es el siguiente:

SIGNALR: APLICACIONES MULTIUSUARIO, ASÍNCRONAS, Y EN TIEMPO REAL. ¡UAU!

¿Te has preguntado alguna vez cómo es posible que en una aplicación web como Google Docs varios usuarios puedan interactuar de forma simultánea? ¿Te interesa la tecnología que usan los grandes como Facebook o Twitter para informarte en tiempo real de que algo ha ocurrido? ¿Piensas que crear un chat basado puramente en ASP.NET no es tarea sencilla? ¿Te gustaría que el servidor pudiera enviar información a los clientes en cualquier momento, sin esperar a que éstos soliciten una página o recurso?

imageSi has respondido que sí a alguna de estas preguntas, SignalR te entusiasmará. Es un marco de trabajo open source que permite saltarse las barreras impuestas por HTTP y su clásico modelo de petición/respuesta para conseguir aplicaciones más interactivas, dinámicas y colaborativas, en las que el servidor toma la iniciativa.

No te pierdas este evento y aprende a poner un factor “¡uau!” en tus desarrollos.

Os recuerdo que se trata de un Webcast, o sea, que podéis asistir a este evento desde vuestro sillón favorito, acompañados de una buena cerveza y un saco de palomitas. Y por supuesto, es totalmente gratuito.

Lo único que debéis hacer para poder asistir es registraros:

No me faltéis, que paso lista 😉

Más características de Razor con MVC 4 y Web Pages 2

 

ASP.NET MVCHace poco comentamos algunos detalles sobre las novedades que incluirá Razor 2, la versión que será incluida en ASP.NET MVC 4, y siguen apareciendo más novedades destinadas a mejorar la calidad del código y nuestra productividad al crear las vistas MVC o Web Pages.

En este post vamos a ver otros comportamientos de Razor en distintos escenarios.

Cerrado implícito de etiquetas

La versión anterior de Razor daba problemas con un código como el siguiente:

@if(passwordNeeded) 
{
    <input type="password" name="password">
}

La página no compila y genera una excepción en tiempo de ejecución debido a que la etiqueta <input> no se ha cerrado explícitamente usando la sintaxis de autocierre <input … /> o bien mediante el cierre de toda la vida </input>.

En Razor 2 se ha creado un parser mucho más complejo, en el que, entre otras cosas, se tienen en cuenta los llamados void elements por la W3C, que son aquellas etiquetas que en ningún caso pueden tener contenido: area, base, br, col, command, embed, hr, img, input, keygen, link, meta, param, source, track y wbr.

Cuando Razor se encuentra con alguna de estos elementos, si la etiqueta inmediatamente posterior no es la que lo cierra, asumirá que éste está cerrado de forma automática, por lo que el código mostrado anteriormente será válido.

Rutas con partes variables

Ya vimos que el nuevo Razor será capaz de interpretar el gusanillo (~) directamente, de forma que ya no será necesario utilizar esos verbosos @Url.Content() a la hora de referenciar recursos como scripts, imágenes u hojas de estilo:

<script type="text/javascript" src="~/Scripts/jquery-1.7.1.js"></script>

Pues bien, el caso es que las rutas especificadas de esta forma no tienen por qué ser una cadena constante, sino que pueden incluir variables, como en el siguiente ejemplo:

@{
    var scriptsFolder = "scripts";
}
<script type="text/javascript" src="~/@scriptsFolder/jquery-1.7.1.js"></script>

Lo que hace Razor en este caso es interpretar y obtener la dirección teniendo en cuenta desde el gusanillo hasta la primera barra, insertar el contenido de la variable, y seguirlo del resto de la cadena constante. El equivalente con la versión anterior (MVC3) de Razor sería algo así:

<script type="text/javascript" src="@Url.Content("~/")@scriptsFolder/jquery-1.7.1.js"></script>

Atributos condicionales con varios valores

También vimos en el post anterior que cuando Razor 2 tenía que generar el contenido de un atributo cuyo valor era null, no generaba ni si quiera el nombre del atributo, lo que al final se traducía en un código más sencillo y compacto:

@{
    string nullValue = null;
    string stringValue = "hello";
}
<span class="@nullValue" id="@stringValue"></span>
 
GENERA:
<span id="hello"></span>

Pues bien, este comportamiento funciona incluso cuando en el atributo aparecen valores procedentes de más de una expresión. Aquellas cuyos valores sean nulos no serán generadas (ni siquiera el espacio en blanco que la separa de las demás), y si todas ellas son nulas el atributo no será generado:

@{
    string nullValue = null;
    string stringValue = "hello";
    string otherNull = null;
}
<span class="@nullValue @stringValue @otherNull"></span>
<span class="@nullValue @otherNull"></span>
 
GENERA:
<span class="hello"></span>
<span></span>

Tratamiento de atributos booleanos

Otro detalle muy interesante lo tenemos al escribir valores para atributos booleanos, como disabled, checked o similares. Lo habitual en la versión 1 de Razor para generar apropiadamente estos atributos era hacer algo así:

@{
    string disabled = "";
    if(condition)
    {
        disabled = "disabled='disabled'";
    }
}
<button @Html.Raw(disabled)>Click!</button>

GENERA (dependiendo del valor de condition):
<button >Click!</button>                
<button disabled="disabled">Click!</button>                

La nueva versión de Razor permite ser mucho más directo y explícito en estos casos. Introducimos directamente el booleano como valor del atributo; si es true, el valor del atributo será su mismo nombre, mientras que si es false el atributo no será renderizado:

<button disabled="@condition">Click!</button>

GENERA (dependiendo del valor de condition):
<button>Click!</button>                
<button disabled="disabled">Click!</button>                

Y eso es todo de momento. Seguiremos atentos a las novedades e iremos contándolas por aquí, como de costumbre 🙂

Publicado en Variable not found.

Knockout (I): pongamos orden en el lado cliente

La programación web tradicional, basada en el modelo de petición-respuesta de página completa, no requería demasiado código en cliente más allá que el necesario para realizar validaciones y lógica de presentación simple: ¿para qué complicarnos en cliente si podíamos hacerlo todo en servidor?

De hecho, durante la era Webforms, la célebre pareja formada por viewstate y postback llevaban a servidor prácticamente la totalidad de la lógica de presentación mediante el artificio de la programación por eventos, y el código cliente necesario para que todo funcionara era generado de forma automática por ASP.NET en su mayor parte.
Modelo monolítico tradicional
Esta lógica de presentación podía estar (y de hecho muchas veces estaba) mezclada con tareas de control e incluso con lógica de negocio, y los desarrolladores empezamos a hacernos conscientes de los monstruos que estábamos creando. Esta preocupación provocó la aparición de soluciones que pretendían estructurar los sistemas de forma razonable, separando las responsabilidades y, en definitiva, poniendo un poco de orden en ese caos.

Arquitectura MVCImplementaciones del patrón MVP, MVVM, o incluso el framework ASP.NET MVC son ejemplos del resultado de esta inquietud. Aunque con matices, todos estos enfoques permiten separar la lógica de negocio, control y presentación en “capas” relativamente independientes.

Sin embargo, la programación web está cambiando, o mejor dicho, lo ha hecho ya ;-). El pesado modelo tradicional petición-respuesta de página completa está siendo relegado en favor de interfaces más ágiles y dinámicos que se basan en el aprovechamiento de la capacidad del cliente para realizar una gran cantidad de tareas a través del uso intensivo de scripting y Ajax.

Arquitectura MVC con MVVM en cliente¿Y a dónde nos lleva este cambio de paradigma? Pues, entre otras cosas, a que el volumen de código script en nuestras páginas ha crecido de forma desmesurada y, debido a ello, se incremente exponencialmente la complejidad en el lado cliente.

Pero como ocurrió en el lado servidor, enseguida han comenzado a aparecer soluciones que nos ayudan a estructurar el código cliente usando patrones ya usados en el otro lado, como MVVM, MVP, o MVC.

En esta serie de posts estudiaremos el uso de Knockout.js, una biblioteca javascript que facilita la creación de interfaces ricas y dinámicas basándose en el patrón MVVM.

¿El patrón MVVM?

MVVM, Model-View-ViewModel, es un patrón de diseño de la capa presentación definido en 2005 por John Gossman, de Microsoft, adaptando el Presentation Model de Fowler a las particularidades de las tecnologías en las que estaba trabajando (WPF).

De forma muy similar a MVC, esta arquitectura divide los componentes en tres grupos.

El Modelo básicamente contiene datos de forma totalmente independiente de cómo vayan a ser presentados en el UI, y casi siempre sin comportamiento. Por ejemplo, podrían ser clases o entidades planas del dominio de la aplicación.

La Vista contiene los elementos del interfaz necesarios para comunicarse con el usuario, como etiquetas, cuadros de texto, botones, desplegables, etc. Por ir centrándonos en el contexto que nos interesa, la vista es puro lenguaje de marcado (HTML, XAML…), y no contiene lógica de ningún tipo. Tanto los datos que necesita para componer la UI como el comportamiento de los elementos en pantalla los toma del View-Model usando mecanismos como el binding (después entraremos en esto).

El Modelo-Vista, o View-Model, es una abstracción sobre la Vista que contiene tanto los datos como el comportamiento de ésta, pero sin conocer los detalles sobre cómo está implementada. En cierto sentido podríamos considerar que es similar a un controlador en MVC. Es el encargado de transformar y formatear la información del Modelo para que pueda ser representada en la vista y, de la misma forma, se encarga de recibir y gestionar las acciones del usuario y actualizar el Modelo cuando es necesario.

Para los desarrolladores ASP.NET MVC, el concepto podría asimilarse con una clase ViewModel, a la que además se han incorporado métodos para gestionar los eventos desencadenados por el usuario durante la interacción con la aplicación.

Pero sin duda, una de las piezas clave en este patrón es el binding, o enlace, tanto de datos como de acciones entre las capas View y View-Model.

En la práctica, este mecanismo permite indicar sobre la Vista, de forma declarativa, qué propiedades del Modelo-Vista se corresponden con cada uno de los componentes del interfaz de usuario, estableciendo un vínculo uni o bidireccional sobre ambos.

Por ejemplo, podríamos tener un cuadro de texto en la Vista vinculado a una propiedad llamada “Nombre” en el View-Model, de forma que cuando el valor de la propiedad cambiara automáticamente se reflejaría en el valor del cuadro de texto, y cuando el usuario modificara el cuadro de texto el valor de la propiedad también sería actualizado de forma automática. Con esto conseguimos mantener Vista y View-Model perfectamente sincronizados sin ningún tipo de esfuerzo por parte del desarrollador.

Y al igual que es posible enlazar elementos del interfaz con propiedades del View-Model, también podemos enlazar de forma declarativa acciones o eventos del usuario a comandos, o métodos definidos sobre el mismo View-Model. Por tanto, y valga como ejemplo, el tratamiento del clic sobre un botón lo implementaríamos en un método del Modelo-Vista, mientras que en la Vista lo único que haríamos es bindear (enlazar) el evento click del botón a dicho método.

¿Qué es Knockout?

Knockout.jsKnockout.js es una biblioteca de scripts desarrollada por Steve Sanderson que implementa el patrón MVVM con el objetivo de facilitarnos la creación de interfaces de usuario de edición y visualización de datos, usando una estructura simple, limpia y mantenible en nuestro código.

Es bastante compacta (~40Kb sin comprimir), no depende de ninguna otra biblioteca para funcionar y funciona con todos los navegadores razonablemente actualizados. Es open source, se distribuye bajo licencia MIT y está muy bien documentada en su sitio web (incluyendo unos tutoriales interactivos bastante buenos).

Sus características principales, que conforman las ventajas que nos aporta a los desarrolladores, son:

  • Sistema de bindings declarativos, expresados sobre los propios tags HTML usando atributos data-bind, que permiten crear un vínculo uni o bidireccional entre elementos del interfaz de usuario y propiedades o acciones del View-Model, que se actualizarán de forma automática ante cambios.
  • Seguimiento de dependencias, capaz de detectar los cambios realizados tanto en la Vista como en el Modelo-Vista y propagarlos hacia todos los objetos o elementos dependientes.
  • Por supuesto, el interfaz de usuario se actualiza automáticamente para reflejar los cambios en el View-Model.
  • Incluye un sistema de plantillas que facilita la creación porciones de vistas reutilizables.

Y por si lo que trae de serie Knockout se nos queda corto, podemos extenderlo muy fácilmente.

¿En qué tipo de proyectos puedo utilizarlo?

En todos: PHP, Python, Perl, JSP, Ruby, ASP.NET MVC, Webforms, ASP clásico, HTML y en los que se os puedan ocurrir.

Realmente se trata de una biblioteca pura de scripts que funciona en cliente sin dependencias hacia ninguna tecnología concreta en el lado servidor.

¡Un poco de código, por favor!

PantallaVeamos un ejemplo rápido que demuestre una pequeña parte de la potencia de Knockout. Nuestro objetivo es implementar una funcionalidad sencilla como la siguiente:

  • presentaremos un simple cuadro de texto en el que el usuario podrá introducir su nombre, junto con un botón.
  • bajo ellos, un texto en el que se podrá ver el nombre del usuario y el número de veces que ha sido pulsado el botón; las porciones “dinámicas” de este texto (nombre y número de clics) se actualizarán desde script conforme el usuario actúe sobre el interfaz. Es decir, si el usuario modifica el nombre o pulsa el botón, se actualizará el mensaje para representar el nuevo estado.
  • además, para complicar un poco más el escenario, como máximo se podrá hacer clic cinco veces sobre el botón. Al llegar a ese punto, el botón deberá deshabilitarse.

Pero veamos primero una posible implementación utilizando métodos “tradicionales”, puro scripting con un poco de jQuery para simplificar:

HTML SCRIPT
<div>
  <input type="text" id="name" />
  <button id="button">Click me!</button>
  <p>
    <span id="nameLabel"></span>, 
    you've clicked 
    <span id="clicksLabel"></span> 
    times
  </p>
</div>
$(function () {
  var numClicks = 0;
    
  $("#name").val("John");
  $("#clicksLabel").text(numClicks);
  $("#nameLabel").text($("#name").val());
  
  $("#name")
    .change(function () {
       $("#nameLabel").text($("#name").val());
    });
  
  $("#button").click(function () {
    numClicks++;
    if (numClicks >= 5) {
       $("#button").attr("disabled", true);
    }
    $("#clicksLabel").text(numClicks);
  });
});

Observad en el código anterior que, aunque logramos una separación razonable entre la visualización (HTML) y la lógica de presentación (script), el código script es bastante farragoso y presenta una fuerte dependencia hacia la forma en que está implementada la vista. Estamos mezclando inicialización de valores, el registro de manejadores de eventos, lógica, accesos al DOM, mapeo entre valores y controles… demasiadas responsabilidades para un único punto.

Pero lo peor de todo es que esta forma de implementarlo no deja claro qué datos maneja la página, ni qué comportamiento se espera de ella, pues ambos aspectos están dispersos a lo largo del script. Esta forma de desarrollar, cuando nos encontremos ante un escenario más complejo, nos llevaría irremediablemente al caos que comentaba al principio.

¿Y cómo implementaríamos estas mismas funcionalidades con Knockout.js? Veamos primero el script que podríamos emplear, que conformaría la capa View-Model:

    var viewModel = {
        numClicks: ko.observable(0),
        name: ko.observable("Peter"),
        canClick: function () {
            return this.numClicks() < 5;
        },
        addClick: function () {
            if (this.canClick()) {
                var clicks = this.numClicks();
                this.numClicks(clicks + 1);
            }
        }
    };
    ko.applyBindings(viewModel);

Bastante más simple y ordenado, ¿verdad? En el código podemos ver claramente los datos que necesita la vista para funcionar (numClicks y name), y el comportamiento esperado en ella (los métodos canClick() y addClick()); ojo, y no existe ninguna referencia hacia la implementación de la vista ni accesos al DOM.

Pasemos ahora a los detalles.

ko es el objeto básico de Knockout; o en otras palabras, ko es a Knockout lo que $ a jQuery.

Las propiedades nombre (name) y número de clicks (numClicks) las estamos inicializando a sus valores por defecto, “Peter” y “0” respectivamente. Sin embargo, como podéis observar, usamos para ello el método ko.Observable(). Esto quiere decir básicamente que estas propiedades serán “vigiladas”, de forma que cuando cambie su valor Knockout deberá analizar qué elementos dependen de ellas y actualizarlos en consecuencia (volveremos a esto cuando veamos el código de la Vista).

También podemos ver que sobre el propio View-Model se define el método canClick(), que determina si debemos permitir al usuario hacer más clicks sobre el botón, y addClick(), que será la lógica a ejecutar cuando el usuario lo pulse: simplemente incrementamos el número de clicks, aunque dado que es un objeto “observable” tenemos que hacerlo usándolo como una función tanto a la hora de consultar su valor como de asignárselo.

Por último, la llamada a ko.applyBindings() lo que hace es poner en marcha Knockout con el objeto View-Model que hemos definido.

Lo interesante de este código es que, aparte de dejar bastante claro qué esperamos de la página, no hay referencia alguna desde el script hacia los elementos de la vista, ni accesos al DOM, simplemente se mantiene actualizado el View-Model. Knockout se encargará de actualizar el UI conforme a los cambios realizados gracias al binding y a los “observables” que hemos comentado anteriormente.

La implementación de la Vista, puro marcado HTML, podría ser la siguiente:

<div>
    <input  data-bind="value: name" type="text" />
    <button data-bind="click: addClick, enable: canClick()" type="button">Click me!</button>
    <p>
        <span data-bind="text: name"></span>, you've clicked 
        <span data-bind="text: numClicks"></span> times
    </p>
</div>

El atributo data-bind es el utilizado por Knockout para definir los enlaces, o bindings, desde los elementos del interfaz hacia las propiedades o métodos del View-Model.

  • en el primer caso, el cuadro de edición, estamos enlazando su valor al de la propiedad name del View-Model. Cuando cambie ésta, el cuadro de texto de texto cambiará y viceversa: Vista y View-Model estarán siempre sincronizados de forma automática.
  • en el segundo caso, el botón, enlazamos el evento click del ratón con el método addClick del View-Model, y su atributo enable con canClick() para deshabilitar el botón cuando hayamos llegado al máximo de veces permitidas.
  • el tercer y cuatro enlace se realiza entre los <span> y las propiedades del View-Model que queremos mostrar. De nuevo la magia de los “observables” hará que cuando éstas cambien el texto interior de estas etiquetas cambien de forma automática para mostrar su valor.

Fijaos que en la vista no hay lógica, sólo enlaces hacia datos y comportamiento definido en el View-Model.

Bueno, y con esto creo que podemos dejarlo por hoy 🙂 Obviamente, Knockout es mucho más que esto, y así lo iremos viendo en futuros posts, en los que iremos desmenuzando poco a poco este interesante framework y viendo cómo podemos utilizarlo para mejorar el código de nuestra capa de presentación.

Ah, he colgado en Skydrive el ejemplo desarrollado en este post. Es un zip de 15kb, con un único archivo .html y otro .js (knockout) con el que podéis jugar para entender mejor su funcionamiento.

Publicado en Variable not found.