Nuevos temas lanzados para Silverlight 4.0 – Estupendo pero.. es suficiente?

Recientemte Tim Heuer ha lanzado varios «themes» para Silverlight 4, podeis leer http://timheuer.com/blog/archive/2010/05/03/new-silverlight-4-themes-available-for-download.aspx y http://timheuer.com/blog/archive/2010/05/17/silverlight-4-tools-released-and-new-application-templates.aspx, junto con el lanzamiento de las Silverlight tools for Visual Studio 2010.
Aunque esta noticia se vio abrumada por la de las tools, creo que es muy interesante ya que estan definiendo (o como minimo proponiendo) un estándar para la definición de temas para Silverllight…
 
Realmente hacia tiempo que esperabamos un ejemplo como estos, ya que es lo que pretende Silverlight & WPF y como herramienta de diseño Blend: Desacoplar la interacción entre la parte relativa al diseñador y la parte asociada al desarrollador.
 
Este trabajo se mejoró con la aparición de los comportamientos, en Blend -Silverlight 3.0  y con soporte mejorado para Blend 4.0 (beta) y SL 4.0.
 
Por ahora el modo de generar y manejar todo esto, es colocar una serie de archivos en una carpeta de «Assets» que si se hace bien contempla varios archivos de estilos, librerias de recursos y varios comportamientos, ver http://storage.timheuer.com/newthemes-structure1.png
Tambien puede incorporar alguna fuente, imagen o video, segun el estilo en cuestión.
 
Ello en si es algo grande, nos permite desacoplar la interacción de estilos y es relativamente simple…. para desarrolladores…  para un diseñador «puro» esto es complejo y cuesta.
 
Mi propuesta de enfoque es simplificar aun más el modelo de interacción para los temas ya que tienen entidad propia, pues asignarles un tipo de proyecto propio, Biblioteca de temas, estilo cosmopolitan.theme.dll…
 
De forma que un diseñador pueda crear una biblioteca de temas estilo «Cosmopolitan.theme.dll» y la aplicación pueda cambiar en cualquier momento el theme que utiliza sin tener que eliminar archivos de estilos, behaviors, imagenes, fuentes, etc… sino incluso pueda tener varias librerias de estilo asociadas y cambiarla como desee vía codigo o, mejor, mediante un comportamiento.
 
Ventajas de mi propuesta:
  • El diseñador podrá abstraerse de la complejidad de la aplicacion y diseñar solo en la biblioteca de estilos.
  • El diseñador evita tocar todo código sensible del desarrollador – favorecemos la separación y desacoplamiento.
  • Favorecemos el mercado potencial de «themes» para Silverlight. Si yo quiero vender themes, seria bueno que la tecnología los soportase.
  • Favorece el reaprovechamiento de themes para crear otros y estimular asi la creatividad y «competitividad» entre diseñadores (y desarrolladores).
  • Se hara por fin muy visible la ventaja de Blend y Silverlight para desacoplar totalmente la parte de aspecto e interacción visual con la de programación. (muy necesario).
 
Por otro lado es muy facil montar un proyecto de test generico en el cual se visualicen varias paginas con todos los controles, los de SL basicos, los del SDK, graficos, los de la Toolkit asi como que sea facil de añadir dinamicamente controles propios… y que el diseñador probase el estilo sin menor problema.
 
Y ya por pedir, esto seria buenisimo que estuviera integrado en Blend 4.0….
Por otro lado, el tipo de dll propuesto «theme.dll» no es que es más que una dll normal de silverlight, es solo una plantilla facil de hacer con implementaciones de todos los controles por defecto. solo se cambiarian las plantillas para que gestionaran estas plantillas permitiendo su carga y descarga dinamica en base al directorio de Assets, por ejemplo). MEF nos permitiria hacer esto muy facilmente..
 
Como lo veis? que opinion os merece esta idea??

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *