ASP.NET MVC Design Gallery y un primer vistazo a las futuras mejoras de ASP.NET MVC Release Candidate

Hoy hemos lanzado el nuevo ASP.NET MVC Design Gallery en www.asp.net. Esta galería ofrece diseños html que podemos descargar y usar en nuestras aplicaciones ASP.NET MVC. Con cada template viene un archivo .master, con una hoja de estilos CSS, y un conjunto de imágenes, clases parciales y métodos de ayuda para ellos.

La galería nos permite previsualizar cada uno de los diseños online, así como descargar una versión en .zip de ellas que podemos extraer e integrar en nuestro sitio. La galería permite que cualquiera cree y mande sus diseños bajo la licencia creative commons. Los visitantes de la galería pueden votar para ofrecer feedback a sus creadores (thumbs up/thumbs down). Los diseños más populares se mostrarán al principio de la galería.

Creemos que ofrece una gran utilidad para que los desarrolladores creen sitios más atractivos y que cumplan los estándares. Se espera que anime a la gente a crear y compartir diseños que puedan ser reutilizados por otros.

Futuras mejoras con la Release Candidate

Mientras que hablamos de interfaces de usuario, me gustaría compartir unos cuantos detalles sobre las mejoras sobre las vistas que vienen con la nueva Release Candidate de ASP.NET MVC que vamos a publicar dentro de poco. Además de corregir algunos bugs, en esta release candidate se incorporan unas cuantas mejoras relacionadas con las vistas en base a varias sugerencias de la comunidad.

Vistas sin archivos de código trasero.

Basándonos en el feedback de un montón de gente, hemos decidido hacer un cambio para que los archivos de las vistas de MVC no creen por defecto los archivos de código trasero. Este cambio ayuda a reforzar el propósito de las vistas en el mundo MVC (que se suponen deben centrarse sólamente en el renderizado y no contener ningún código relacionado), y para la mayoría de la gente se han eliminado archivos innecesarios en el proyecto:

Con la beta de ASP.NET MVC, los desarrolladores pueden eliminar el código trasero usando la sintaxis de CLR para tipos genéricos en vistas que hereden un atributo, pero esta sintaxis de CLR es (para ser claros) muy difícil de usar. El equipo de ASP.NET MVC fue capaz de combinar unas cuantas características de extensibilidad que ya estaban en ASP.NET para permitir la sintaxis estándar de VB/C# a través del atributo de herencia que venía en la release candidate de ASP.NET:

Otro gran beneficio de no usar un archivo con código trasero es que tendremos un intellisense inmediato cuando la añadamos al proyecto. Con la beta teníamos que ir al menú build/compile inmediatamente después de crear una vista para poder tener el intellisense en ella. La RC hace que el workflow de añadir y editar inmediatamente la vista se muy parecido.

Top-Level Model Property en vistas.

Con versiones previas de ASP.NET MVC, accedíamos a un modelo de objetos fuertemente tipados que se pasaban a la vista usando la propiedad ViewData.Model:

La sintaxis anterior sigue funcionando, aunque ahora hay otra propiedad en una vista que podemos usar:

Esta propiedad hace exactamente lo mismo que la versión anterior – el principal beneficio es que nos permite escribir código mucho más conciso.

Ayudantes HTML/AJAX  permiten expresiones de sintaxis

Una de las peticiones que hemos tenido es la posibilidad de usar expresiones fuertemente tipadas (en lugar de strings) cuando nos referimos al modelo usando objetos de vistas HTML y AJAX.

Con la beta de ASP.NET esto no era posible, ya que los clases de ayuda HtmlHelper y AjaxHelper  no expon’ian el tipo de modelo, y teníamos que crear nuestros helper methods directamente fuera de la clase base ViewPage<TModel> para conseguirlo. La RC de ASP.NET MVC introduce los tipos HtmlHelper<TModel> y AjaxHelper<TModel> que se exponen en la clase base ViewPage<TModel>. Estos tipos permiten que cualquiera pueda crear métodos de extensión HTML y AJAX fuertemente tipados que usan expresiones de consultas para referirse a las vistas del modelo.

Por ejemplo, podríamos crear un helper method (muy simple) fuertemente tipado con el siguiente código:

Y usarlo en cualqueira de nuestras vistas para enlazar un Producto de nuestro modelo de objetos de la siguiente forma:

Visual Studio nos dara intellisense para la expresión fuertemente tipada cuando trabajemos contra el modelo de la vista en el editor de código de la siguiente manera:

Nota: las extensiones HTML en el núcleo de ASP.NET MVC V1 se seguirá usando la sintaxis existente (no basada en expresiones). Estamos planeando añadir versiones basadas en expresiones en el assembly MVCfutures. Por supuesto, podemos seguir añadiendo nuestro propios helper methods (usando tanto strings como expresiones fuertemente tipadas). Todos los helper methods incluidos pueden ser opcionalmente eliminados (ya que son extensión methods) si queréis reemplazarlos o sobrescribirlos.

Soporte scaffolding (andamios)

La RC de ASP.NET MVC incluye soporte automático para crear los andamios necesarios para UI cuando creamos vistas usando el nuevo comando “Add View” de Visual Studio. Este soporte nos permite generar automáticamente vistas contra cualquier tipo de .NET u objeto – es decir, puede funcionar sobre cualquier clase POCO, LINQ to SQL, LINQ to Entities, NHibernate, Subsonic, LLBLGen Pro, o cualquier otro modelo de objetos. El motor usa reflexión para obtener las partes públicas del modelo de tipos de la vista, y se lo pasa a un template para obtener el markup necesario para la vista que se está creando.

Por ejemplo, supongamos que tenemos la clase ProductsController y queremos crear la acción “Edit” para mostrar una vista de edición para un Product particular. Con esta Release candidate podemos hacer clic derecho en el método de acción “Edit” y seleccionar “Add View” en el menú contextual:

En el diálogo de “Add View” podemos indicar que lee estamos pasando un tipo Product a la vista:

Podemos indicar que queremos una vista “Empty” (como la anterior) o indicar que queremos que VS la genere automáticamente un formulario “Edit” para el objeto que le estamos pasando:

Si elegimos el template “Edit” VS generará un archivo que tiene todo el HTML y los métodos de validación necesarios  para crear un formulario:

Podemos ejecutar la aplicación y obtener la interfaz de usuario necesaria para la edición:

Luego podemos ir y cambiar el archivo edit.aspx como queramos para personalizarlo.

Una de las cosas realmente increíbles sobre esto es que está usando el sistema de generación de código T4 de Visual Studio (Scott Hanselman tiene un post sobre esto aquí). Los templates “List”, “Edit”, “Create” y “Details” qu publicamos con ASP.NET pueden ser completamente personalizados o reemplazados con los templates T4 por los nuestro (o descargárnoslos de la ASP.NET MVC Design Gallery). Así que si tenéis una forma personal de crear los HTML, o queréis usar HTML helpers personalizados (por ejemplo: los que están basados en expresiones fuertemente tipadas) podéis actualizar los templates por defecto y el sistema de scaffolding  (andamios) los usará.

Estamos planeando dejar que los templates puedan sobreescribirse tanto a nivel de máquina como a nivel de proyecto (de manera que podamos  subir cualquier template y compartirlos en un equipo).

Tareas de MSBuild para vistas compiladas

Por defecto cuando hacemos un build en un proyecto ASP.NET MVC se compila todo el código del proyecto, excepto el código de los archivos de vistas. Con la beta de ASP.NET MVC teníamos que crear nuestra propia tarea de MSBuild si queríamos compilarlas. Esta RC incluye una tarea MSBuild que podemos usar para incluir las vistas como parte del proceso de compilación del proyecto. Esto verificará la sintáxis y el código incluido en las vistas y en las master pages de la aplicación, y nos mostrará errores cuando los encuentre.

Por motivos de rendimiento no recomendamos que esto se haga así para compilaciones rápidas durante el proceso de desarrollo, pero es conveniente añadir los a una configuración de build (por ejemplo: en las fases de despliegue y en integración) y/o para usarlo en servidores Build o CI (Integración Continua).

Otras características de la Releas Candidate.

Hemos visto una pequeña lista de las funcionalidades que vienen en esta release candidate.

Hay otras características y peticiones que vienen en ella: soporte para IDataErrorInfo para permitir a los modelos mostrar mensajes de errores de validación, así como una mayor extensibilidad de dichas validaciones para poder usar nuestras propias validaciones en los ModelBinders (El soporte de IDataErrorInfo está encima de todo esto); nuevos tipos FileResult y JavaScriptResult (permitiéndonos descargar archivos y ejecutar javascript en los navegadores); el archivo –vsdoc para el intellisense jQuery viene integrado; soporte de refactorizado en AccontController para permitirnos crear test unitarios más fácilmente y poder extenderlo a escenarios de login; una variedad de mejoras en los templates de proyectos, más extensibilidad por todas partes; muchos bugs corregidos, y otras características chulas/chulosas de las que hablaré más tarde.

Publicaremos esta release en enero. Nuestros planes son tener la ASP.NET MVC V1 API con todas las características y ningún bug conocido. Daremos un poco de tiempo para que os la descarguéis, para que la pateéis bien, y nos comentéis cualquier cosa que encontréis. Luego publicaremos la V1 oficial rápidamente después de todo eso (que no es poco).

Espero que sirva.

Scott.

Traducido por: Juan María Laó Ramos.

Artículo original.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *