Mientras esperamos impacientes la llegada de ASP.NET MVC 2 con su flamante sistema integrado de validación de datos en cliente y servidor, xVal puede sernos de bastante utilidad al ofrecernos prácticamente las mismas funciones previstas para la versión 2, y alguna más :-)

xVal es un framework para aplicaciones ASP.NET MVC 1.0 (y superiores) creado por Steve Sanderson, y presentado en sociedad el pasado 17 de septiembre, que permite validar la información almacenada en clases del modelo, tanto en el lado cliente como en servidor, de forma automatizada.

Su diseño es muy flexible, permitiéndonos elegir entre distintos marcos de trabajo para la validación en servidor (de serie soporta los atributos DataAnnotations, Castle Validator y NHibernate Validator, aunque se pueden crear proveedores personalizados) y librerías en cliente (inicialmente utiliza el magnífico plugin jQuery Validation).

Vamos a ver, paso a paso, cómo podemos comenzar a utilizarlo de forma inmediata en nuestras aplicaciones ASP.NET MVC 1.0, utilizando las restricciones DataAnnotations y la librería de validación para jQuery citada anteriormente.

1. Preparamos la infraestructura

En primer lugar, vamos a preparar el entorno para utilizar el framework de validación:

1. Descargamos xVal desde CodePlex. Se distribuye en un fichero .zip que incluye tanto el ensamblado como archivos de soporte, así que lo descomprimimos en cualquier parte para tener los archivos a mano.
   


2. Descargamos el plugin de validación de jQuery, por ejemplo, desde el CDN de Microsoft (¿qué es el Microsoft Ajax CDN?) y lo incluimos en la carpeta /scripts de nuestro proyecto. Otra posibilidad sería no descargarlo y referenciarlo directamente nuestras páginas, a gusto del consumidor ;-)
   


3. Añadimos a la carpeta /scripts del proyecto la librería xVal.jQuery.Validate.js presente en el raíz del comprimido de xVal. Este archivo, junto con el anterior, son imprescindibles para montar la validación automática en el lado cliente que veremos más adelante. Además, para que los mensajes aparezcan en nuestro idioma, copiamos también al mismo sitio el archivo xVal.Messages.es-ES.js, disponible en la carpeta “internationalization” del zip.
   


4. Copiamos al directorio /bin de nuestra aplicación el ensamblado xVal.dll, o simplemente añadimos una referencia en el proyecto hacia dicho archivo, que encontraréis en el raíz del fichero comprimido que hemos descargado en primer lugar.
   


5. Retocamos ligeramente el Web.config de nuestro proyecto para que sea incluido automáticamente el espacio de nombres xVal.Html en nuestras vistas, facilitando así el acceso a los helpers suministrados:
   
   

   <system.web>

     <pages>

        <namespaces>

           <!-- Añadir la siguiente línea -->

           <add namespace="xVal.Html"/>

       </namespaces>

     </pages>

   </system.web>

Los pasos comentados hasta el momento son genéricos, es decir, tendremos que realizarlos en todos los proyectos en los que vayamos a utilizar este framework de validación. Podría ser interesante, por tanto, crearnos una plantilla de proyecto en la que tengamos ya todo este trabajo realizado.

2. Definimos las restricciones con Data Annotations

Ahora vamos a definir, de forma declarativa, las restricciones que queremos imponer a las propiedades de las clases del modelo, utilizando los atributos denominado data annotations, distribuidos con .NET 3.5 y originalmente diseñados para trabajar con la tecnología Dynamic Data.

1. Dado que vamos a declarar las restricciones utilizando los atributos data annotations, hay que añadir referencia en el proyecto a  System.ComponentModel.DataAnnotations.



2. A continuación, tenemos que incluir en el proyecto un método que nos permita recorrer las anotaciones de las clases, ejecutarlas e ir generando los errores apropiadamente.  Este método lo utilizaremos más adelante, desde los componentes del Modelo, para comprobar si los valores presentes en las propiedades cumplen los requisitos impuestos por el dominio del sistema.
   
   El código es muy sencillo, el propio Sanderson nos facilita uno en el proyecto de demostración de xVal, que podéis copiar y pegar:
   
   

   using System;

   using System.Collections.Generic;

   using System.Linq;

   using System.Web;

   using xVal.ServerSide;

   using System.ComponentModel.DataAnnotations;

   using System.ComponentModel;

   namespace MyProject.Validation

   {

    public static class DataAnnotationsValidationRunner

    {

     public static IEnumerable<ErrorInfo> GetErrors(object instance)

     {

       var metadataAttrib = instance.GetType()

                               .GetCustomAttributes(typeof(MetadataTypeAttribute), true)

                               .OfType<MetadataTypeAttribute>().FirstOrDefault();

       var buddyClassOrModelClass = metadataAttrib != null ? 

                                       metadataAttrib.MetadataClassType:

                                       instance.GetType();

       var buddyClassProperties = TypeDescriptor.GetProperties(buddyClassOrModelClass)

                               .Cast<PropertyDescriptor>();

       var modelClassProperties = TypeDescriptor.GetProperties(instance.GetType())

                               .Cast<PropertyDescriptor>();

       return from buddyProp in buddyClassProperties

                  join modelProp in modelClassProperties on buddyProp.Name equals modelProp.Name

                  from attribute in buddyProp.Attributes.OfType<ValidationAttribute>()

                  where !attribute.IsValid(modelProp.GetValue(instance))

                  select new ErrorInfo(

                               buddyProp.Name, 

                               attribute.FormatErrorMessage(string.Empty), instance);

     }

    }

   }

   
   Ojo, esto sólo tenemos que hacerlo cuando estemos utilizando DataAnnotations, como es el caso; si utilizamos otros frameworks como el de Castle o NHibernate no será necesario, puesto que incluyen ya implementaciones para realizar esta tarea.
   
   


3. Marcamos las propiedades de la entidad del modelo con las restricciones a aplicar durante la validación. Podemos utilizar los atributos disponibles para restringir los valores permitidos en cada propiedad como Required , StringLength , Range  y otros (puedes ver la relación completa aquí).
   
   Un ejemplo podría ser el siguiente, en el que vemos varias restricciones aplicadas a las propiedades de la entidad:
   
   

   public class Recluta

   {

       [Required, StringLength(30)]

       public string Nombre { get; set; }

       [Required, StringLength(40)]

       public string Apellidos { get; set; }

       [Required, Range(1, 4)]

       public int Talla { get; set; }

       [Required, DataType(DataType.Date)]

       public DateTime FechaNacimiento { get; set; }

   }

   
   Sin embargo, muchos os preguntaréis qué ocurre cuando estas entidades de datos las generamos con herramientas automáticas, como el diseñador de Entity Framework. En estos casos, cada vez que generemos el modelo, las clases serían machacadas por las nuevas versiones, y nuestras anotaciones pasarían a mejor vida.
   
   Afortunadamente, existe la posibilidad de declarar una clase paralela (o, como la llaman, ‘buddy class’), en la que definiremos exclusivamente las propiedades a las que queremos añadir alguna anotación. Además, marcaremos la entidad original (aprovechando que la mayoría de estas herramientas automáticas las generan como parciales) indicando la clase que contiene los metadatos asociados a ésta:
   
   

   // Indicamos en la entidad original que los

   // metadatos se encuentran en 'ReclutaMedata'

   [MetadataType(typeof(ReclutaMetadata))]

   public partial class Recluta

   { 

       // Nada más que añadir aquí

   }

   // Definimos los metadatos para la entidad 'Recluta'

   public class ReclutaMetadata

   {

       [Required, StringLength(30)]

       public string Nombre { get; set; }

       [Required, StringLength(40)]

       public string Apellidos { get; set; }

       [Required, Range(1, 4)]

       public int Talla { get; set; }

       [Required, DataType(DataType.Date)]

       public DateTime FechaNacimiento { get; set; }

   }

   
   Como podéis observar, la entidad y la clase de metadatos son prácticamente iguales. Un poco anti-DRY sí que es, pero bueno.

3. Validamos en servidor

La propuesta de xVal para el lado del servidor consiste en desplazar la lógica de validación al modelo, dado que es éste el que normalmente impone las restricciones en los datos que han de estar presentes en las entidades del dominio. Una forma de realizarlo sería así:

• por cada entidad, creamos un método que valide la información del mismo, primero invocando al ValidationRunner (el proceso de validación basado en anotaciones descrito anteriormente), y luego añadiendo aquellas reglas de negocio no incluidas en dichas anotaciones). Un ejemplo podría ser el siguiente:
  
  

  private void validar(Recluta recluta)

  {

      var errors = DataAnnotationsValidationRunner.GetErrors(recluta);

      if (errors.Any())

          throw new RulesException(errors);

      // Regla de negocio adicional: prohibido alistarse reclutas

      // con hermanos en el cuartel...

      if (tieneHermanos(recluta.Apellidos))

      {

          throw new RulesException("Apellidos",

                      "El recluta tiene hermanos ya alistados", recluta);

      }

  }

   
  Este método podría incluirse en la propia entidad Recluta, o bien donde se implemente la lógica de negocio asociada a la misma.
   
  En cualquier caso, como se puede observar, cuando se producen errores debido a un incumplimiento de las restricciones indicadas en las anotaciones, se lanza una excepción de tipo RulesException (facilitada por xVal) que contiene una descripción de los problemas encontrados. Asimismo, la existencia de otro tipo de problemas, hallados de forma programática, son lanzados también en una excepción del mismo tipo.
   


• antes de realizar operaciones susceptibles de modificar el estado del sistema, tenemos que asegurarnos de que las entidades son válidas. Observad, por ejemplo, la implementación del método que nos permite añadir un recluta al sistema:
  
  

  public void Crear(Recluta recluta)

  {

      validar(recluta);

      reclutas.Add(recluta);

  }

  
  Si se producen errores en la validación, el método Crear() será interrumpido por la excepción RulesException lanzada desde validar(), y llegará finalmente hasta el Controlador, donde deberá ser procesada. 
  


• desde el punto de vista del Controlador, podremos comprobar que el patrón a seguir es realmente sencillo, pues toda la lógica de validación la hemos desplazado al modelo.
  
  El siguiente código muestra los métodos de acción asociados a la creación de una entidad; el primero de ellos simplemente se encarga de mostrar la vista de edición sobre un objeto recién creado, mientras que el segundo obtiene los datos del recluta desde el formulario, e intenta realizar la operación de creación sobre el modelo:
  
  

  public ActionResult Create()

  {

      return View(new Recluta());

  }

  [AcceptVerbs(HttpVerbs.Post)]

  public ActionResult Create(Recluta recluta)

  {

      try

      {

          gestorDeReclutas.Crear(recluta);

      }

      catch (RulesException ex)

      {

          ex.AddModelStateErrors(this.ModelState, "");

      }

      if (!ModelState.IsValid)

          return View(recluta);

      else 

          return RedirectToAction("Index");

  }

  
  Como se puede observar, se capturan las excepciones de validación que se produzcan al realizar el alta, añadiendo al ModelState los errores que se estén informando en éstas y, en función de la validez de los datos, enviando al usuario a la vista correspondiente.

4. Validamos en el cliente

Está claro que la validación en el lado del servidor es la que única que debemos hacer obligatoriamente; el lado cliente es sensible al equipo del usuario, que puede estar accediendo desde dispositivos sin javascript (o con esta característica desactivada), o incluso puede ser fácilmente manipulado, por lo que no podemos confiar en que los datos lleguen ya siendo válidos.

Sin embargo, ofrecer validación en cliente es una característica imprescindible hoy en día vistas a realizar interfaces muy usables, capaces de ofrecer al usuario feedback inmediato sobre sus acciones.

Con xVal, añadir en este punto validaciones en cliente es realmente sencillo, pues ya tenemos realizado prácticamente todo el trabajo, quedando simplemente:

1. incluir las librerías script en las vistas donde vayamos a realizar la edición de las entidades del modelo. Si vamos a utilizarlas en muchos sitios, lo más fácil es añadirlas a la página maestra:
   
   

   <script src="../../Scripts/jquery-1.3.2.min.js" type="text/javascript"></script>

   <script src="../../Scripts/jquery.validate.min.js" type="text/javascript"></script>

   <script src="../../Scripts/xVal.jquery.validate.js" type="text/javascript"></script>

   <script src="../../Scripts/xVal.Messages.es-ES.js" type="text/javascript"></script>

   
   


2. generar en la vista los scripts de validación de las entidades que nos interesen. En el siguiente código generamos la lógica para la entidad Recluta:
    
   

   <%= Html.ClientSideValidation<MiProyecto.Models.Recluta>() %>

       

5. ¡Y hasta aquí hemos llegado!

A lo largo de este post hemos recorrido los pasos necesarios para echar a andar el framework xVal en una aplicación ASP.NET MVC 1.0.

Faltan muchos aspectos por comentar, como la posibilidad de utilizar validaciones Ajax en servidor, permitir la localización en decimales, escribir nuestros propios atributos de anotaciones, etc., pero creo que este post ya es lo suficientemente extenso… ya lo veremos en otra ocasión.

Puedes descargar el proyecto de demostración desde Skydrive:

Publicado en: Variable not found.

Pues sí… todo lo que empieza acaba, y las vacaciones no iban a ser una alegre excepción.

Aquí estamos de nuevo listos para entrar en combate. Esta vez, además, el retorno al MundoReal™ coindice con un momento de emocionantes cambios a nivel profesional, lo cual hace especialmente motivador el regreso.

En cuanto a las vas vacaciones, simplemente geniales: mucho descanso en las playas de Huelva y Cádiz y, sobre todo, un grato recuerdo de la visita a Lanzarote, que sin duda es espectacular; si alguna vez tenéis oportunidad de visitar la isla, no dudéis en ir a disfrutar de ese lugar tan diferente. La única pega ha sido la insistente ola de calor que nos ha perseguido a todos nuestros destinos, pero bueno, son gajes del oficio.

De compañero de viaje esta vez he elegido Struts 2 in action, una muy recomendable lectura para conocer este veterano framework Java de desarrollo de aplicaciones web bajo la filosofía MVC. Me ha resultado interesantísimo conocer el enfoque del marco de trabajo, y contrastarlo con el muy reciente ASP.NET MVC; aunque con las obvias diferencias vinculadas a las tecnologías subyacentes en cada caso y al nombrado de componentes, hay muchísimas coincidencias y es sencillo encontrar correspondencias entre ambos frameworks que facilitan la comprensión y asimilación de los conceptos.

El libro está editado en español por Anaya Multimedia, bajo el nombre Struts 2; aunque, como suele ocurrir en este tipo de textos, de vez en cuando te encuentras errores de traducción y contenidos, cumple bastante bien su cometido.

Y sin más preámbulos, comenzamos la temporada 2009-10 en Variable not found, donde espero seguir contando, como hasta ahora, con vuestra participación y apoyo.

Publicado en: Variable not found.

Varios lectores y amigos me han hecho llegar algunas cuestiones sobre el nuevo ASP.Net MVC Framework, y en vez de responder de forma individual, creo que es más interesante realizar un post recopilatorio e intentar que las respuestas puedan ayudar a más desarrolladores. Aprovecho para añadir cuestiones de mi propia cosecha, esperando que también puedan aclarar algo.

<disclaimer>

Algunas de las respuestas podríamos considerarlas como beta, y pueden variar con el tiempo. Son opiniones, ideas y conjeturas sobre un producto nuevo y que todavía está en desarrollo, así que usadlas con precaución. ;-)

</disclaimer>

1. Empecemos desde el principio, ¿qué es MVC?

Aunque de forma algo simplista, podríamos definir MVC como un patrón arquitectural que describe una forma de desarrollar aplicaciones software separando los componentes en tres grupos (o capas):

• El Modelo que contiene una representación de los datos que maneja el sistema, su lógica de negocio, y sus mecanismos de persistencia.
• La Vista, o interfaz de usuario, que compone la información que se envía al cliente y los mecanismos interacción con éste.
• El Controlador, que actúa como intermediario entre el Modelo y la Vista, gestionando el flujo de información entre ellos y las transformaciones para adaptar los datos a las necesidades de cada uno.

MVC son las siglas de Modelo-Vista-Controlador, y se trata de un modelo muy maduro y que ha demostrado su validez a lo largo de los años en todo tipo de aplicaciones.

Puedes encontrar más información en:

• Wikipedia, Modelo-Vista-Controlador
• Documentos originales de definición de MVC, de Trygve M. H. Reenskaug, en Xerox (¡año 1978!)
• Tutorial de Java, Arquitectura MVC
• Model-View-Controller Web presentation pattern en MSDN

2. ¿Qué ventajas tiene el uso del patrón MVC?

Como siempre, esto de enumerar ventajas es algo subjetivo, por lo que puede que pienses que falta o sobra alguna (¡dímelo!). En un primer asalto, podríamos aportar las siguientes:

• Clara separación entre interfaz, lógica de negocio y de presentación, que además provoca parte de las ventajas siguientes.
• Sencillez para crear distintas representaciones de los mismos datos.
• Facilidad para la realización de pruebas unitarias de los componentes, así como de aplicar desarrollo guiado por pruebas (TDD).
• Reutilización de los componentes.
• Simplicidad en el mantenimiento de los sistemas.
• Facilidad para desarrollar prototipos rápidos.
• Los desarrollos suelen ser más escalables.

Pero bueno, también se pueden citar algunos inconvenientes:

• Tener que ceñirse a una estructura predefinida, lo que a veces puede incrementar la complejidad del sistema. Hay problemas que son más difíciles de resolver respetando el patrón MVC.
• La curva de aprendizaje para los nuevos desarrolladores se estima mayor que la de modelos más simples como Webforms.
• La distribución de componentes obliga a crear y mantener un mayor número de ficheros.

3. ¿Qué es ASP.Net MVC Framework?

Es un framework, un entorno de trabajo que está creando Microsoft, que nos ayudará a desarrollar aplicaciones que sigan la filosofía MVC sobre ASP.Net. Su versión final incluirá librerías (ensamblados), plantillas y herramientas que se integrarán en Visual Studio 2008. ScottGu, en su presentación del framework el pasado Octubre en las conferencias Alt.Net, ya adelantó las principales características, y puedes ampliar información en la página oficial.

Actualmente (marzo 2008) puede descargarse la Preview 2 del framework, e incluso su código fuente ha sido publicado en CodePlex. Aunque "de fábrica" no soporta las versiones Express de Visual Studio, en este mismo blog puedes encontrar algunas plantillas y ejemplos de ASP.NET MVC. También hay quien la ha echado a andar en Mono.

4. ¿Es el primer framework MVC creado para .Net?

No, ni el único. Existen multitud de frameworks MVC para ASP.Net, como MonoRail, Maverick.Net, ProMesh.Net y muchos otros.

5. Como desarrollador de aplicaciones web con ASP.Net, ¿me afectará la llegada de este framework?

No necesariamente. Puedes seguir desarrollando aplicaciones como hasta ahora, con Webforms. Si así lo decides, este nuevo framework no te afectará nada; simplemente, ignóralo.

De todas formas, ya que has leído hasta aquí, permíteme un consejo: aprende MVC framework. Después podrás decidir con conocimiento de causa si te conviene o no.

6. ¿Significa la aparición del framework MVC la muerte próxima de los Webforms de ASP.Net?

En absoluto. Son simplemente dos filosofías diferentes para conseguir lo mismo, ¡páginas web!.

La tecnología de Webforms es muy útil para asemejar el desarrollo de aplicaciones web a las de escritorio, ocultando la complejidad derivada del entorno desconectado y stateless (sin conservación de estado) del protocolo HTTP a base de complejos roundtrips, postbacks y viewstates, lo que nos permite crear de forma muy productiva formularios impresionantes y que el funcionamiento de nuestra aplicación esté guiado por eventos, como si estuvieramos programando Winforms.

Sin embargo, esta misma potencia a veces hace que las páginas sean pesadas y difícilmente mantenibles, y además se dificultan enormemente la realización de pruebas. Y por no hablar de comportamientos extraños cuando intentamos intervenir en el ciclo de vida de las páginas, por ejemplo para la carga y descarga de controles dinámicos.

ASP.Net MVC propone una forma distinta de trabajar, más cercana a la realidad del protocolo y, curiosamente, más parecida a cómo se hacía unos años atrás, cuando controlábamos cada byte que se enviaba al cliente. No existen, por tanto, conceptos como el mantenimiento del estado en el viewstate, ni el postback, ni nos valdrán los controles de servidor basados en estas características, la mayoría. Sin embargo, dado que el framework está creado sobre ASP.Net, será posible utilizar páginas maestras, codificar las vistas en un .aspx utilizando C# o VB.Net, usar los mecanismos de seguridad internos, control de caché, gestión de sesiones, localización, etc; además, seguro que en un futuro no demasiado lejano comenzarán a surgir miles de componentes o controles reutilizables que nos ayudarán a mejorar la productividad.

7. ¿Vale la pena pasarse a ASP.Net MVC o sigo usando Webforms?

Todavía lo estoy estudiando ;-). Hay muchos aspectos a valorar.

No hay que olvidar que los Webforms son una buena opción, tanto como lo han sido hasta ahora. Sobre todo si el equipo de desarrollo tiene ya experiencia creando aplicaciones con esta tecnología y se dispone de controles reutilizables propios o ajenos, deberíamos pensárnoslo antes de dar el salto a ASP.Net MVC. Tened en cuenta que la productividad, al menos inicialmente, va a caer.

Sin embargo, las ventajas de la arquitectura MVC y del propio framework descritas anteriormente son un buen aliciente para comenzar: testing, URLs amigables, separación de aspectos, mantenibilidad... Por otra parte, todavía es pronto para conocer el nivel de las herramientas de desarrollo (a nivel de IDE, librerías de controles, helpers) que aparecerán con la versión final, y las que surgirán desde la propia comunidad de desarrolladores, por lo que no es posible evaluar el impacto en la productividad que tendrá la adopción de esta nueva forma de trabajar.

Y, por cierto, si te preocupa el futuro de los Webforms, has de saber que Microsoft va a seguir dándoles soporte y mejorándolos, como no podía ser de otra forma. Por tanto, de momento no es necesario que bases tu decisión en esto.

8. ¿Se puede utilizar el ASP.Net Ajax con el framework MVC?

De momento parece que no, o al menos no de la forma en que se hace actualmente, dado que los controles de servidor (runat="server"), como el UpdatePanel, no están integrados en este modelo. De hecho, ya ni siquiera tienen sentido los formularios runat="server", por lo que menos aún los controles que dependían de éstos.

Se prevé que se creará un API específico para permitir desde cliente, mediante scripting, hacer llamadas a los controladores, y actualizar porciones de contenido de la página con el marcado que nos envíe la vista correspondiente. Pero esto son sólo conjeturas de momento, ya se irá aclarando conforme el producto se acerque a su versión final.

9. ¿Puedo usar Linq desarrollando aplicaciones con ASP.Net MVC framework?

Sí, de hecho se complementan a la perfección.

Por ejemplo, las clases del modelo podrán generarse de forma automática (y completa para aplicaciones relativamente simples) con los diseñadores visuales de LinqToSQL o LinqToEntities desde Visual Studio 2008 o de forma externa con herramientas como SQLMetal. Además, el controlador podrán utilizar expresiones de consulta para solicitar datos desde el modelo, o enviar datos actualizados usando las capacidades ORM de estas tecnologías.

10. ¿Será ASP.Net MVC framework software libre?

Pues claro que no ;-). Se podrá acceder al código fuente (de hecho, ya se puede), que será distribuido de la misma forma que el de .Net framework, pero no será software libre. Si buscas una solución open source, revisa la pregunta número 4.


Publicado en: http://www.variablenotfound.com/.

Si hace unos días Jeffrey Palermo recogía en su blog la presentación del futuro ASP.Net MVC Framework, es ahora el propio Scott Guthrie, uno de los padres de la criatura, el que hace una pequeña introducción en su bitácora sobre esta tecnología que se avecina.

Vía CodeBetter llego a un interesante post de Jeffrey Palermo donde cuenta que Scott Guthrie, de la división de desarrolladores de Microsoft, anunció y demostró el pasado 5 de ocubre en el contexto de las conferencias Alt.Net un framework MVC para ASP.NET en el que los de Seattle llevan tiempo trabajando.

Algunas de las características que describe, aunque muy someramente, de la nueva plataforma son:

• Soporte nativo para TDD (¿qué diantres es esto?) en los Controladores.
• Vistas basadas en ASPX, sin viewstate ni postbacks.
• Soporte para enlaces otros motores como MonoRail.
• Soporte para contenedores IoC (¿ein?) y DI (¿y esto qué es?).
• Control absoluto sobre las URLs y la navegación. Éstas seguirán un modelo común, algo similar a: "/Ruta/Acción/Param1/Param2... ", que se mapearán hacia la acción oportuna del Controlador asignado.
• Separación de la capa de negocio de la de presentación, como buen MVC.
• Integración total en ASP.NET, sin traumas. De hecho, la llegada de esta tecnología no implica, ni por asomo, la desaparición de los conocidos y utilizados Webforms actuales, ambos modelos podrán convivir incluso en la misma aplicación.
• Soporte para lenguajes estáticos como C++, C#, o VB.Net y dinámicos como Javascript, Ruby o Python.

Se espera una CTP pública hacia finales de año, y se espera la versión definitiva como add-on para el próximo Visual Studio 2008. Mínimo primavera-verano, por tanto.