Hola! ¿Has llegado por aquí buscando mi blog de tecnología .NET?

Ya no lo tengo en clearscreen, mi blog ahora está en geek.ms:

http://geeks.ms/blogs/etomas

Nos leemos en geeks!!! ;-)

Si habéis probado de serializar un objeto que implemente IDictionary os habréis dado cuenta de que el sistema genera una excepción, indicando que no sabe como serializar dichos objetos.

Por suerte existe una solución bastante fácil (explicada tanto aquí como aquí): implementar la interfaz IXmlSerializable. En los métodos ReadXml ponemos el código para deserializar y en WriteXml el código de serializar.

A continuación un ejemplo (el mérito no es mío, si no de los que han hecho los enlaces anteriores, yo lo único que he hecho ha sido adaptarlo para que use genéricos). Los objetos de la clase SerializableDictionary se pueden serializar a Xml de la manera tradicional. Para más información pasaros por los enlaces anteriores ;-)

public class SerializableDictionary : Dictionary, IXmlSerializable 
{
const string NS = <A HREF="">http://blogs.clearscreen.com</A>; 
#region IXmlSerializable Members 
public System.Xml.Schema.XmlSchema GetSchema() 
{
return null; 
}

public void ReadXml(System.Xml.XmlReader r) 
{
XmlSerializer keySer = new XmlSerializer(typeof(K));
XmlSerializer valueSer = new XmlSerializer(typeof(V)); 
r.Read();
r.ReadStartElement("dictionary", NS); while (r.NodeType != System.Xml.XmlNodeType.EndElement) 
{
r.ReadStartElement("item", NS); 
r.ReadStartElement("key", NS); 
K key = (K)keySer.Deserialize(r);
r.ReadEndElement();
r.ReadStartElement("value", NS); 
V value = (V)valueSer.Deserialize(r);
r.ReadEndElement();
this.Add(key, value); 
r.ReadEndElement();
r.MoveToContent();
}
r.ReadEndElement();
}
public void WriteXml(System.Xml.XmlWriter w) 
{
XmlSerializer keySer = new XmlSerializer(typeof(K));
XmlSerializer valueSer = new XmlSerializer(typeof(V)); 
w.WriteStartElement("dictionary", NS); foreach (K key in this.Keys) 
{
w.WriteStartElement("item", NS); 
w.WriteStartElement("key", NS); 
keySer.Serialize(w, key);
w.WriteEndElement();
w.WriteStartElement("value", NS); 
V value = this[key]; 
valueSer.Serialize(w, value);
w.WriteEndElement();
w.WriteEndElement();
}
w.WriteEndElement();
}
#endregion
}

Editado @ 04/10: Eliminados unos molestos saltos de línea que impedían leer bien el código fuente... ^_^

Pues eso... hay varias cosas que no me terminan de cuadrar sobre el como funciona el DataGridView cuando se vincula (mmm... ata?), cuando se hace data-binding para entendernos contra un objeto de negocio propio.

Supongamos que tengo la siguiente clase:

La clase Action no importa para lo que quiero contar, imaginaosla como querais... podemos suponer que tiene una propiedad Name de tipo String.

Tengo también otra clase llamada State que entre otras cosas tiene una propiedad de tipo List, llamada Activities.

Creo un object data binding: Data -> Add New DataSource -> Object y selecciono la clase State.

Eso me crea un object data binding parecido a ese:

(Nota: En mi caso la clase Activity tiene también propiedades DoAction y ExitAction que son de tipo Action)

Luego, arrastro la propiedad Activities en un form, y me aparece automáticamente un dataviewgrid vinculado. Hasta ahí todo perfecto.

Ahora empieza la pesadilla... Cual es mi idea? Tengo varios tipos de Acciones que se pueden asignar a la propiedad EntryAction. Desde la grid vinculada me gustaría que se desplegara una combo con los distintos tipos de acciones que admito (p.ej. PlaySound y PlaySequence). Cuando el usuario escoja un valor de la combo, el datagridview debería crear un objeto Action, concreto (bueno, de hecho me gustaría que creara un objeto de una cierta clase derivada de Action. Si el usuario escoje PlaySound en la combo quiero que se cree un objeto de la clase PlaySound).

El primer paso es sencill En la DataGridView indico que quiero modificar las columnas y indico que la columna EntryAction es de tipo DropDownList. La cosa queda més o menos así:

Luego añado dos items a la columna EntryAction (dos cadenas) con los valores "PlaySound" y "PlaySequence" para que el usuario pueda escojer.

Finalmente creo la clase ActionTypeConverter que deriva de TypeConverter cuya finalidad es convertir una cadena a un objeto Action y viceversa. Defino los métodos:

Lo hago para que el CanConvertFrom y el CanConverTo indiquen true sólo si se desea convertir desde/a cadena e implemento el ConvertFrom para que devuelva una instancia de PlaySound o PlaySequence en función de si la cadena pasada es "PlaySound" o "PlaySequence". Finalmente el método ConvertTo hace lo contrario (devuelve una cadena "PlaySound" o "PlaySequence".

Ejecuto el programa y cuando escojo un valor de la combo:

Además ese error se repite ad-eternum cada vez que la DataViewGrid necesita refrescarse.

Tras unas cuantas lecturas por foros y demás, viendo que ese error se da un muchos casos, observo depurando que los métodos CanConvertFrom y ConvertFrom del ActionTypeConverter, pero los que convierten de Action a string no. Eso me extraña puesto que yo daba por supuesto que:

1. La Grid llamaría a ConvertTo para pasar el objeto Action a una cadena y mostrar ese valor en la combo
2. La Grid llamaría a ConvertFrom cuando se hubiese seleccionado un valor de la combo, para obtener un objeto Action (o en mi caso un objeto derivado de Action).

Pero, por alguna razón el punto (1)  no se lleva a cabo... :(

Luego también me llamó la atención el hecho de que en unos foros se mencionaba que una celda de tipo combo en la grid sólo podía mostrar valores que contuviera la propia combo, y me asaltó la duda... no estará comparando por Equals? En este caso el mensaje de error, tendría sentido puesto que en la combo había cadenas (String) que nunca serían iguales a objetos Action (aunque yo proporcionase un ConvertTo que por alguna oscura razón no se llamaba). Así que hice dos cosas: poblar la combo (myColumn.Items.AddRange(...)) con dos objetos Action (un PlaySound y un PlaySequence) y redefnir los métodos Equals de forma que todos los PlaySound sean iguales entre ellos y todos los PlaySequence sean iguales entre ellos.

Cuando ejecuté el programa en la combo no aparecía el nombre "PlaySound" o "PlaySequence" sinó el nombre completo de la clase... tal y como lo hace el ToString(), así que ya puestos lo redefiní también (total... me hacía falta un método para pasar de Action a cadena, no?).

Y al ejecutar... funcionó! En la combo se mostraba "PlaySound" y "PlaySequence" y al seleccionar un valor, se ejecutaba el ConvertFrom del TypeConverter.

Mis dudas principales son:

1. Por qué la Grid es capaz de ejecutar el ConvertFrom del TypeConverter para obtener un objeto a partir de la cadena y no es capaz de ejecutar el ConvertTo para obtener una cadena a partir del objeto (será porque todos los objetos tienen ToString() ?)
2. Por qué me obliga a poblar la columna usando objetos Action en lugar de cadenas? (Aunque bueno, esto segundo lo puedo llegar a entender pienso que debería ser posible poblar la combo con cadenas que fuesen representaciones válidas de objetos de negocio y que la grid fuera lo suficientemente lista como para espavilarse).

En fin, tu... que líos...

Editado @28/09: Vale... creo que ya se cuando llama al ConvertTo y cuando llama al ToString(): Para poblar la combo necesita cadenas, así que llama al ToString(). Si tengo eso:

Para poblar la combo llamará a a1.ToString() y a2.ToString().

Luego el ConvertTo lo llama cuando lee de la fuente de datos, y la cadena resultante es la que intenta mostrar en la combo.

Buenas!

Para un desarrollo que estoy preparando me ha surgido la necesidad de obtener el esquema XSD, de una clase en .NET, de forma programática (sin usar la herramienta xsd.exe, vamos). La idea es poder generar dinámicament y de forma automática el esquema XSD de cualquier clase.

La verdad es que la clase XmlSerializer, permite serializar a XML cualquier clase .NET, pero no hay manera aparente de obtener el esquema XSD. Después de estar bastante rato buscando por internet y surfeando por la MSDN no he encontrado ningún ejemplo, ni nada parecido o que me pudiera ayudar. Así que al final, he optado por una solución drástica: decompilar la herramienta xsd.exe (vale, reconozco que quizá no es muy ético, pero necesidad obliga ;))...

Gracias a Reflector for .NET, he podido obtener una aproximación al código fuente de xsd.exe y sólo ha sido cuestión de tiempo el averiguar como obtener el XSD asociado a una clase .NET. La clave está en la clases System.Xml.Serialization.XmlReflectionImporter y System.Xml.Serialization.XmlSchemaExporter, que no están documentadas en la msdn (vamos, que aparecen pero con el típico comentario " This type supports the .NET Framework infrastructure and is not intended to be used directly from your code.").

La primera permite importar la información de toda una clase en un objeto System.Xml.Serialization.XmlTypeMapping, mientras que rellena un System.Xml.Serialization.XmlSchemas con la información del XmlTypeMapping indicado.

En resumidas cuentas el código quedaria (básicamente) así:

...

En fin, digo yo que que les costaría a los de microsoft documentar un poquillo más las cosas, no???

Un saludo!

El otro día un compañero mío de raona, envió un correo que creo que es intersante, así que me he permitido la licencia de resumirlo y publicarlo aquí.

En concreto hablaba del desarrollo de web services haciendo especial énfasis en el contrato (contract-first vs code-first, podeis leer mucha más información en http://msdn.microsoft.com/msdnmag/issues/05/05/ServiceStation/), aún no siendo la solución definitiva a algunos de los problemas que quieren resolver los servicios web, plantea algunos aspectos que van en la dirección correcta, especialmente aquellos que nos hacen pensar que mensajes debemos enviar o recibir.

Obviamente la situación ideal es cuando tenemos un esquema concreto al que nos tenemos que ajustar, y en este caso lo cierto es que VS.NET (por su tendencia a ocultar el WSDL generado) no nos ayuda demasiado. En este punto es donde mi compañero mencionaba que han estado usando una herramienta gratuita (que yo personalmente no he tenido ocasión de probar), pero que facilita bastante el trabajo: http://www.thinktecture.com/Resources/Software/WSContractFirst/default.html.

Dicha herramienta permite garantizar que los mensajes enviados/recibidos por un servicio web se ajusta a un esquema indicado y permite generar también el código del servicio web como del cliente asociado.

Un saludo!

Muy buenas...

Me pregunto de nuevo, y esta vez por escrito, por que microsoft no ha incorporado el concepto de referencia constante al CLR y así de paso a todos los lenguajes .NET.

Personalmente el uso de const en C++ me parece una autentica maravilla y me sorprende que ni Sun en su dia con Java, ni Microsoft hayan incorporado dicho concepto a sus lenguajes.

Los que sepais C++ sabeis como funciona el tema: se puede indicar que una función recibe como parámetro o devuelve una referencia constante, eso es, que el estado del objeto apuntado por dicha referencia (y/o puntero en el caso de C++) no se puede modificar:

void foo (const MyClass* pMc) {...}

La función foo no puede modificar el estado del objeto apuntado por pMc, es decir no puede llamar a ningún método que modifique alguna variable miembro de la clase. De hecho, al desarrollar la clase, tiene que marcarse explicitamente que funciones son accesibles a través de una referencia/puntero const:

class MyClass

{

public:

void func1();

void func2() const;      // El código de MyClass::func2 no puede modificar ninguna variable miembro de MyClass

}

En este caso, una llamada a pMc->func1() desde la función foo daría un error de compilación, mientras que una llamada a pMc->func2() compilaría correctamente.

Personalmente encuentro esta característica muy interesante... por ejemplo al devolver colecciones. Algunas veces tengo classes parecidas a estas:

class UXLContainer

{

    private UXLItemCollection _items; 

    public UXLItemCollection Items { get { return _items; } }

}

Me encuentro en que es perfectamente legal que alguien coja un objeto UXLContainer, y haga algo como:

UXLContainer c = new UXLContainer();

c.Items.Add (...);

Pero a mi, p.ej. me interesaba que dicha colección fuera de solo lectura (es decir que se pudiera acceder a un UXLItem, pero no añadir ni quitar UXLItems de la colección).

Se que hay soluciones alternativas, pero considero que en este caso una referencia constante sería ideal.

No he entendido jamás porque ni Java en su día, ni .NET más tarde incorporaron esta característica de C++ a sus plataformas...

Nos vemos!

Buenas!

Conoceis el paradigma de programación web, que se conoce como Ajax?? Bueno... básicamente consiste en utilizar XmlHttpRequest + javascript para lanzar peticiones asíncronas al servidor web y así romper el flujo tradicional de una aplicación web.

No es un invento relativamente nuevo, pero está ganando mucho auge ahora, especialmente desde que XmlHttpRequest está disponible en todos los navegadores. Un muy buen ejemplo del potencial de ajax es gmail. Bueno... una explicación mejor de Ajax que ésta la encontrareis aquí.

En ASP.NET 2.0 habrá soporte para Ajax (Client Callbacks), pero este soporte desde mi punto de vista deja un poco que desear, porque está orientado por control, mientras que yo pienso que este paradigma es lo suficientemente importante para que el soporte de Ajax esté orientado por el framework entero. Y esto implica que el framework debe dar mucho más soporte de cliente que el que proporciona en la actualidad (para empezar el desarrollador debería despreocuparse del código Javascript asociado. Un ejemplo de a lo que me refiero es la librería ajax.net). Una buena cantidad de características que no existen en ASP.NET 2.0 las podeis leer en este blog (mirad el apartado "It works but...")

En ASP.NET 2.0 no veremos nada nuevo al respecto, pero las buenas noticias son que al menos parece que Microsoft se está preocupando por Ajax (o eso se deduce de esta petición al feeback center).

Veremos como evoluciona todo esto... ;)

	[ToolboxData("<{0}:TagIf runat=server></{0}:TagIf>")]
	[ParseChildren(true)]
	public class TagIf : Control, INamingContainer
	{

		protected ITemplate _doAction = null;
		protected ITemplate _elseAction = null;
		protected string _expression = null;

		/// <summary>
		/// Expresión a evaluar para decidir si mostrar el contenido del DoAction o del ElseAction
		/// </summary>
		/// <value>En esta versión... un número (constante) ;)</value>		
                public string Expression
		{
			get { return _expression; }
			set { _expression = value; }
		}

		// override to prevent literal controls from being added as children
		protected override void AddParsedSubObject(object o)
		{
		}

		/// <summary>
		/// Las propiedades ITemplate son las que permiten tener texto HTML + ASP.NET como parte de una propiedad de un control
		/// </summary>
		/// <value></value>
		[TemplateContainer(typeof(TagItem))]
		public ITemplate DoAction
		{
			get { return _doAction; }
			set { _doAction = value; }
		}

		[TemplateContainer(typeof(TagItem))]
		public ITemplate ElseAction
		{
			get { return _elseAction; }
			set { _elseAction = value; }
		}  

		/// <summary>
		/// Creamos los controles hijos.
		/// En función de la evaluación de la expresión (en este caso un simple número) creamos los controles hijos
		/// a partir del template DoAction o ElseAction (según sea el número != 0 o ==0).
		/// </summary>
		protected override void CreateChildControls()
		{

			int bi = 0;
			try
			{
				bi = Convert.ToInt32(_expression);
			}
			catch (Exception) { }


			if (bi > 0)
			{
				FillActionTemplate(DoAction);
			}
			else
			{
				if (ElseAction != null)
				{
					FillActionTemplate(ElseAction);
				}
			}
		}

		/// <summary>
		/// Rellena un ITemplate con los controles hijos que se crean a partir del código HTML + ASP.NET que está
		/// dentro de este template
		/// </summary>
		/// <param name="action">ITemplate a rellenar</param>
		private void FillActionTemplate(ITemplate action)
		{
			// clear any existing child controls
			Controls.Clear();
			// create item
			TagItem item = new TagItem();
			// initialize item from template
			action.InstantiateIn(item);
			// add item to the child controls collection
			Controls.Add(item);

		}
	}

	public class TagItem : Control, INamingContainer
	{
		public TagItem()
		{

		}
	}

        <ufo:tagif id="TagIf1" runat="server" expression="0">

            <doaction>

                <h1>Pues sí</h1>

            </doaction>

            <elseaction>

               <h1>Pues no!</h1>

               <hr />

               <asp:textbox id="TextBox1" runat="server"></asp:textbox>

            </elseaction>

        </ufo:tagif>

Según el contenido de Expression sea "0" o cualquier otro número distinto de 0, se ejecuta el código HTML (y ASP.NET) que esté contenido en DoAction o en ElseAction.

Un saludo!