Je me rappelle que, il y a quelques années, je me demandais pourquoi la plus grande partie des applications client riche avait un design très peu flatteur, alors qu'on retrouve du design bien plus poussé dans les applications Web. Cela ressemblait à une contradiction, puisque sur le client riche on dispose de beaucoup plus de moyen pour bien exploiter les capacités graphiques de la machine que dans un browser.

   J'avais à l'époque passé un peu de temps avant de me rendre compte (je suis peut être un peu stupide sur les bords?) que c'était parceque le modèle de développement n'était pas du tout le même. Sur les applications Web, les designers s'occupent de créer la charte graphique, et les développeurs s'attellent à ne créer que les fonctionnalités dynamiques (accès aux bases de données, traitement des interactions utilisateur, validation, ... etc). Ce qui m'avait pris un temps de réflexion était le pourquoi, avant de me rendre compte que c'était facile de créer des applications de design qui générent du code, mais qu'il faut encore que le code qui gère l'affichage soit séparé de celui qui gère les aspects dynamiques, et que HTML remplissait ce rôle. Je savait pertinament qu'il n'était pas facile de dépasser les fonctionnalités de HTML (temps pour normaliser, temps pour implémenter les nouvelles normes, puis temps pour que cette nouvelle norme soit supportée par la majorité des browser) et que cette opération prennait des années.

   Quand XML est arrivé, on pensait que c'était un bon moyen pour que, sur le Web au moins, on puisse créer du code qui exploiter facilement toutes fonctionnalités nouvelles des nouveaux browsers sans pour autant perdre la compatibilité avec les browsers ancien (différents XSLT en fonction du UserAgent). D'ailleur, on pouvait aussi imaginer que les applications client riche utilisent le même modèle en basant la génération dynamique de l'affichage sur du XML. Le problème restait que l'affichage était cintrolé par le XSLT, et donc que c'était aux développeurs de le traiter et non pas aux designers... et donc le modèle en entier cassait.

   Aujourd'hui, nous avons enfin un modèle qui permet de séparer réellement le code du contenu, que ce soit dans des applications client riche ou lèger, et ce modèle se base sur une forme de XML appellée XAML (Extended Application Markup Language). Ce modèle à été conçu par Microsoft dans le cadre de la refonte du sous système de présentation de Windows qui fera partie de Windows "Longhorn" (prévu pour 2006). Ce qui est intéressant dans ce modèle, c'est qu'il offre un modèle semblable à HTML, sauf qu'il est utilisable sur tout type de client, et que le code n'a pas a être mélangé dans le HTML (même plus que ce n'était le cas avec ASP.Net).

   Le principe est très simple :

•  Le code déclaratif (XAML) permet  une utilisation très riche des possibilités graphgiques (contrôles, documents, médias, transparence, effets, animlations, transformations ..etc). il est donc possible de faire des designs impresionnant avec XAML (ce que Adobe a très vite compris et a commencé à préparer des applications de design basées sur XAML). Ce code sera utilisé par le compilateur comme une classe partielle complètée par le la classe qui est dans le code (sans avoir à ajouter des balises ou quoi que ce soit)
• Le code fait en langage de développement qui constitue une classe partielle complétée par le XAML.

   Même si ce modèle fait partie de Windows Longhorn, on peut d'ors et déjà l'utiliser à travers les outils tels que Xamlon (interprétation du XAML en runtime, et code behind dans un code séparé) et les divers générateurs XAML qui permettent de transformer des documents Illustrator ou After Effect (ou autres) en XAML. Les résultats sont impéssioanants...

4/6/2004 11:57:08 AM UTC