Climens Codelog

Ayer estuve en la presentación de Visual Studio 2008 aquí en Valencia y la segunda charla fue sobre LINQ (Como no tengo la documentación, sólo propaganda, no recuerdo de memoria quién dió la charla, solo que era de Alcoi). Ya había visto algo pero francamente no lo había visto en acción.

Y la verdad es que LINQ me deja un sabor dulce aunque con un toque un poco agrio. Por un lado, es una herramienta muy potente y unificada para acceder a distintos orígenes de datos y colecciones (XML, arrays de objetos, bases de datos...) que además obliga a introducir novedades en C# muy interesantes. Pero sintácticamente no me gusta nada:

var directors = from movie in movies
where movie.Country == "Spain"
select movie.Director;

Y vale. Impresionante en ciertos aspectos: movies puede ser un XML o un array o cualquier cosa y finalmente directors será un array de objetos Director o de strings, según estén definidos en los objetos de la colección movies y además, Intellisense reconocerá los campos de la colección directors y nos permitirá autocompletar y detectar errores en tiempo de compilación.

Pero, ¿era necesaria esta sintaxis? Yo creo que no. Creo que una interfaz fluida (fluent interface) habría sido mucho más interesante desde el punto de vista de mantener la coherencia con el resto del C# (o VB.NET, para el caso es lo mismo) y no habría introducido artefactos de código un tanto forzados.

Por otro lado, no sé hasta qué punto es útil ofrecer facilidades para mezclar código de consultas a la base de datos por la aplicación, ya que en cierto modo fomenta las malas prácticas, pero eso es otro cantar.

Finalmente, no me gusta LINQ to SQL porque volvemos a estar con el mismo problema que con los datasets tipados: un diseñador semiautomático que mapea la base de datos para generar las clases que usará LINQ, pero ¿qué pasa cuando se hacen cambios en la base de datos? El diseñador de datasets era bastante propenso a hacer cosas raras al haber muchos cambios además de que generaba XSDs gigantescos además de los archivos de código asociados. De todos modos sobre esto aún no puedo hablar porque no lo he probado.

En fin, para gustos colores y desde luego que al final acabaré acostumbrándome a todo.Por supuesto, si funciona bien y es tan útil como parece lo usaré. Además están apareciendo proveedores de LINQ para todo, lo que es muy interesante.

Actualización 19/03/08: En el siguiente post, ya me va gustando más la sintaxis y explico algunos de los motivos que hay detrás y cómo funciona.

Leo en Kriptópolis y de allí en openxml.info que España ha rechazado la propuesta del estándar OOXML no sin polémica sobretodo por el documento de Microsoft en el que se afirmaba que la Junta de Andalucía apoyaba la propuesta del gigante del software.

Al final, 4 votos en contra y 3 a favor por el comité evaluador de AENOR, con lo que España se abstendrá el próximo 2 de septiembre en la votación final ya que debe haber una mayoría de dos tercios para no abstenerse.

En definitiva, ya son unos cuantos los países que no ven clara la propuesta y veremos como queda el resultado final. Si queréis saber por qué es malo el OOXML, podéis leer mi post anterior sobre el tema y los enlaces que allí se presentan.

Yo al final no sé si realmente se están sacando un poco las cosas de quicio pero si uno se pone a leer todos los asuntos turbios que rodean esta iniciativa de Microsoft la verdad que no sabe qué pensar, desde luego no es agua clara. Al final, haya o no haya estándar, la gente va a seguir usando el Word pirateado y pasará los documentos en .docx, con lo que, queramos o no, tendremos que claudicar. Hasta ahora ha sido así, tanto en la administración como en otros organismos, los .doc campan a sus anchas aunque para editarlos con 100% de garantías haya que pasar por caja y pagar unos duros a Microsoft. Por no hablar de la gran cantidad de gente que no solamente usa Word sino que ni siquiera sabe que existen otras alternativas igual de válidas y gratuitas.

Vía | España no aprueba el formato OOXML de Microsoft pero... [kriptopolis.com]

Me ha surgido la necesidad de devolver un texto al realizar una llamada a una página ASP.NET, para sustituir un script antiguo pero sin tener que cambiar nada de las páginas que se comunican con esta.

Lo primero que hay que hacer es, cambiar la página .aspx para que la salia no sea html sino texto plano, cambiando la etiqueta ContentType de la directiva @Page:

 
<%@ Page Language="C#" ContentType="text/plain" AutoEventWireup="true"
 CodeBehind="Default.aspx.cs" Inherits="Proyecto1._Default" %>

Después, el código por detrás sería algo similar a esto:

 
namespace Proyecto1{
    public partial class _Default : System.Web.UI.Page{
        protected void Page_Load(object sender, EventArgs e)
        {
            string salida= "Texto que se va a mostrar";
            StreamWriter writer =
                new StreamWriter(Response.OutputStream, System.Text.Encoding.ASCII);
 
            writer.Write(result);
            writer.Close();
        }
    }
}

Y eso es todo, así de sencillo.

Se pueden hacer variaciones, por ejemplo para escribir XML, que puede ser mucho más útil. Para ello habría que cambiar el ContentType a "text/xml" y después, en vez de usar el StreamWriter, crear algo similar a esto:

 
XmlTextWriter writer =
    new XmlTextWriter(Response.OutputStream, System.Text.Encoding.UTF8);

Con esto por ejemplo se pueden escribir XML para pasarlos a algún web service poco estándar o para alguna llamada AJAX.

Via | Creating XML Documens with the XmlTextWriter class [4guysfromrolla.com]