Plop, comme convenu je te réponds en MP En fait ton analogie avec les pages JSP n'est pas tout à fait exact, car le langage CM est typiquement un langage de template, ce n'est pas un langage conditionnel. La logique de ce langage est de diviser totalement le développement de freeBrowser. D'une part : * Le côté développement * Le côté interface graphique. L'interface graphique ne fait pas intervenir de code conditionnel, uniquement du code de présentation et de manipulation de contenu. Ainsi des graphistes ayant des connaissances en HTML et XML peuvent facilement développer des interfaces utilisateurs pour freeBrowser. Il n'y a aucun côté développement dans les skins (je m'éfforce de garder le plus de distance dans le langage CM par rapport à un langage de script). Donc l'analogie avec les pages JSP n'est pas tout à fait exacte. D'autre part : * L'architecture plugin de fB. Chaque fonction que ce soit la navigation de fichiers, le traitement des images, la récupération des tags mp3 de la playlist audio, ou encore l'affichage de pannel 'dynamique' sont des plugins bien distinct. Ces plugins fournissent alors une arborescence de contenu ( à la manière de service via un contenu XML) qui peut être exploité via le langage CM. Pour afficher la liste des répertoire par exemple : Code:
>
Ce modèle dispose de nombreux avantages : * Dissociation du design et du fonctionnel, qui permet le travail en parallèle de 2 équipes (à la manière des sites web actuels) * Généralisation de processus (gestion automatique de la pagination par exemple, ou encore la génération de clés permettant de trier des données d'un tableau) * Potentiel graphique très diversifié car dissocié de tout code "en brute", on peut placer le contenu de n'importe quel plugin où on veut, et surtout afficher ce que l'on souhaite du plugin. * Développement unifié et réutilisable en associant plusieurs plugins dans les skins. Par exemple associer le plugin qui récupère les tags ID3 des mp3s avec celui chargé de récupérer les pochettes selon le nom de l'artiste et le nom de l'album, ainsi que le plugin chargé de convertir toute image en gif au format spécifié. Cela permet ainsi d'afficher la pochette de l'album en cours d'écoute. * Développement facilement déboguable (pas d'imbrication de code entrainant des effets de bords, chaque plugin est dans son propre domaine) * Et surtout, un gros point fort de ce système : réutilisation de cette technologie pour l'associer à des utilisations diverses, possible lorsque l'interface utilisateur est générée dynamiquement par un système de texte : - Freeplayer = HTML 3.0 - Web = HTML + javascript + toutes les technos web locales - Standalone = interface graphique élaborée, très proche de meedio ou encore windows media player grace à XAML, exemple : http://up.mezimages.com/up/09/1124799TestXAML.JPG On peut imaginer d'autres types d'interface utilisateur, ou simplement transformer freeBrowser en serveur de streaming. Donc comme tu peux le voir, les avantages d'un tel système sont très nombreux, le points négatifs selon moi : * Temps de développement au début très long afin de mettre en place le langage et la technologie de plugins, ainsi que la première skin de test. * Le CM étant un langage maison, il faut bien optimiser l'interpéteur pour ne pas avoir trop de temps de latence. * Le CM étant un nouveau langage il faut faire du support au début, heureusement le langage est simple à prendre en main. * Avec ce genre de technologie, le problème est que l'on a toujours envi d'en faire toujours plus :} à cause de la liberté proposée. Le CM st un langage de tempalte, on peut l'utiliser pour d'autres choses, c'est ce que j'ai fait pour générer les documentations automatiques des plguins, exemple : http://geffd.free.fr/Coding/FreePlayer/FB_SDK/Docs/doc.html Voila j'espère que mon explication t'auras intéressé Si tu as des objections des idées ou quelquonque remarque, je suis ouvert L'échange nous permettant de progresser