José Selesan

ASP.Net MVC, routing y URL amigables

2008-11-26T15:15:00.003-02:00

Creo que una de las cosas que más le gusta a los webmasters son las URL amigables, por todo el tema de Google y de posicionar la página. Para los que no saben de qué estoy hablando, lo resumo fácilmente: una URL del tipo www.dominio.com/productos?id=4525 no dice mucho en sí misma sobre qué es el producto y es difícil de recordar, por eso se dice que "no es amigable", una URL amigable en cambio, sería de la forma www.dominio.com/catalogo/navegadores/gps-nuvi-200. En esta url claramente vemos que se trata de un producto dentro de la categoría "navegadores" y su descripción es "gps-nuvi-200". Además de ser lindas para los simples mortales, las URL amigables son muy buenas para los motores de búsqueda. En wikipedia hay más información (note usted la URL amigable en la mismísima wikipedia).

Ahora bien, implementar URL amigables en ASP.Net nunca fue tarea fácil hasta la llegada de ASP.Net MVC. Con este nuevo framework podemos crear rutas, que no son más que formas de indicarle al motor como traducir una url en una llamada a una acción de un controlador.

Para ilustrar mejor vamos a ver un pequeño ejemplo. Supongamos que tenemos un controller llamado ProductosController, con una acción llamada Ver que tiene como objetivo mostrar un producto cuyo código único recibe como parámetro. Sin usar rutas, una url típica sería de la forma /productos/ver/4525. Vamos entonces a crear una ruta para hacerla más amigable.

En ASP.Net MVC, las rutas se registran en el evento Application_Start y se evalúan de la primera a la última, cuando una corresponde ("matchea" se podría decir, aunque no me guste hablar así) con la url, es esa la que se usa. Para nuestro caso, la ruta quedaría así:

routes.MapRoute(

"Catalogo",
"catalogo/{id}/{descripcion}",
new { controller = "Productos", action = "Ver", id = 0 },
new { id = @"\d+" }

)

El primer parámetro es el nombre de la ruta (que debe ser único", el segundo es el patrón de la url y el tercero es el que indica los valores por defecto. El cuarto parámetro lo veremos luego. En los valores por defecto le estamos diciendo que si no puede detectar el nombre del controlador en la url, que use "Productos" y que si no puede encontrar la acción, que use "Ver". Con esta ruta, al llamar a la url /catalogo/4525/gps-nuvi-200 en realidad se estará llamando al método Ver de la clase ProductosController, pasandole el valor 4525 como parámetro.

Vamos a hacer un poco más interesante la url. Supongamos que queremos dar la posibilidad de colocar la categoría del producto en la url, o sea algo de la forma /catalogo/navegadores-satelitales/4525/gps-nuvi-200. Para hacerlo, basta con agregar otra ruta más de la siguiente forma:

routes.MapRoute(

"CatalogoConCategoria",
"catalogo/{categoria}/{id}/{descripcion}",
new { controller = "Home", action = "Prueba", id = 0 },
new { id = @"\d+" }

);

En esta nueva ruta, hacemos casi lo mismo que en la anterior, con la diferencia que ahora estamos esperando urls con la categoría antes del ID de producto. Lo importante de esto es el cuarto parámetro que no expliqué hoy. Ese parámetro no es más que una restricción sobre los elementos de la URL, y le indica al motor de ruteo que la url corresponde con esa ruta si se cumple esa condición. En nuestro caso, le estamos diciendo que el ID debe ser un número. Esto es muy importante porque si no lo hacemos, al recorrer las rutas en orden, el motor tomaría la categoría como ID de producto, dando un comportamiento que no es el esperado.

Error inesperado

2008-11-14T21:56:00.002-02:00

Por esas cosas locas que tiene el destino, saqué de nuestra biblioteca una vieja edición de "Sobre héroes y tumbas" y entre sus maravillosas páginas había un pequeño trozo de papel escrito por mí y que quizá en su momento sirvió de señalador, con el texto "A class named TInterfacedPersistent already exists", y se me dió por pensar no sólo los años que debe llevar eso ahí, sino también por qué lo abré anotado y en qué habré estado trabajando en ese momento. Por la T al principio del nombre de clase se me ocurre que es Delphi, pero vaya uno a saber.

Es interesante lo que uno puede encontrar abriendo un libro...

Advantage Database Server y ASP.Net 2.0

2008-11-14T16:23:00.002-02:00

Estoy trabajando en una aplicación web con Visual Studio 2008 y Advantage Database Server como motor de base de datos y ocasionalmente, al ejecutarla obtenía un error diciendo que no se podía hacer un typecast entre el tipo de dato System.Web.Compilation.BuildResultCompiledAssembly y el tipo System.Web.Util.ITypedWebObjectFactory. Lo extraño es que recargando la página en el browser con Shift presionado para que la traiga toda de nuevo, funcionaba bien.

Buscando un poco en internet, encontré este KB de Microsoft donde explican las causas y la solución. Aparentemente no le gusta mucho tener ensamblados satélite con información de cultura, así que mirando las propiedades de cada assembly de mi solución, encontré que las causantes del problema eran tres dlls que necesita el provider de ADS para .Net: ace32.dll, adsloc32.dll y axcws32.dll. Después de colocarlas en una carpeta llamada en-US dentro del bin, todo funcionó de diez, y fuimos felices.

ASP.Net MVC y la extensión .mvc

2008-10-30T14:30:00.004-02:00

Como ya deben saber quienes probaron el framework MVC de la muchachada de Microsoft, viene con un motor de ruteo y la posibilidad de usar urls sin extensión, lo cual las hace bastante amigables (por ejemplo: http://sitio/productos/ver/1). Sin embargo, esta última opción solo está disponible (al menos de forma nativa) solo en IIS 7, o sea Windows Server 2008. Para poder correr una aplicación ASP.Net MVC en IIS 6 es necesario que las urls tengan la extensión en la parte del controlador (o sea, algo de la forma http://sitio/productos.mvc/ver/1). La extensión más usada por el momento es mvc, y para que esto funcione, se debe la mapear en IIS con la aspnet_isapi.dll así es el framework el encargado de procesar la solicitud.

Cuando lo hice por primera vez, fui entusiasmado a correr la aplicación en el server y me encontré con un error 404, lo cual no podía ser porque la url era totalmente válida y el sitio estaba montado correctamente. Después de varias pruebas y naufragios por google, encontré que la forma de que funcione es desmarcando el check "Verificar que el archivo existe" en el diálogo de mapeo de la extensión mvc, para que el IIS no restringa las solicitudes solo a archivos existentes:

Hecho esto, el sitio funciona bien. Próximamente voy a tratar de usar urls sin extensión en IIS 6 mediante el agregado de un módulo de reescritura (al estilo mod_rewrite de apache), porque sinceramente este tipo de urls me atraen más que las que tienen extensión, por lo mismo que dije antes.

Scrum y XP desde las trincheras

2008-10-29T16:01:00.002-02:00

El título del post corresponde a un libro muy interesante sobre gestión ágil de proyectos. Si bien es un libro bastante corto, lo que lo hace interesante es que no se va por las ramas con mucha teoría de metodologías y demás yerbas sino que trata una serie de consejos prácticos de manera tal que el lector pueda comenzar a utilizar técnicas ágiles apenas leidos unos cuantos capítulos.

El libro se puede comprar impreso, o bien puede ser descargado de aquí
Quienes no estén muy familiarizados con el inglés, podrán encontrar una traducción (no la leí, así que no puede decir si es buena o no), aquí, y despues contarme qué le pareció el libro.

5 Estrellas Platinum

2008-10-23T13:59:00.004-02:00

Hace unos días salió a la luz la esperada 5ta estrella de Platino del programa de capacitación Desarrollador Cinco Estrellas.

Para alcanzarla se debe tener la 5ta estrella dorada y rendir al menos un curso más, entre dos disponibles: Linq y Silverlight 2.0. Como siempre, el material me parece bastante escaso, aunque hay que reconocer que para un desarrollador que ya llegó a esta instancia del curso, solo necesita una introducción para entender un tema y luego investigar por su cuenta para profundizar y lograr los conocimientos necesarios para utilizarlo en el trabajo diario.

ASP.Net MVC + System.Linq + Tipos Anonimos = Soluciones Elegantes

2008-10-03T14:40:00.005-03:00

Hace poco me encargaron el desarrollo de una pequeña aplicación web de uso interno, así que como era un proyecto de bajo riesgo y pocas líneas de código, aproveché para hacerlo con ASP.Net MVC, para aprenderlo y usarlo (ya hice varias aplicaciones con Monorail y necesitaba tener mas herramientas para comparar con el nuevo framework MVC de los muchachos de Microsoft).

Antes de abordar el tema que motivó este post, algunas consideraciones sobre ASP.Net MVC:

Es excelente el soporte de intellisense para la edición de vistas, lo que facilita mucho la curva de aprendizaje.
Me pareció atinado el uso de ActionResult como resultado de las acciones, ya que permite hacer mejores aserciones en los tests unitarios (recordemos que las acciones en MonoRail son void)
No me pareció tan buena la asociación entre las vistas y la master page. Esto dificulta un poco el uso eventual de ajax. No prové las extensiones que provee MvcContrib, que implementa un atributo Layout al modo Monorail, pero parece que ayuda.
Es fantástico el uso que le dan a los métodos de extensión, que permite agregar lo que necesitemos a los helpers predefinidos
También me pareció acertado el uso de Generics y de expresiones Lamda en algunos metodos de los helpers. Por ejemplo, al definir un form con el HtmlHelper, podemos hacer Html.Form(p => p.MiAccion() ). La gran ventaja de esto, además del intellisense, es la facilidad de refactoring, ya que estamos referenciando tipos y métodos de las clases y no cadenas de caracteres que no representan anda para el IDE ni para el compilador.

Un poco de magia

Volviendo al tema que da título al post, voy a contar qué tuve que hacer y como lo solucioné. Cuando ya tenía lista la aplicación, me pidieron que se pueda exportar a Excel el resultado de un par de reportes. Inmediatamente recordé como lo hacía con webforms, renderizando la grilla directamente al stream y cambiando un par de headers, pero cuando comencé a pensar como trasladarlo al patrón MVC las cosas se complicaron. Después de un rato en Google, encontré este excelente post que me salvó la vida (y le dio otro punto a favor a los ActionResult, ya que hace uso extensivo de la herencia sobre ese tipo).
Obviamente lo primero que hice fue bajarme el código, buscar las dos clases que necesito y agregarlas a mi proyecto. Luego de hacerlo, me puse a ver en más detalle el código y me enconté con que no me servía así como estaba, ya que usaba Linq to SQL y mi proyecto usa ActiveRecord, así que en vez de tener un IQueryable, tenía un IList. Aquí empieza a aparecer la magia, ya que simplemente agregando un using a System.Linq, me apareció el método de extensión AsQueryable() en la interfaz IList, así que pude pasar el parámetro que necesitaba. Hecho esto, tampoco me funcionaba, ya que la clase usaba el mapping de Linq to SQL para descubrir las propiedades o nombres de las columnas para armar la tabla en Excel. Solución rápida: el siempre querido Reflection para indagar las propiedades del tipo de dato guardado en el IList.
Listo, con eso la exportación funcionó bien, pero con un pequeño detalle. Aquellas propiedades que eran un tipo de dato complejo (una clase), se exportaban como el nombre del tipo y no el valor que yo quería. Por ejemplo, la entidad tenía una propiedad del tipo Usuario, y se exportaba como MiEspacioDeNombres.Usuario, en vez de exportar el nombre del usuario. Y acá aparece la potencia del framework 3.5 en todo su explendor, simplemente haciendo una consulta Linq sobre el IList y devolviendo objetos de tipo anónimo con las propiedades que quiero exportar ya resueltas:
var lista = from p in miListado select new { Propiedad1 = p.P1, Propiedad2 = p.P2, Usuario = p.Usuario.Nombre }

Esto es todo. Simplemente quedé asombrado por las posibilidades que brindan las nuevas características del lenguaje en el framework 3.5 para resolver de manera elegante cuestiones que surgen cuando ya se tiene la aplicación diseñada y no vale la pena hacer mucho refactoring.

Javascript, ASP.Net Ajax y arreglos clonados

2008-05-07T13:50:00.002-03:00

Para un desarrollo con ASP.Net Ajax necesitaba poder clonar un arreglo devuelto por un webservice (en realidad acabo de aprender que los arreglos en javascript son tipos por referencia). Fue así que después de algunos intentos de escribir una función, opté por buscar en Google y encontré esta opción:

Object.prototype.clone = function () {
var o = new Object();
for (var property in this) {
o[property] = typeof (this[property]) == 'object' ? this[property].clone() : this[property];
}
return o;
}
Array.prototype.clone = function () {
var a = new Array();
for (var property in this) {
a[property] = typeof (this[property]) == 'object' ? this[property].clone() : this[property];
}
return a;
}

Cuando la voy a probar, descubro que la clonación en profundidad (deep clone) la hace perfectamente, sin embargo, por alguna extraña razón que después de una mañana completa no logré comprender, no se lleva bien con los scripts que genera ASP.Net Ajax, y da un error bastante extraño y hace que dejen de funcionar algunas cosas de Ajax. Cosa e' Mandinga. Primero pensé que era un conflicto de nombres, así que le cambié el nombre "clone" por "clonar", y tampoco.
Resumiendo, como necesitaba avanzar con el desarrollo, hice un segundo intento con el amigo Google y encontré esta función acá: http://bytes.com/forum/thread715567.html

Funciona a la perfección, y no se lleva mal con ASP.Net Ajax. Es así el mágico mundo de la programación.

Programar para Web es facil

2008-04-18T16:20:00.002-03:00

A esta altura ya me da pena ver como algunos programadores jóvenes (entiéndase programadores que se están iniciando), desembocan la mayoría de las veces en soluciones muy complejas a problemas simples.

¿Por qué? Por supuesto que la respuesta no la tengo, pero quizás una aproximación, y es esta: el modelo de Webforms de ASP.Net hace complejo un protocolo simple (como lo es el HTTP).

Me explico un poco mejor. El principal objetivo "marketinero" de los webforms fue acercar a los programadores de aplicaciones de escritorio al desarrollo web. Para ello, dotaron a ASP.Net de un complejo ciclo de vida de las páginas, eventos y controles, todo para que los webforms se parezcan lo más posible a los winforms. Y lo que consiguieron es que gente que nunca programó en web comience a hacerlo, pero a hacerlo al estilo windorms. Es así como hoy vemos programadores Web que no saben como funciona HTTP, incluso algunos que no distinguen cuándo están corriendo en el servidor y cuándo en el cliente. Y ni hablemos del mal uso de la sesión, al punto de degradar la aplicación o hacer que los usuarios pierdan trabajo cuando actualizan una dll del stio.

Hace poco vino un compañero de trabajo a hacerme una pregunta extraña sobre la relación entre el esquema del documento HTML y los Themes de ASP.Net 2.0. Como la pregunta me dejó medio descolocado, empecé a indagar para saber cuál era el problema real. Y el problema real era que quería usar un botón que había programado alguien y aparentemente no se llevaba bien con los temas. Mi sugerencia entonces fue, que si ese botón no funcionaba, que ponga un link o un botón común, a lo que me respondió que no le servía porque tenía que cambiarle el texto del lado del servidor, porque en un momento servía como botón "Buscar" y en otro como botón "Volver". La primera solución que se me ocurrió fue simplemente usar dos páginas distintas, una con los filtros y otra con los resultados de la búsqueda. Y ahí fue donde me dí cuenta del título de este post: "Programar para la web es fácil, si se piensa en web".

Mis consejos para los nuevos programadores (y para los no tan nuevos) que quieran desarrollar aplicaciones basadas en la web son estos:
- Conocer como funciona el protocolo HTTP
- Saber que aunque los webforms no lo permitan se puede tener más de un tag "form" por página
- Saber que se puede trabajar con .Net para la web sin usar los odiosos webforms (estudiar por ejemplo MonoRail o ASP.Net MVC)
- Buscar siempre la solución más sencilla que funcione. Si algo no se puede resolver de una manera, tirarlo y buscar otra solución

Inyección de dependencia en Enterprise Library

2008-04-15T11:06:00.003-03:00

Según publicó InfoQ en este artículo, Microsoft implementó una librería para inversión de control e inyección de dependencia, que va a salir junto con la nueva versión de Enterprise Library.

Pareciera que los muchachos de P&P se están avivando de qué es realmente lo que se necesita a la hora de crear una aplicación con una buena arquitectura, y ya se copiaron (porque realmente es así) dos de los componentes del Castle Project, como ser MonoRail para el desarrollo web con MVC y Windsor/Microkernel para la inyección de dependencia. Lo que no termino de entender es cómo para algunas cosas van tan rápido (como las nuevas versiones del framework .net) y para otras van tan lento (recordemos que el proyecto Castle tiene ya un buen tiempito y está bastante maduro aunque no tenga un release formal).

Creo que ya no quedan dudas de que por la plata baila el mono.

5 Estrellas .Net

2007-12-17T21:56:00.000-03:00

Bueno, eso, que desde hace unos días tengo las 5 estrellas del programa Desarrollador 5 Estrellas. Para alcanzarla hay que rendir temas de Framework 2.0 y 3.0.

He aquí el diploma:

Libro

2007-11-14T19:32:00.000-03:00

Me había olvidado! Para los que aún no lo saben, ha salido a la calle un libro de mi autoría. Es una guía básica de introducción a la programación. Se abordan brevemente temas desde la resolución de problemas y algoritmos hasta UML, pasando por la programación estructurada y lógicamente Orientación a Objetos.

La imagen muestra la tapa. Como siempre, haciendo click podrán ampliarla. Sobre el logo de Visual Studio está mi nombre!

Primeras impresiones de ASP.Net MVC

2007-11-14T18:24:00.000-03:00

En estos días, Scott Gu publicó un breve tutorial sobre el nuevo framework de Microsoft para desarrollar aplicaciónes ASP.Net siguiendo el patrón MVC.

Como ya noté en mi anterior post sobre el tema, el parecido con MonoRail es realmente impresionante. No encontré un aspecto de la implementación de Microsoft que no esté ya soportado en MonoRail. Si se da la opuesta, hay varios detalles de MonoRail que aun no existen en ASP.Net MVC, como por ejemplo el SmartDispatcherController, aunque según Scott lo van a implementar antes de sacar el release del framework. Tampoco hay aun un soporte para Ajax.

Un aspecto en el que "se parecen mucho" (no quiero decir que el equipo de Scott haya copiado a los amigos del proyecto Castle, pero...) es la clase Html, que según se puede ver en el ejemplo, viene a cumplir el mismo objetivo que el HtmlHelper de MonoRail.

Hay algunas cosas que vi y no me gustaron. Una de ellas es la necesidad de especificar en la vista el tipo de datos del objeto que se va a usar para pasar información desde el controlador a la vista (lo que sería el PropertyBag de MonoRail). Obviamente esto da la ventaja del IntelliSense en las vistas, pero igualmente no me convence, creo que es más lo que se pierde que lo que se gana. Otro aspecto que no me gusta del todo es el hecho de poder usar WebControls en las vistas. ¿En qué baso mi postura? En que para interactuar con los WebControls hay que acudir al code behind de la página. Esto puede confundir un poco, haciendo el código menos legible, ya que al código del controlador y al de la vista, se agrega el del code behind. Además existe el riesgo de que un programador poco experimentado termine escribiendo lógica de la aplicación en los manejadores de eventos de los controles, rompiendo claramente el patrón.

Bueno, ¿como sigue esto? Seguiremos esperando la salida del framework para juzgarlo con más herramientas que un simple artículo.

MVC en ASP.Net

2007-10-17T19:42:00.000-03:00

Hace algunos días ScottGu publicó este post sobre el nuevo framework de MVC en ASP.Net. Por la imagen que se ve en el post, sigue una estructura muy similar a la de MonoRail, en cuanto a la organización de las carpetas. Todavía no se lo puede bajar para ir viéndolo en acción y tampoco vi los videos donde lo muestran, pero se me vienen algunos pensamientos a partir de la imagen del post:

Al parecer ya hay soporte para pruebas unitarias sobre los Controllers, veremos si es tan bueno como MonoRail (o mejor)
Me inquieta ver como relacionan el modelo de ejecución de los webforms, con sus postbacks y su ciclo de vida complejo con las acciones de los postbacks
Según un comentario que se ve por ahí, a traves de plugins se va a poder usar cualquiera de los engines de renderización de vistas implementados para MonoRail. Eso está bueno!

Seguiremos esperando y cuando se pueda hacer alguna pequeña aplicación, trataré de hacer una comparación con MonoRail

Separación de responsabilidades

2007-10-09T11:07:00.000-03:00

Hace unos años (unos cuantos), cuando comencé a programar, aún no se hablaba mucho y no había suficiente documentación ni experiencias sobre separación de responsabilidades a la hora de escribir el código, entonces en el mismo archivo teníamos la lógica para actualizar la interfaz, para validar reglas de negocios y para manipular los datos.

Con el tiempo, sobre todo ahora con el auge de los blogs, creo que ya se sabe que si se quiere lograr una base de código sólida, mantenible y bien estrucutrada, debemos separar por un lado los datos (que pueden estar en un SGBDR), la lógica de negocios, la lógica de actualización de la interfaz y la interfaz con el usuario propiamente dicha. Existen patrones y técnicas que colaboran en cada uno de estos aspectos, desde la separación en capas hasta el MVC o el MVP.

Sin embargo, aun hay gente que hace cosas horribles, sin analizar un solo instante las implicancias de lo que está escribiendo o quiere escribir. Por ejemplo, hoy vi algo que me dejó con la boca abierta, por decirlo de una manera. Me mostraron el código de un trigger en SQL Server, que se encargaba de generar código JavaScript en base a campos de alguna tabla y lo insertaba en otra, para luego tomarlo directamente en una interfaz ASP.Net. Es decir, lógica de interfaz almacenada en la base de datos.

Le pido a los programadores nuevos: nunca una urgencia debe atentar contra la calidad del código, recordemos que como programadores, el código fuente es el principal documento que tenemos, y que si lo hacemos bien, nos va a evitar más de un problema. Pensemos simplemente que pasa si alguien que nunca tocó esa aplicación, debe corregir un error en el código javascript. ¿Cuánto tiempo le puede insumir llegar hasta el trigger para encontrar el problema? Con suerte, unas cuantas horas, cuando debería haberlo encontrado a los pocos minutos si estuviese donde tiene que estar.

Regreso

2007-10-09T09:54:00.000-03:00

Después de un tiempo de inactividad, estoy tratando de volver a escribir un poco más y con mayor frecuencia. En este tiempo he estado trabajando y escribiendo sobre tecnlogías que si bien no son novedosas (particularmente MonoRail y todo el proyecto Castle), siempre es bueno compartir experiencias.

Así que aquí estaremos, tratando de aportar un granito más de arena a la gran montaña de confusión que es el mundo del desarrollo de aplicaciones de software.

Performancing en FireFox

2007-02-23T20:48:00.001-03:00

Cada día que pasa me gusta más Firefox. Hoy descubrí un addon que se llama Performancing. Este addon es simplemente un editor para postear en blogs. Qué es lo más interesante? pesa alrededor de 200 kb, se baja en segundos y se configura muy fácil. Acabo de bajarlo y en menos de un minuto ya lo tenía configurado para postear en Blogger.

Hay que reconocer que la gente que está trabajando alrededor de Firefox, está haciendo un trabajo espectacular.

Este post fue enviado con Performancing

ASP.Net Ajax ya es release

2007-01-24T09:05:00.000-03:00

Así lo anunció ayer Scott Gu' anunció el lanzamiento de la versión 1.0 de ASP.Net Ajax, junto con la correspondiente versión 1.0 de ASP.Net Ajax Toolkit, que incorporó tres controles interesantes: un textbox con calendario (esto se podía simular con las betas y el RC usando el PupUpExtender, pero había que poner algunas líneas de código), un control tipo TabStrip a puro javascript y un MaskEdit para restringir el ingreso de datos, para alegría de los programadores de la vieja escuela (leáse de Clipper, Fox y demás).

Como siempre, la página oficial de ASP.Net Ajax está acá.
El post de Scott con el anuncio, lo pueden encontrar acá

El tamaño sí importa

2007-01-18T08:59:00.000-03:00

Cada vez que tengo que mantener código de otro, o ayudar a alguien con algún fuente, insisto en lo mismo: escribir métodos pequeños. Me he encontrado con métodos de más de 2000 líneas. En este post en Object Mentor, se comentan algunas de las razones por las que el tamaño de las clases y métodos sí importa, junto con las implicancias que tiene el código demasiado largo.

Separación de UI y Logica en Ajax

2006-10-23T08:27:00.000-03:00

Algo que ya muchos criticaron sobre Ajax (en particular sobre Ajax Library, o sea ATLAS) es que implica un uso bastante intensivo de JavaScript del innerHTML para actualizar la UI luego de llamar a WebServices desde el lado del cliente.

En respuesta a eso, Scott Gu escribió este excelente post con una propuesta de solución que me pareció muy buena. Sin embargo, despues de bajarme el codigo y darle una mirada, veo que hace uso de Reflection para pasarle datos al control que usa para renderizar la vista. Todos sabemos que Reflection es una gran herramienta, pero puede tener algunos problemas de redimiento y que deberíamos evitarlo siempre que sea posible. Y en este caso es posible.

Mi solución es la siguiente. Por un lado, definir una interfaz que exponga una propiedad para pasarle los datos al control:

public interface IDataView
{
object Data { get; set; }
}

Luego, cada control que querramos renderizar desde el ViewManager, deberá implementar la interfaz IDataView:

public partial class App_Views_Customers : System.Web.UI.UserControl, IDataView
{
protected void Page_Load(object sender, EventArgs e)
{
Repeater1.DataSource = Data;
Repeater1.DataBind();
}

private object data;
public object Data
{
get { return data; }
set { data = value; }
}
}

Por último modifiqué la clase ViewManager para que no use Reflection sino que requiera que el control sea también un IDataView:

public class ViewManager
{
public static string RenderView(string path)
{
return RenderView(path, null);
}

public static string RenderView(string path, object data)
{
Page pageHolder = new Page();
UserControl viewControl = (UserControl) pageHolder.LoadControl(path);

SetData(viewControl as IDataView, data);

pageHolder.Controls.Add(viewControl);
StringWriter output = new StringWriter();
HttpContext.Current.Server.Execute(pageHolder, output, false);

return output.ToString();
}

private static void SetData(IDataView view, object data)
{
view.Data = data;
}

}

Con esto, no solo eliminamos el uso de Reflection sino que el código quedó más claro, más OO y al no acceder a un campo por su nombre como variable, quedó más seguro ya que permite verificar todo en tiempo de compilación.

Artículo sobre ATLAS

2006-10-05T20:51:00.000-03:00

Hoy vio la luz el número de octubre de Level Extreme, que en esta oportunidad incluye un artículo mío sobre ASP.Net Ajax Library, es decir, ATLAS.

Fue muy interesante escribir este artículo porque si bien ya hace un buen tiempo que vengo experimentando con ATLAS, solamente había usado los controles del lado del servidor (principalmente el UpdatePanel), y para poder profundizar un poco en el tema, tuve que hacer unas pruebas con web services y realmente me pareció muy cómodo y sencillo de usar.

Variables static en VB.Net

2006-10-04T14:32:00.000-03:00

Hoy me hicieron la siguiente pregunta: "¿Que diferencia hay en Visual Basic .Net entre shared y static?". Como soy un programador de C# y no de ese otro lenguaje feo atiné a responder que static es lo mismo que shared, pero en C#. Pero como mi interlocutor no quedó muy satisfecho con la respuesta, tras unos minutos de lectura me vengo a enterar que en VB.Net, una variable local a un método puede tener el modificador static, lo que hace que mantenga el valor entre llamadas. Es decir, si tenemos algo así:

Public Sub Metodo1()
Static Dim contador as Integer
contador = contador + 1
Console.WriteLine(contador)
End Sub

Public Sub Metodo2()
Metodo1()
Metodo1()
End Sub

Como resultado, tendremos en la consola los valores 1 y 2, ya que la variable "contador" mantiene su valor entre una y otra llamada al método.

Ahora bien, ¿de que sirve esto en un leguaje orientado a objetos? La misma funcionalidad se puede resolver perfectamente con el uso de un atributo privado de la clase: (lo escribo en C# porque ya fue suficiente VB.Net por hoy)

private int contador;
public void Metodo1()
{
Console.WriteLine(++contador);
}
public void Metodo2()
{
Metodo1();
Metodo1();
}

Obviamente, C# que es un leguaje bien hecho, no tiene un equivalente al static de VB.Net. Esto no hace más que reafirmar mi idea de que VB.Net es un leguaje feo, que arrastra todos los problemas de diseño de un lenguaje de programación desde sus primeras versiones y que permite escribir código muy mal estructurado (y que los programadores de VB.Net de alguna manera u otra se las arreglan para usar todas las cosas de VB.Net que no deberían usar para que el código quede bien escrito).

Estimar tiempos no es como jugar al golf

2006-09-29T15:09:00.000-03:00

Hace unos días empecé a leer Extreme Programming for Web Projects, un librito bastante entretenido y de lecutra liviana que, como su título lo indica trata de como enfrentar proyectos de desarrollo de aplicaciones web siguiendo técnicas de desarrollo ágil.

A grandes rasgos, los temas tratados no difieren en absoluto a los de cualquier libro/articulo/sitio web sobre metodologías ágiles, salvo por los capítulos donde los autores abordan temas relacionados con las particularidades del desarrollo web, como los son el diseño gráfico de la aplicación y el uso de XML.

Hay un capítulo en el que se hace una analogía entre la estimación de tiempos y un juego de golf y quería comentarla porque me pareció interesante el planteo (aunque no sea más que otra forma de plantear el problema que todos conocemos). Parafraseando (y traduciendo) a los autores, pensemos en el desarrollo de software como un juego de golf en el que tenemos un objetivo (el hoyo), pero está bastante lejos y no podemos verlo. Nuestro cliente puede decirnos que el hoyo está a 130 metros de donde estamos, y al centro de un dogleg. Los miembros del equipo ya han jugado al golf antes y nos advierten que en el medio podría haber obstáculos, como lagunas o tramas de arena. Entonces, ¿qué tan fuerte le pegamos a la pelotita?, ¿el viento puede influir?, ¿el cliente realmente sabe donde está el hoyo?, ¿nuestro compañeros de equipo no sabían de un obstaculo que estaba en medio? ¿eh?

ATLAS será release en diciembre

2006-09-12T13:14:00.000-03:00

Así es, finalmente el framework ATLAS verá la luz como un producto con soporte y todo a fines de este año, bajo el nombre de "Microsoft AJAX Library" y el ATLAS Control Toolkit será bautizado formalmente como ASP.Net AJAX Control Toolkit.

Más información en el blog de Scott Guthrie

Otro artículo de Mocks

2006-09-12T08:30:00.000-03:00

Ayer salió el nuevo número de LevelExtreme donde salió publicado otro artículo mío, esta vez sobre pruebas de interacción con mock objects.

Como podrán ver en el artículo, la idea es parecida a la de otros artículos sobre mocks, pero esta vez, lo que se debe probar es que la aplicación reacciona bien ante los datos enviados por una balanza electrónica de camiones y aplica correctamente las reglas de negocios.

Despues de leer el artículo (y dejar algún comentarió acá), los inviton a que le den una mirada al blog del autor de los Rhino Mocks (www.ayende.com/Blog), qué está haciendo un excelente trabajo, en especial con la librería RhinoCommons (que dicho sea de paso, ya recibió algunos aportes míos).