Posts Tagged ‘.net’

Crear PDFs del lado del servidor: iText y FPDF

marzo 7, 2008

Armando un form super largo que después tenía que salir por impresora se me presentó la dicotomía: OpenXML o PDF.

Necesitaba soporte para headers y paginación. Que el documento de salida fuera editable no era necesario.

Estaba en .NET, razón por la cuál OpenXML hubiera sido la opción más razonable. A poco de andar terminé encontrando que utilizar Word a través de COM no era nada recomendable del lado del servidor. Necesitaba entonces una biblioteca que maneje el tema. Me encontré con una paga a la cuál no voy a linkear, porque le sobran links de entrada. Microsoft ofrece una biblioteca para generar OpenXML pero genera documentos para Office 2007. No todo el mundo tiene Office 2007, razón por la cuál el camino del OpenXML se iba cerrando. La última opción era generar el doc, guardar como Office XML 2003 y parsear el documento mediante XML o tags. El documento terminaba pesando 900 KB, inaceptable para un ambiente con concurrencia.

Bueno, hubo que tomar el camino del PDF…Yo había hecho algo parecido en PHP con una biblioteca que se llama FPDF. Es una clase PHP 4.0 sencilla pero muy potente para generar PDFs. Lo bueno es que hay un montón de ejemplos en su sitio y hay documentación en español. Lo malo es que es un poco tosca, pero es muy fácil de extender. El enfoque es como trabajar con un lienzo (canvas para la muchachada) donde vamos dibujando nuestras genialidades.

El drama era que había que conseguir algo parecido y allà GPL para .NET. Me encontré con iTextSharp. iText es una biblioteca para generar PDF en java. Muy completa, también es un lienzo pero tiene estructuras como párrafo, frase y pedacito (Paragraph, Phrase y Chunk) y una completa implementación de tablas. Esto permite simplificar muchas tareas que en FPDF me costaban bastante. La biblioteca está muy bien hecha y facilita mucho trabajo. A su vez permite acceder al contenido del pdf a bajo nivel de una manera muy sencilla.

Por si fuera poco hay un tutorial para iTextSharp muy sencillo y elocuente para el desarrollador en apuros, al igual que en FPDF. Lo único que se añora es que no esté en español.

Los autores Bruno Lowagie y Paulo Soares(responsable del port a .NET) han hecho un gran trabajo. Hay un libro muy interesante llamado iText in Action. El libro a través de un caso ficticio -pero muy parecido a lo que pasa en realidad- va cubriendo todas las funcionalidades de la biblioteca y trae piezas de código muy interesantes.

En esencia la biblioteca nos permite generar un pdf en 5 pasos básicos:

  • instanciar un objeto Document
  • generar una instancia del PdfWriter y asociarla a un canal (stream)
  • abrir el documento
  • insertar el contenido
  • cerrar el documento

Nuestro trabajo será esencialmente generar el contenido, porque todo lo demás ya nos los provee la biblioteca.

A su vez tiene un modelo de eventos para la documento, página y tabla. De esta manera podemos generar encabezados y pies de página dinámicos, centralizar los estáticos, etc.

La verdad es que fue una grata sorpresa encontrar la biblioteca esta. Mi solución terminó siendo un HttpHandler que genera los pdfs con iTextSharp. El archivo pesa 40 KB. El mundo ha sido salvado nuevamente. Diós está en el Cielo, todo está en en la Tierra.

ASP.NET MVC

enero 19, 2008

Anoche fui a una TechNight de Microsoft donde presentaron ASP.NET MVC. Los chicos que dieron la exposición estuvieron muy bien, y que haya habido cerveza y papas fritas a la salida me pareció un gran gesto. Eso y los ojos de una muchacha que andaba dando vueltas por ahí, azules como el cielo de este hermoso día.

Mi pregunta era como habían hecho las cosas… No las hicieron mal, solo que las hicieron igual… ¡Ejemplo del blog con comentarios incluido!

Igual a Ruby on Rails, a Monorail, a CakePHP, a todos los frameworks MVC, pero con las tecnologías de VS 2008. Como ORM utilizan LINQ, como API para Sindicación usan WCF, etc.

Algo muy positivo es que los módulos que componen el modelo se comportan como módulos realmente y son intercambiables.

Tiene un router de urls, expresiones regulares para validar. ¡Está todo!

Tal vez lo más interesante sea en que cada parte sea implementada como una interfaz, permitiendo implementar las propias, hacer mock-objects, utilizar sistemas de templates como los de MonoRail o implementar el propio sistema de Ruby On Rails. Es muy flexible en eso. Esto para integrar aplicaciones ya desarrolladas es un golazo.

Otra ventaja -que al programador asp.net medio no le parece tal- es que se van el viewstate y el postback. ASP.NET depende mucho de estas cuestiones y ahí es donde se complican la mayoría de las páginas. Haber transportado el esquema de eventos de Visual Basic a la web es algo que ayuda mucho a acortar la curva de aprendizaje para pasar de una tecnología a otra, pero los dolores de cabeza empiezan cuando hay que hacer cosas en AJAX, o necesitamos manosear el DOM desde javascript. Se puede calcular o directamente obtener el id del DOM de los controles. El drama es cuando estos son generados como ItemTemplates, hay que hacer alguna chanchada. El esquema es bueno en una aplicación de escritorio, pero en web es muy pesado. Esto lleva a que todos los controles que dependían del viewstate y del post-back hayan quedado, bueno, “deprecated”. Tendrían que haber visto como se puso la monada cuando los chicos tuvieron que avisar que el GridView no iba más. AJAX.NET también se ve comprometida.

Tranquilos muchachos, están los Helpers de la UI para generar nuestros nuevos controles. En vez de Viewstate usamos el cache del lado servidor. Es programar un poco más, pero podemos armar nuestro propio Viewstate usando la Cache. Y ganamos obteniendo páginas y sesiones más livianas.

Con .NET 3.5 hay variables tipadas dinámicamente, saludando al variant de VB. Sinceramente, si no era porque las variables NO empezaban con $, hubiera jurado que estaba viendo código PHP y templates de CakePHP en Visual Studio 2008.

Otra cosa es que IIS 7 ya permite Rewrite Rules o algo por el estilo. Lo que nos permite hacer la magia de las urls amigables a la intuición del usuario y a los buscadores.

La verdad es que me parece muy bueno que ASP.NET provea la posibilidad de trabajar con MVC, al margen de que yo lo haga. Le da al desarrollador un enfoque nuevo muy útil en varios escenarios.

Espero que le den para adelante, porque se va a ganar mucho en flexibilidad y legilibidad del código. Pero tal vez lo mejor es que trabajar con MVC nos ayuda a identificar mejor los requerimientos de nuestra aplicación y trabajar en función de ellos. Después si tiene que salir en ATOM, XHTML o código morse ya es problema de la vista y sus helpers. Nosotros tenemos nuestro controlador que hace el trabajo importante.

Yo voy a seguir firme junto a PHP5, SPIP y CakePHP en trabajo independiente, dado que no tengo un IIS7, ni plata para comprar un módulo ISAPI de redirección para IIS6 (otra cosita que tuvieron que contar los chicos), pero ASP.NET MVC sería mi “weapon of choice” a la hora de trabajar en web con .NET.