El Concilio de Rivendel

Mix 2010 Open Call Vote. Vota por Plain, vota por ti ;)

Anuar Khan Ali — Fri, 08 Jan 2010 07:19:00 GMT

Como ya ha comentado mi querido compañero Anton ( alias Antuan para los amigos) este año la organización del MIX 2010 ha decidido que 5 de las charlas serian escogidas por la comunidad, la lista de las charlas que se pueden votar esta en el siguiente enlace: http://visitmix.com/opencallvote.
Aunque como digo en el titulo del post, "te pedimos" que votes por Plain, porque es una forma de votar por ti ;). Os dejo los enlaces de las cinco charlas que propone PlainConcepts.

BECOMING SOCIAL. How to power up your website using social networks

PLAIN CONCEPTS’ SILVERLIGHT LIVE MESSENGER TOOLKIT

SILVERLIGHT IN THE AUDIOVISUAL WORLD

EXTENDING THE WINDOWS LIVE MESSENGER WEB TOOLKIT WITH SCRIPT# AND SILVERLIGHT

WHAT YOU SEE IS NOT WHAT IS THERE. Users mind as a resource in Expression Blend

Solo tenéis que pinchar sobre "Add to ballot". Una vez hecho esto sobre todas, pinchad en "Submit Your Ballot" y listo.

Tenéis hasta el 15 de enero para votar

Un saludo y muchas gracias a todos.

Próximo evento WPF en Santander: "La revolución en UX: Destripando WPF"

Anuar Khan Ali — Wed, 08 Jul 2009 11:52:00 GMT

El próximo dia 24 de julio mi gran compañero Roberto Vivancos y yo impartiremos un evento en Santander, mi querida tierra natal :) . El evento esta organizado por el CIIN y tratara como se ve en el titulo del post sobre Windows Presentation Foundation (WPF), intentaremos dar una visión lo mas completa posible tanto en la parte de diseño como de desarrollo. Os dejo el enlace de inscripción. Espero que os animéis, sobre todo la gente de Cantabria. Tan solo ya dar las gracias al CIIN y especialemente a Juan Carlos por todo su apoyo y trabajo de organización del evento.

Un saludo.

Como poder usar nuestras Dependecy Properties desde Microsoft Expression Blend

Anuar Khan Ali — Thu, 25 Jun 2009 09:36:00 GMT

A menudo cuando se tiene que realizar una interfaz de usuario o una aplicación en Windows Presentation Foundation (WPF) es necesario crear controles personalizados: botones especiales con animaciones, controles de gestión de fecha, semáforos que describan algún estado, etc.

Al crear estos controles es muy normal que se le definan unas Dependecy Properties, que definan el comportamiento o las características del control.Para utilizar posteriormente estos controles en tiempo de diseño es muy útil que estas propiedades estén accesibles para poder realizar los Data Binding de una manera rápida desde Expression Blend.

Para llevar a cabo este cometido tan solo se tiene que añadir el siguiente código antes de la definición de la Dependecy Property.

[Category("Propiedades Alumno")]

public string Nombre

{

get { return (string)GetValue(NombreProperty); }

set { SetValue(NombreProperty, value); }

}

// Using a DependencyProperty as the backing store for Nombre. This enables animation, styling, binding, etc...

public static readonly DependencyProperty NombreProperty =

DependencyProperty.Register("Nombre", typeof(string), typeof(TestControl));

Donde “Propiedades Alumno” es el nombre de la categoría que va a aparecer en la lista de propiedades que están situadas en la columna de la derecha en Expression Blend.
Por lo tanto al utilizar el control en alguna ventana o en otro UserControl aparecerán estas propiedades en el diseñador para poder utilizarlas de la manera cómoda y sencilla en tiempo de diseño, como se puede ver en la siguiente figura.

De esta forma ya se tiene el control listo para usar, pudiendo acceder a sus propiedades en tiempo de diseño.

Un saludo a todos y espero que os guste u os sea util, Anuar

Windows Presentation Foundation y Entity Framework, poderosa combinación II: No todo lo que reluce es oro.

Anuar Khan Ali — Mon, 22 Jun 2009 08:04:00 GMT

Una de las principales características de Windows Presentation Foundation (WPF) es el Data Binding, con el se puede unir de una forma rápida la interfaz de usuario con nuestras propiedades, ya sean datos de negocios o simplemente propiedades con las que se quieren controlar ciertas acciones de la interfaz.
Ahora bien, ¿qué aporta este Data Binding realmente? Pues lo que aporta es una forma de trabajar muy cómoda, tanto a nivel de diseño con Expression Blend o en código, de tal forma que si se tiene una serie de controles de texto que siempre utilizan la misma propiedad, al “bindear” estos controles a nuestra propiedad, solo se tiene que modificar el valor de la propiedad y todos los controles obtendrán ese valor en vez de tener que modificar manualmente el valor de cada uno de ellos.

Otro ejemplo muy visual, es el típico caso de que se quiere controlar la visibilidad o si son accesibles una serie de controles en función por ejemplo, de una política de usuario como puede ser, que sea o no administrador de la aplicación. En este caso bastaría con “bindear” la propiedad de visibilidad o de habilitado a una propiedad, y al cambiar el valor esta propiedad cambiarían la visibilidad o el estado de habilitado automáticamente, sin tener que tocar manualmente cada control.
Así que siguiendo esta filosofía, se puede “bindear” las entidades que suministra Entity Frammework (EF) para los formularios controles que se tengan que desarrollar y así poder utilizar esta potente característica, de tal forma que solo modificando los valores de las propiedades de las entidades que proporciona EF y que todo ello se refresque en nuestra interfaz.

Pero como dice el titulo de este post “No todo lo que reluce es oro”. ¿Y esto por qué? Pues porque el Data Binding de WPF está pensado para utilizarse con Dependency Properties, que es un tipo de propiedades un poco especiales, tienen varias características importantes, como que permite un coerce o validación de los datos, pero la característica que más importante para el caso que nos ocupa es que estas propiedades implementan INotifyPropertyChanged y heredan de la clase DepencyObject, con lo cual lanzan un evento de cambio cada vez que se actualiza la propiedad. Este evento de cambio lanzado por la propiedad es recogido por WPF y el gestiona automáticamente los cambios y actualiza los datos en pantalla sin tener que actualizar manualmente los valores en los controles.
¿Y cuál es nuestro problema? Pues por si no os habéis dado cuenta todavía, las entidades que proporciona EF, no implementan INotifyPropertyChanged, por lo tanto si “bindeamos” estas entidades la interfaz de WPF no se enterara de los cambios. Así que nuestro gozo en pozo y todas las expectativas e ilusiones se acaban de diluir.

Pero tampoco hay que desesperar, siempre se encuentra una solución. Básicamente se tienen tres posibilidades ante este problema.
La primera posibilidad es crear una Dependency Property del tipo de la entidad de EF, en el código subyacente del control de usuario a utilizar. Esta posibilidad tiene una gran limitación, y es que de esta forma la interfaz se da cuenta de los cambios de entidad no de los cambios de las propiedades de la entidad, así que este caso no es útil en la mayoría de los casos.

La segunda posibilidad es crear un nuevo grafo en memoria de las entidades de EF, pero esta vez heredando de DependencyObject y las propiedades siendo Dependency Properties. Esta posibilidad da toda el jugo a WPF y toda las posibilidades, pero en contra tiene que puede ser complicado y pesado reconstruir el grafo, sobre todo si se está trabajando con servicios, y que hay que manejar con mucho cuidado los cambios para que el contexto siempre siga la traza de nuestras Entidades.
La tercera posibilidad, no es tan potente como la anterior pero en muchos casos es suficiente. La forma de realizarlo es la siguiente: Se crean clases parciales de las entidades que proporciona EF y estas clases se hace que implementen INotifyPropertyChanged, ya que no se tiene ninguna restricción para implementar interfaces. Después se hace que las propiedades lancen en evento de cambio.

De esta forma WPF será consciente de los cambios y actualizara la interfaz de modo automático como si estuviera trabajando con Dependency Properties. Esta opción no da todas las posibilidades que si se usara Dependency Property pero en muchos casos será muy útil y suficiente.
Bueno y hasta aquí este segundo post sobre WPF y EF, espero que os haya parecido interesante u os resulte útil.

Un saludo, Anuar.

Windows Presentation Foundation y Entity Framework, poderosa combinación I : Como surtir de datos a un control TreeView

Anuar Khan Ali — Tue, 10 Mar 2009 17:39:00 GMT

En uno de los proyectos los que estamos trabajando en Plain Concepts, hemos tenido que trabajar con el control TreeView de Windows Presentation Foundation (WPF) y con Entity Framework (EF), como fuente de los datos que se suministran a nuestro control TreeView, así que voy a ir escribiendo una serie de post con el titulo "Windows Presentation Foundation y Entity Framework, poderosa combinación" sobre cómo combinar estas grandes tecnologías.

En este primer post voy a centrarme en cómo definir la forma de suministrar los datos al control TreeView.

El control TreeView, como otros controles que heredan de la clase ItemsControl, admiten dos formas de insertarle los elementos hijos. A través de la propiedad ItemSource en el que podemos pasarle una colección que implemente IEnumerable, o bien con la propiedad Items e ir añadiendo los elementos que queramos. Estas dos formas no se pueden combinar, sino que debemos de escoger entre una u otra para surtir a nuestro control de los datos que queremos. Ahora bien, ¿Qué diferencias hay, o cuando es conveniente usar una forma o la otra?

Si utilizamos ItemSource, simplemente le pasamos la colección en la que tenemos los datos, y el añade los elementos de la propia colección. ¿Pero qué ocurre si queremos añadir o eliminar la lista? Pues que si no hemos definido un Databinding debemos de modificar la colección y volver a modificar el valor de la propiedad ItemSource. En un principio esta forma de trabajar esta más pensada para elementos que son listas de objetos, como ListView, ListBox o ComboBox, en la que no se va ir modificando la colección. Como añadido a este caso, podemos pasarle a la propiedad ItemSource una estructura Hierarchical DataTemplates, como por ejemplo un XML, y el propio control TreeView es capaz de representarnos esta estructura jerarquica. Este caso lo veremos más en particular en un futuro post.

El otro camino de trabajar con el control TreeView es ir añadiendo manualmente los objetos a través de la propiedad Items. Para ser más exactos la forma correcta seria ir añadiendo TreeViewItems, insertar en la propiedad DataContex el objeto que queramos poner en el árbol, e ir anidando la estructura de datos que queremos obtener, ya que a un elemento TreeViewItem le podemos ir añadiendo hijos de la misma manera que al control TreeView.
Un ejemplo de cómo realizar este caso, puede ser el siguiente código.

List<Aplicacion> source = Aplications.RetrieveAllAplications();

foreach (Aplicacion item in source)

{

TreeViewItem aux = new TreeViewItem();

aux.DataContext = item;

node.Items.Add(aux);

}

Hasta aquí este primer post, espero que os pueda ser de utilizad, en los siguientes post iremos viendo mas curiosidades y características sobre el control TreeView

Año nuevo, blog nuevo

Anuar Khan Ali — Wed, 07 Jan 2009 10:44:00 GMT

Hola a todos, soy Anuar Khan Alí y desde septiembre soy miembro de la PlainNave, después de unos meses de aterrizaje y transición me he decidido a inaugurar mi blog de Geeks. Presumiblemente iré hablando sobre WPF y EF principalmente, y puede que vez en cuando sobre SharePoint, verdad Juan Carlos.

Tan solo dar las gracias a Plain Concepts por esta oportunidad y un saludo a todo Geeks.

Anuar