lunes, 15 de diciembre de 2008

Propiedades y métodos públicos en la MasterPage

Este truco ya es un poco viejo, sin embargo, aún puede ser útil para muchos.

En muchas situaciones deseamos exponer propiedades y métodos públicos en la página maestra o página principal para accederlas desde las páginas de contenido. Sin embargo, al hacerlo vemos que no son accesibles. No aparecen en la lista de Intellisense.

Existe una directiva poco conocida llamada MasterType que podemos agregar fácilmente en nuestras páginas de contenido y así poder acceder a las propiedades y métodos públicos definidos en nuestra página maestra.

image

Una vez definida esta directiva podemos acceder en el código por detrás de nuestras páginas de contenido, a las propiedades y métodos públicos de la MasterPage.

image

Enjoy it!

¿Cómo recuperar el objeto DataItem del control ListView?

Cada elemento o fila de los controles de datos como GridView, DataList o Repeater disponen de una propiedad DataItem que permite recuperar el registro de datos enlazado a la lista. Esta propiedad es muy útil para procesar los elementos y controles durante el evento de enlace de datos.

Sin embargo, al trabajar con el control ListView incluído en ASP.NET 3.5 habrán notado que no existe una propiedad similar o equivalente para recuperar los datos del ítem enlazado para procesarlos durante el evento ItemDataBound.

Investigando un poco sobre cómo resolver esta ausencia, encontré una forma poco intuitiva:

image

El truco es que el elemento e.Item de tipo ListViewItem se puede castear a ListViewDataItem y entonces ahí podemos acceder a la propiedad DataItem para luego castearlo nuevamente a la clase de datos que estamos enlazando.

Este doble casting no me agrada mucho, pero es la única forma que encontré para recuperar el elemento de datos que está siendo enlazado al control ListView.

Bueno, espero que sirva y ahorre algunos dolores de cabeza.

Saludos, Gus

domingo, 30 de noviembre de 2008

String Extensions

Como sabemos, los Extensions Methods son una de las nuevas características de C# 3.0. Podemos verlos como métodos estáticos que permiten agregar nuevas funcionalidades a clases ya existentes. No es mi intención explicar cómo crear Extensions Methods (pueden aprender más aquí y aquí), sino compartir varios extensions methods que uso habitualmente en mis proyectos de desarrollo.

Convirtiendo Strings

Convertir cadenas de texto a un número o fecha es una necesidad habitual en todos los proyectos. El código típico es el siguiente:

int number = int.Parse(NumberTextBox.Text);
DateTime date = DateTime.Parse(DateTextBox.Text);

El mismo resultado podríamos obtener usando la clase Convert:

int number = Convert.ToInt32(NumberTextBox.Text);
DateTime date = Convert.ToDateTime(DateTextBox.Text);

En este caso tenemos la ventaja de que si el argumento es null, el valor devuelto es cero. Esto puede comprobarse con Reflector.

image

Ninguno de los métodos anteriores resuelve el problema de conversión de datos cuando el usuario ingresa letras donde se esperaba números o fechas con formatos no válidos.

image

Para evitar esta situación podemos usar validators de ASP.NET, controles de máscara o bien el método TryParse:

int number;
if (int.TryParse(NumberTextBox.Text, out number))
{
    //TODO: Do something
}

El único problema con esta solución es que implica escribir mucho más código, generando rutinas más extensas y difíciles de leer.

La situación se complica un poco más con los Guid, pues no disponen de un método TryParse, entonces habría que usar Try/Catch, lo que complica aún más el código resultante.

String Extensions

Es aquí donde los Extensions Métodos pueden proporcionar una solución efectiva, elegante e intuitiva. La siguiente figura muestra cómo convertir una cadena a un número usando un extension method:

image 

La implementación del extension method es muy simple:

image

He creado una clase StringExtensions.cs con varios extensions methods para convertir a byte, short, long, float, double, decimal, boolean, datetime, guid, etc. Incluí también versiones compatibles con tipos nullables. Seguiré agregando nuevos métodos en la medida que encuentre aplicación práctica y aporten simplicidad en el código.

A continuación les dejo el link para descargar la clase StringExtensions.cs. En próximos post, publicaré otros extensions methods aplicables a controles de ASP.NET. Espero que sirva.

Saludos, Gus

jueves, 27 de noviembre de 2008

Nuevo control de Chart en ASP.NET

La gente de Microsoft ha liberado un nuevo control para ASP.NET 3.5 SP1 y Windows Forms para resolver nuestras necesidades de charting. Thanks!!!

Pueden leer el artículo de Scott Guthrie (en inglés) dando la noticia o si lo prefieren pueden leer la traducción en español de Juan María Laó Ramos.

Pueden arrancar con los siguientes links:

  1. Descargar los controles.
  2. Descargar el soporte para VS 2008 para estos controles.
  3. Descargar los ejemplos.
  4. Descargar la documentación.
  5. Visitar el foro.

Finalmente pueden descargar los recursos en español para estos controles: Paquete de idioma de Microsoft Chart Control para Microsoft .NET Framework 3.5

Y aquí les dejo unos screenshots de los ejemplos. Se ven muy bien!

image

image

image

image

Saludos, Gus

jueves, 20 de noviembre de 2008

Descubriendo Live Mesh

Como comentaba en un post anterior, Live Mesh es una de las aplicaciones de Microsoft que, basado en los servicios de Live Framework, permite en principio una sincronización de archivos simple, segura y transparente entre múltiples dispositivos. Desde computadoras personales, portátiles y dispositivos móviles a cámaras digitales e impresoras, entre otras. Pero Mesh es mucho más que sincronización de datos e iré comentando más en la medida que vaya probando y descubriendo sus bondades.

Por el momento estoy empezando a usar las capacidades de sincronización de archivos de Mesh con amigos y compañeros de proyecto y realmente es muy útil, si bien hoy no es una herramienta de control de versiones con capacidades de merge, etc., la simple posibilidad de tener archivos y carpetas distribuidos y sincronizados entre diferentes dispositivos ya tiene un gran valor.

Instalando Live Mesh

El primer paso consiste en ingresar al sitio https://www.mesh.com y conectarse a Live Mesh usando alguna cuenta de Live ID (por ejemplo una cuenta de Hotmail).

image

Esto significa que no necesito registrarme, completar formularios, etc. Simplemente utilizo mi cuenta de Live ID para Live Mesh.

image

Después del login en Windows Live, veré la página de dispositivos de Mesh. Desde aquí podré agregar mis dispositivos a Mesh. De forma predeterminada, ya existe un Live Desktop listo para usar. Se trata de un escritorio virtual online, donde podré acceder y administrar mis archivos y carpetas disponibles a través de Mesh.

image

Para agregar mi equipo a Mesh, selecciono Add device, y podré descargar e instalar el cliente de Mesh.

image

El cliente de Mesh está disponible para Windows XP y Windows Vista; existe una versión para Mac y, si bien en la página oficial no encontré referencias, me enteré que ya existe una versión para Windows Mobile que pueden descargarla desde https://m.mesh.com

Continuando con la instalación, debemos seleccionar la plataforma correcta y al presionar el botón Install, iniciaremos la descarga de LiveMesh.exe. Su instalación no tiene inconvenientes y dura unos 3 a 5 minutos.

image 

Finalizada la instalación encontraremos en el área de notificaciones el icono de Mesh y deberemos iniciar una sesión con nuestra cuenta Live ID para agregar nuestro dispositivo a la red.

image

El siguiente paso es darle un nombre a nuestro equipo para conectarlo a la red de Mesh.

image

En pocos segundos tendremos nuestro equipo conectado a Mesh y podremos verlo junto a los demás equipos y dispositivos. En este caso solo encuentro mi equipo portatil y el Live Desktop.

image

Y si volvemos a la página de dispositivos de Mesh en la web (https://www.mesh.com/Web/Devices.aspx), veremos nuestro dispositivo agregado al anillo de Mesh.

image

Compartiendo archivos y carpetas

Ahora quiero crear una carpeta y compartirla entre mis equipos de Mesh. Para lograr esto podría crear una carpeta en Live Desktop y luego sincronizarla con mi equipo portatil y viceversa.

A modo de ejemplo, voy a crear una carpeta Test en mi escritorio local y agregarla a Live Mesh.

image 

Como se muestra en la imagen es muy simple, gracias a la integración de Live Mesh con el Escritorio, Mi PC, el Explorador de Windows, etc.

Al seleccionar Add folder to Live Mesh veremos una ventana de diálogo donde podremos indicar el nombre de la carpeta a compartir y cuando debe sincronizarse con los demás dispositivos. Presionamos Ok y listo!.

image

Ahora nuestra carpeta Live Mesh cambió a un color azulado y ya tenemos disponible la misma carpeta en el Live Desktop (y otros dispositivos conectados). Observen también que el sitio de Mesh usa un protocolo HTTPS que nos proporciona seguridad de encriptación de datos en la transferencia de nuestros bytes.

image

Para terminar las pruebas, abrimos la carpeta Test de nuestro equipo local y creamos un simple archivo de texto Prueba.txt.

image

Esperamos unos segundos y listo! Este archivo Prueba.txt ahora también esta replicado en nuestro Live Desktop (y otros dispositivos, si existiesen). Podemos verificarlo ingresando a nuestro Live Desktop, haciendo doble clic en la carpeta Test.

image

Conclusiones

Es muy simple el uso de Live Mesh para compartir y sincronizar archivos y carpetas entre diferentes equipos y dispositivos. Su integración con el Shell de Windows lo hace muy amigable. Además podemos invitar a amigos y colaboradores para compartir archivos o documentos de trabajo y mantenernos sincronizados. Basta de diferentes versiones de archivo en diferentes lugares, tendremos una sola versión en todos los lugares que necesitemos.

En futuros post comentaré mi experiencia con Remote Desktop de Live Mesh.
Hasta la próxima!

miércoles, 19 de noviembre de 2008

PDC 2008 Buenos Aires

Ayer martes 18 de Noviembre tuve la oportunidad de asistir a este importante evento realizado aquí en Buenos Aires. El evento inició con unas keynotes de la mano de Miguel Saez, Ezequiel Glinsky, Juan Ladetto y Alejandro Ponicke que nos comentaron un poco sobre el PDC 2008 de Los Angeles, realizado hace apenas 2 semanas, y lo que se viene: Windows Azure, Cloud Computing, Windows 7, etc.

Juan y Miguel, como ya nos tienen acostumbrados, en una excelente presentación en tiempo y forma, nos mostraron algunas bondades muy interesantes y útiles de Live Mesh. En siguientes posts comentaré mis experiencias con estas aplicaciones, su API, etc.

Ezequiel nos mostró unas fotos de los impresionantes DataCenters de Microsoft, particularmente el DataCenter de Quincy. Con inversiones de miles de millones Microsoft demuestra su fuerte apuesta en el futuro de los servicios basados en la nube.

Finalmente, Alejandro nos dió un preview de Windows 7, si bien no fue una presentación en profundidad, destacó algunas características interesantes como una TaskBar mucho más rica, desde donde podemos lanzar aplicaciones, acceder a documentos recientes, alternar aplicaciones en ejecución e incluso interactuar con las aplicaciones en runtime directamente desde la taskbar.

Luego de las 2 horas que duraron las keynotes tuvimos un break de 30 minutos donde aprovechamos unos cafés con ricas medialunas.

Las siguientes charlas se dividieron en 3 salas: una sala dedicada a Servicios en la nube, otra donde hablaron de Aplicaciones Clientes y Presentación (WPF, Silverlight, ASP.NET 4.0) y en la tercer sala se dedicaron a Herramientas, Lenguajes y Framework (F#, C#, Oslo, VS2010, etc.). Todas las charlas eran muy interesantes, pero había que decidir cual asistir. Mi amigo Mariano Noguera y yo nos inclinamos por la nube.

Servicios en la nube

Arrancamos con un recorrido por Cloud Services de la mano de Juan Ladetto, donde empezamos a ver un poco más de qué se trata Windows Azure. En nuevos posts intentaré hablar sobre lo que vaya conociendo de esta nueva plataforma que se perfila como una excelente y novedosa alternativa para hostear nuestras aplicaciones.

A continuación, con Matías Woloski y Edgardo Rosetto, desplegamos un servicio en la nube. La experiencia fue muy simple. Creamos una típica aplicación Hola Mundo en ASP.NET y lo desplegamos en Windows Azure, todo lo que hicimos fue seguir un asistente web que nos permitió hostear la aplicación, primeramente en un estado de Stagging para luego pasarla a Production. Si bien la aplicación hacía exactamente nada, lo interesante fue ver cómo ponerla en la nube y ver cómo esta aplicación puede escalar a voluntad en tiempo record simplemente cambiando valores en configuración. Este es un punto sin precedentes que permitiría que una aplicación pueda escalar horizontalmente en cuestión de segundos.

Nuevamente, Miguel Saez nos dió un paseo más programático sobre Live Framework  y Mesh Services. Obviando los aspectos teóricos, Miguel nos mostró a través de una aplicación WPF, como interactuar con la API de Live Mesh y Live Contact. La verdad que es una API muy simple e interesante que más de uno puede encontrarle usos prácticos en las aplicaciones del mundo real. Podrán encontrar ppts y ejemplos en su blog.

Para terminar, y ya un poco agotados con esta maratón de charlas y novedades, Nicolás y Maximiliano de Huddle Group nos dieron una muy prolija y perfectamente sincronizada presentación de SQL Data Services. Nos mostraron el actual estado del arte, vimos un par de aplicaciones Windows y Web haciendo uso de las APIs, posibilidades y limitaciones actuales, y la intención de MS de llevar toda la potencia de SQL Server en la nube.

Fin del PDC

Pasadas las 22hs, terminaron las charlas y luego de un agradecimento de la gente de MS, se hizo un rápido sorteo de Libros, MS Mouses y algunas gorritas MSDN. No tuve la suerte de llevarme ningún libro, y había varios interesantes (Silverlight 2, Application = Markup + Code, ASp.NET 3.5, etc.), así que tuve que conformarme con la pulsera de la registración :-(

La verdad fue una jornada muy enriquecedora que mostró a las claras la intención de MS de posicionarse fuertemente en el negocio del Cloud Computing, las plataformas y herramientas que ofrecerá y cómo nosotros podemos beneficiarnos de estas nuevas plataformas que se hablan hoy y reinarán en los próximos 5 a 10 años.

Bueno, seguiré comentando sobre estas nuevas plataformas y tecnologías en futuros posts.
Byes!

martes, 22 de enero de 2008

Libro de OpenXML

Wouter Van Vugt ha escrito el primer libro sobre OpenXML "Open XML Explained". En este libro de 128 páginas cubre los aspectos básicos del desarrollo con OpenXML. El autor es un especialista en los formatos de OpenXML, podrán ver su participación en los foros de OpenXmlDeveloper.org y en su blog encontrarán algunos posts sobre OpenXML y otras tecnologías de .Net Framework.



Podrán descargar el libro en formato PDF desde aquí.
Y podrán acceder a un versión en formato docx desde aquí.

Limpiar los items recientes en Visual Studio 2005

No es una novedad, pero muchos me han preguntado si conocía una forma fácil de eliminar las entradas de los proyectos recientes en Visual Studio 2005, sin tener que editar/borrar manualmente entradas en el registro de Windows. Googleando un poco encontré una respuesta: MRU Cleaner.
Se trata de un add-in para borrar las entradas de los proyectos recientes en Visual Studio 2005, y no solo de los proyectos, sino también la lista de archivos recientes. La siguiente imagen muestra su uso:



Lo he probado y funciona muy bien. Pueden descargar una versión de este complemento para Visual Studio 2005 aquí. Y pueden obtener una versión beta para Orcas aquí.

miércoles, 16 de enero de 2008

Los documentos WordprocessingML

Ya hemos visto qué es y por qué nos interesaría usar OOXML, y presentamos sus componentes principales y tecnologías asociadas. Ahora vamos a explorar uno de sus tres lenguajes de marcas principales: WordprocessingML. Veremos su estructura, sus partes, elementos y relaciones; y cómo se almacena un documento de WordprocessingML dentro del contenedor.

Partes de un documento WordprocessingML
Como ya hemos dicho, un documento WordprocessingML tiene muchas partes relacionadas que se almacenan dentro de un contenedor. Actualmente se utiliza el formato ZIP para empaquetar y contener un documento WordprocessingML. Si renombramos un documento .docx a .zip podremos descomprimirlo y explorar internamente cada una de las partes del documento.


Figura 1: Estructura de un documento WordprocessingML

Ests estructura es definida por la especificación Open Packaging Conventions del formato OOXML. Como se muestra en la figura, el archivo.zip contiene una estructura de carpetas y archivos XML que forman las partes del documento. El contenido principal del documento se almacena en el archivo document.xml de la carpeta word y los demás archivos .xml (fontTable.xml, settings.xml, styles.xml, webSettings.xml) contienen información de estilos, fuentes, configuración, etc. El siguiente gráfico muestra un esquema de documento WordprocessingML y sus partes relacionadas:


Figura 2: Partes de un documento WordprocessingML

En la raíz del paquete .zip existe un archivo llamado [Content_Types].xml que describe todos los tipos de contenido para cada una de las partes dentro del paquete. El Content Type indica al consumidor del documento qué tipo de contenido debe ser esperado dentro del paquete.
Si continuamos explorando el archivo .zip, veremos una carpeta llamada _rels. Esta carpeta contiene un archivo XML con extensión .rels que describe las relaciones entre las diferentes partes del documento y permite unir el documento y sus partes.

En la carpeta docProps, encontraremos varios archivos XML como core.xml, app.xml y custom.xml. Estos archivos almacenan las propiedades del documento. Por ejemplo, el archivo core.xml contiene las propiedades generales aplicacables a todos los documentos de OOXML como Título, Asunto, Autor, etc. EL archivo app.xml contiene propiedades específicas del documento como Número de páginas, Número de líneas de texto, Versión de la aplicación, etc. Finalmente, el archivo custom.xml contiene propiedades personalizadas agregadas por el autor o usuario del documento.

Archivos binarios
El formato XML no soporta nativamente los datos binarios como imágenes u objetos OLE. OOXML almacena los datos binarios en como partes binarias en su formato nativo. Si examinamos la carpeta media encontraremos las imágenes y objetos binarios que han sido incluidos en el documento.

Un documento WordprocessingML básico
Si quisiéramos crear un documento WordprocessingML básico, necesitaríamos al menos 3 partes:

  1. Un archivo document.xml que contiene el cuerpo principal del documento.

  2. Un archivo [Content_Types].xml que describe los tipos de contenidos incluidos en el paquete.

  3. Un archivo .rels que define las relaciones entre las diferentes partes y permite ubicar cada parte dentro del paquete.

Figura 3: Documento Wordprocessing básico

La parte de inicio, document.xml
El primer elemento al crear un documento de OOXML es la parte de inicio (start-part). Este es el lugar donde los consumidores empezarán a parsear el contenido del documento. Los 3 lenguajes de marcas principales de OOXML (WordprocessingML, SpreadsheetML, PresentationML) contienen dentro del archivo ZIP una parte considerada como la parte de inicio. En WordprocessingML la parte de inicio es el archivo document.xml y es usado para almacenar el contenido principal del documento.

La siguiente figura muestra un ejemplo del contenido de un archivo document.xml:


Figura 4: Contenido de document.xml

Se puede observar una estructura XML bastante sencilla para formar un documento. Dentro del elemento document se puede crear los bloques de construcción del documento como párrafos, tablas y gráficos. Muchos de estos elementos utilizan el mismo identificador de espacio de nombres XML. Microsoft Office 2007 utiliza el prefijo w. Podemos usar cualquier otro prefijo, pero debemos mantener el espacio de nombres XML de WordprocessingML:

http://schemas.openxmlformats.org/wordprocessingml/2006/main

Los tipos de contenidos, [Content_Types].xml
Los consumidores de OOXML necesitan saber qué tipos de contenidos existen dentro del paquete. La lista de tipos de contenidos está definida dentro del archivo [Content_Types].xml que debe estar ubicado en la raíz del contenedor.
Los tipos de contenidos se identifican de dos formas:

  1. Utilizando la extensión del archivo de partes dentro del paquete.

  2. Especificando la ubicación y tipo de contenido del archivo dentro del paquete.
La siguiente figura muestra el contenido de un archivo [Content_Types].xml:


Figura 5: Contenido de [Content_Types].xml

Se puede ver claramente las dos estrategias utilizadas para identificar y definir los tipos de contenidos de cada parte dentro del paquete. Dentro del elemento Types se puede crear dos elementos, Default y Override. En el ejemplo, el elemento Default asocia la extensión xml con el tipo de contenido application/xml, y de forma similar puede observarse el tipo de contenido asociado a los archivos rels y los archivos png.

Anteriormente, hablamos del archivo document.xml , que es la parte de inicio y contiene el cuerpo principal del documento. Como la extensión de este archivo es xml, el elemento default, del archivo de tipos de contenidos, indicaría que se trata de un simple archivo de tipo application/xml, sin embargo este archivo es especial y debe ser definido como tal. Para ello se utiliza el elemento Override, para sobrescribir la asociación de tipos por defecto y especificar el tipo de contenido asociado en forma explícita.

En el ejemplo, existe un elemento Override que asocia el archivo /word/document.xml con el tipo de contenido application/vnd.openxmlformats-officedocument.wordprocessingml.document.main+xml. Este mismo enfoque se utiliza para definir el tipo de contenido de las partes restantes del documento.

Las relaciones entre partes
Otro elemento requerido en un documento Wordprocessing, es el archivo de relaciones entre partes. En el archivo .zip existe una carpeta _rels que contiene un archivo .rels. Este es un archivo XML que define las relaciones y ubicación de las partes principales del paquete.

La siguiente figura muestra el contenido del archivo .rels:


Figura 6: Contenido del archivo .rels

El elemento Relationship contiene tres piezas básicas de información:

  1. ID: Un identificador único para la relación.

  2. Type: define el tipo de relación.

  3. Target: especifica la ubicación del elemento o parte relacionada.

Debe observarse que no hay información sobre el origen (Source) de la relación. En este caso, el origen de la relación es implícito y relativo a la raíz del paquete.

Además del archivo .rels principal, dentro de la carpeta word/_rels existe un archivo document.xml.rels que define las partes relacionadas al documento.xml como el encabezado, pie, estilos y fuentes.

Utilizando el attributo type y target del archivo .rels, los consumidores de documentos OOXML pueden localizar el documento principal (start-part), y, luego, usando el archivo de relaciones asociado al documento principal (document.xml.rels), es posible ubicar el encabezado y pie, encontrar las imágenes y otras partes relacionadas al documento.


Hasta aquí hemos visto las partes principales de un documento de WordprocessingML, su formato y estructura. En la próxima entrega empezaremos a hacer ejercicios y veremos cómo crear y empaquetar esas partes en forma manual y en forma programatica, utilizando la API de Packaging (System.IO.Packaging) incluida en .NET 3.0.

martes, 15 de enero de 2008

Conociendo Office Open XML

Anteriormente, comenté acerca de OOXML, la idea de Software + Servicios y cómo podemos beneficiar nuestros desarrollos con estos nuevos enfoques. En este post vamos conocer un poco más sobre OOXML, sus elementos y su estructura.

Componentes de OOXML
Como vimos en el post anterior, Office Open XML es una especificación basada en XML para documentos digitales como planillas de cálculo, gráficos, presentaciones y documentos de procesamiento de texto. La especificación fue desarrollada por Microsoft para suceder al formato binario de Microsoft Office y fue estandarizada por la ECMA en diciembre de 2006.

En la especificación actual aparecen tres lenguajes de marcas principales:

  • WordprocessingML: para documentos.
  • SpreadsheetML: para hojas de cálculo.
  • PresentationML: para presentaciones
Además de estos lenguajes de marcas, existen otros lenguajes subyacentes como DrawingML usado para dar soporte a gráficos, tablas y diagramas.
Las partes de un documento OOXML son empaquetadas dentro de un contenedor. Hoy se utiliza el formato ZIP para empaquetar y contener los archivos y recursos que componen un documento, sin embargo, podría utilizarse una base de datos como contenedor de documentos OOXML.
Finalmente, además de los lenguajes de marcas, la estructura interna dentro del paquete o contenedor también ha sido estandarizada. Esta estructura se conoce como Open Packaging Convention.
El siguiente gráfico resume los elementos principales de la especificación OOXML. ZIP y XML + Unicode no son parte de la especificación.


Figura 1: Componentes de Office Open XML

En el siguiente post exploraremos el formato y estructura de documentos WordprocessingML y comprenderemos mejor la relación entre los componentes de OOXML.

¿Por qué Office Open XML?

También conocida como OOXML, es una de las nuevas siglas que inspiran cientos de posts en los blogs de tecnología. Office Open XML es una especificación basada en XML para documentos digitales como planillas de cálculo, gráficos, presentaciones y documentos de procesamiento de texto. La especificación fue desarrollada por Microsoft para suceder al formato binario de Microsoft Office. Esta especificación fue estandarizada por la ECMA en diciembre de 2006.

Actualmente, la especificación está siendo evaluada por la ISO referida como DIS 29500 (Draft International Standard 29500) y se ha generado una polémica en su entorno que escapa los fines de este post.

Software + Servicios
Más allá de la polémica suscitada sobre la estandarización, muchos desarrolladores se preguntarán por qué o para qué necesito aprender OOXML. Bueno, existen muchas motivaciones para usarlo. En los siguientes enlaces encontrarán dos artículos en español interesantes que hablan acerca de los fundamentos del nuevo mundo de documentos y los formatos de Open XML: http://www.microsoft.com/spain/interop/openxml/new_world_of_docs.mspx http://www.microsoft.com/spain/interop/openxml/ds_open_xml.mspx

De las diferentes oportunidades que OOXML puede generar, la que más me ha interesado como desarrollador fue la posibilidad de construir e implementar soluciones S+S (Software + Services) combinando las soluciones de clientes ricos y soluciones móviles con servicios de Internet.

Por ejemplo, crear una solución basada en planillas de cálculo que permita generar una orden de compra y publicarla en el sistema de gestión de compras a través de Internet; o escribir un artículo en el procesador de texto y publicarlo en la web con un solo clic.

Se trata de aprovechar la flexibilidad y experiencia de usuario enriquecida proporcionada por las aplicaciones de escritorio y móbiles y combinarlas con servicios de Internet basados, por ejemplo, en el modelo SaaS. De hecho, podría arriesgar a decir que S+S intenta cubrir los aspectos que se pierden en un enfoque SaaS puro, como la experiencia de usuario enriquecida basada en soluciones de escritorio ricas, capacidad de trabajo offline, mayor aprovechamiento de la plataforma subyacente, etc.

El papel de OOXML en S+S
Resulta interesante la idea de S+S, pero ¿qué papel juega OOXML?. En el pasado ya se han construido aplicaciones capaces de generar o capturar información a través de planillas de cálculo y documentos de texto utilizando los formatos binarios de Microsoft Office y otras suites.
Entiendo que un aspecto interesante de OOXML para los desarrolladores es, por ejemplo, el soporte que ofrece Microsoft a través de .NET Framework para crear y manipular documentos de OOXML, facilitando la integración y construcción de soluciones S+S.

Muchos aún discuten que OOXML no es estándar, que no es abierto, que no es XML, etc. Pero la realidad es que la mayoría de las empresas en el mundo centran su trabajo en el uso de documentos electrónicos. Aplicaciones como Excel y Word, se han convertido en la herramienta principal o preferida para registrar, visualizar, manipular y publicar datos. Estos escenarios basados en documentos representan nuevas oportunidades para complementar, interoperar y extender nuestros productos y servicios.

En los próximos post empezaré a explorar este nuevo mundo de Open XML desde la perspectiva del desarrollador; veremos la teoría y crearemos ejemplos en .NET.
Hasta la próxima!