Quetzal finalmente disponible

Luego de un año ajetreado, finalmente he liberado el código de Quetzal bajo una licencia GPL. Lo pueden descargar de aquí.

Varias fueron las razones por las que tarde tanto en liberar este framework, pero la principal era que en la primeras versiones era arduo de configurar y de extender, cosa que lo hacía muy improductivo. Por suerte, Quetzal ha cambiado mucho internamente, desde esas primeras versiones principalmente para facilitar su extensibilidad.

Es así que Quetzal es un framework "orientado a la generación de código", ya que si bien fue pensado para resolver varios de los problemas que se presentan al trabajar con la generación de código, su capacidad de mantener el "modelo" en memoria permite que funcione como una "extensión" de las clases del dominio agregando propiedades y métodos de forma dinámica.

Quienes bajen el código tendrán entre sus manos lo siguiente:

• El "core" de Quetzal que es "ModelDescriptor" y tres extensiones,
• AutomationNH tambien conocida como NHGenerator que permite generar los .hbm a partir de las clases del dominio.
• ModelToArtifact (M2A) que implementa un mecanismo para la manipulación y la administración de la generación de código
• y Validator que como su nombre lo indica implementa validaciones usando como validadores específicos los de EntityLibrary 3.1

Pueden seguir como ejemplo los test, para el caso de M2A y Validator,  y el sample para el funcionamiento de "NHGenerator". Se que los ejemplos son pobres pero mi idea es tener una demo y "alguna" documentación que integre todo próximamente.

Espero sus comentarios y que les sea útil.

ASP.NET MVC II : Recursos

Como les conté estoy trabajando con Asp.Net MVC y como todo proyecto en ejecución carece de muchas funcionalidades y recursos que nos facilitan las cosas para construir aplicaciones del mundo real. Si aparte trabajan con Visual Web Developer 2008(VWD2008) como es mi caso, la cosa se complica un poco más, ya que el CTP 2 no soporta el tipo de proyectos que se manejan con esta IDE. Así que mi idea es compartir con Uds. algunos recursos que me resultaron de mucha ayuda y un pequeño aporte de mi parte.

• Thinking in .NET blog con traducciones al castellano de importantes referentes de .net, sobre sus ultimas tecnologías. Entre las traducciones figuran el tutorial de MVC de Scott Gutthrie.
• Un template de una aplicación de Asp.Net MVC CTP 2 para utilizar con VWD 2008. Esencial para nuevos proyectos. Si ya venias trabajando con el CTP 1 te simplifica la migración.
• MVC Contrib - MvcContrib.org un importante proyecto de la comunidad para aumentar la funcionalidad del framework. Varias cosas muy interesantes (IOC, helpers, templates, NHaml para los que conocen RoR, etc). No lo use todavía.
• ASP.Net MVC Membership Starter Kit esta implemetación para MVC solo funciona en proyectos bajo VS2008. Se puede usar tambien con OpenID. Podrán hallar aquí (svn) una adaptación del codigo fuente de mi autoría para Visual Web Developer 2008.
• El blog de Fredrick Normén con ejemplos de programación avanzada.
  

Bueno, espero que a ustedes les sirva también .

ASP.NET MVC I : RenderComponents y bugs

Estoy desarrollando desde el fin del año pasado un proyecto que usa Asp.Net MVC. Demás esta decir las bondades de la nueva arquitectura.
Recientemente se lanzó el CTP 2 que trae una serie de mejoras, muchas basadas en las recomendaciones de la comunidad, y tambien se puede ver el código fuente (sic) ;).
Para los conocedores de MVC, especialmente de MonoRail, entre las mejoras se encuentra la utilización de "ViewComponents", pero como toda tecnología que esta "verde" trae sus bugs.
Es así que me cruce con uno de estos "bichitos" que es comentado en este post
y cuyo autor plantea el "core" de la solución, y tambien propone una solución más general pero sin código. Mi humilde aporte va en este sentido, es decir aqui les dejo el código mas general que permita avanzar hasta el próximo CTP. La funcionalidad se implementa mediante "extensions" (.net 3.5) de la clase ViewPage:

using System;
using System.Linq.Expressions;
using System.Web.Mvc;

public static class Extensions
{

    public static string RenderComponent<T>(this ViewPage vwp, 
Expression<Action<T>> action) where T : ComponentController
    {
        T controller = Activator.CreateInstance<T>();
        controller.Context = vwp.ViewContext;
        var ex = action.Compile();
        ex.Invoke(controller);
        return controller.RenderedHtml;
    }
}

Y lo utilizamos en las .aspx así:

....

<%=  this.RenderComponent<datecomponentcontroller>
( c => c.Show("Today", DateTime.Today() , true ))%>

...

Bueno la seguimos en el próximo post.

NHGenerator ve la luz

Para aquellos que les aburre como a mí escribir los mappings de nHibernate, deje una demo tan temprana, que casi es una prueba de concepto, de NHGenerator, una herramienta que espero evolucione, guste y fundamentalmente acorte nuestros tiempos de desarrollo.
NHGenerator es una herramienta que esta inspirada por las mismas ideas que exprese cuando presente a Quetzal, y que las podrán leer en post anteriores aunque bajo el nombre de Automation.NH.
Utilice para la demostración los test del proyecto uNHAddins , indispensables para encarar cualquier proyecto con NHibernate.
Hasta ahora he implementado los test que implicaban los mapeos mas básicos "Master-Detail", "one-to-one", "many-to-one" y "component", quedando como paso importante los mapeos de herencia.
Cabe aclarar tambien que no he tenido tiempo todavía de probarlo en dominio "complejos".
Espero sus comentarios.

Prism y nuestro IDE

Me entere que Mozilla había "relanzado" una especie de "Firefox-light", es decir un Firefox que permite correr un solo sitio , impidiendo la navegación por otras urls. La aplicación se denomina ahora "Prism", y antes era conocida como "WebRunner".

Leyendo sobre las ventajas (menor consumo de recursos, mayor seguridad, etc.) se me ocurrió que podía ser el compañero ideal de nuestro "IDE" para desarrollar sitios web y no esperar tanto cada vez que "recargabamos" el proyecto. Así que lo puse a prueba con VS2005 y anduvo bárbaro, cargando como esperaba "muchísimo" más rápido el proyecto para debuguear.

Para hacerlo procedan así

1. Generen un "Acceso directo" con Prism con el URL de su aplicación por ej: "http://localhost:4401/Website/Default.aspx".
2. luego tomando de la hoja de propiedades del Acceso Directo que genero Prism los valores del campo "Destino"
   
   

3. configuren en las opciones de Inicio en el menu WebSite de VS2005, poniendo en este caso en el campo de
   "Start external program": C:\Archivos de programa\Prism\prism.exe
   y en el campo "Command line argument": -webapp TestPrisma@prism.app
   
   
4. Aplicar, y listo.
   

Agradecimiento y deuda

Hoy abro el correo de la lista de arquitectura del MUG y encuentro el post que escribío Angel sobre la charla que dio el viernes y que ya les comente . Y me llevé la grata sorpresa de ser citado en él, y en su blog, lo cual le agradezco.
Próximamente subire una version mejorada de "templates compilados" para aclarar un poco màs el asunto

Templates compilados?

Hoy, luego de asistir a una charla en el "MUG" dictada por el "maestro" Angel sobre generación de código y su excelente "ajgenesis", me quede "tildado" en la relación entre templates, código "vivo" y su actualización de forma dinámica. Ya que uno de los grandes problemas de la "generación de código" es la actualización del código generado, sobre todo si estamos produciendo software de una forma incremental. O sea, si actualizamos el "template", como "brodcastiamos" o difundimos eso en el "código" ya generado, y por sobre todo no pisamos el "ajuste fino" que hicimos sobre él.

Por otro lado, habitualmente para generar un template en alguna herrmienta de generación de código lo que hago es reemplazar las partes "variables" de un codigo en el lenguaje original que estoy trabajando y lo reemplazo por los token que me da el generador. O sea algo así:

"EditPersona" se transforma en "Edit${NombreEntidad}".

Esto implica abrir el notepad buscar "Persona" y reemplazarlo por "Edit${NombreEntidad}". Esto sucede cada vez que cambio mi código "fuente", o sino debo agregar a "pelo" en el template lo que modifique sin garantía de que este código este compilado. Demás esta decir que si son muchas las variables a reemplazar y muchos los templates a actualizar el trabajo se torna largo, y tedioso.

Lo ideal sería entonces que:

1. El template "compilara".
2. Que en el proceso de re-generación no pisará nuestro "ajuste fino".

Lo que les dejó aquí es una especie de "prueba de concepto" que me gustaría profundizar con la opinión de ustedes. Solamente atacá el primer problema, ya que es un mero ejemplo que más que ofrecer una solución lo pongo para explorar una idea. Esta realizado simplemente con NAnt y algún "truquillo" en el código c#.

Para usarlo simplemente tenemos que respetar que las variables/string que queremos reemplazar empiezen con "_" y terminen con "0", (se pueden elegir otros que c# permita) , lanzar el build de NAnt (GeneraEntidad) y luego recargar el proyecto. El único problema es que deberán comentar el código de cada generación de entidad ya que NAnt NO "puede"!!! sobreescribir sus propiedades.

Los comentarios estan abiertos para opinar