Le 21 Octobre 2004 avait lieu la première édition Parisienne de MAX, cycle de conférences Macromedia.
Bien que l'évènement soit payant (90€), il y avait affluence ce jour là au Palais des Congrès, dont cinq salles de conférence avaient été réservé pour l'occasion, ainsi que le patio du 2ème étage. Nous avons assisté à quelques conférences, dont voici le résumé, rien que pour vous, avec en prime une interview de Mike Chambers...

MAX : "Maturité de l'intérêt pour les design pattern"

Sur la brochure présentant les conférences du salon Max, celle de Mike Chambers était intitulée "Maturité de l'intérêt pour Action script 2". Là, on se dit que Macromedia a utilisé pour cette brochure la même méthode que pour la doc de Flash : laisser faire un logiciel de traduction et (surtout) ne pas faire relire par quelqu'un de compétent.
Une fois la conférence commencée, cette mauvaise surprise est oubliée puisque Chambers nous indique qu'en réalité la conférence s'intitule "Architecting applications with Flash": pas grand chose à voir, donc, avec le titre français (enfin, français, c'est vite dit) de la brochure. On est tout de suite rassuré, d'autant que ça parait tout de suite plus intriguant ! De toute façon cette conférence se déroulera uniquement dans la langue de Benny Hill, ce qui n'est pas plus mal.

Dans le langage Macromedia, ce qu'il faut comprendre par "architecting applications", c'est tout simplement implémenter des design patterns. Car c'est bien de cela dont il s'est agit lors de cette conférence : démontrer l'intéret des design pattern, créer des API, et les implémenter. Plus précisemment c'est le design pattern MVC qui a été à l'honneur au travers de trois exemples à l'intérêt inégal.

Pour celles et ceux qui ignorent ce que sont les design pattern, je rappellerai juste qu'il s'agit de modèles théoriques de programmation (orientés objets le plus souvent), ayant pour but de s'appliquer à différents cas de figure souvent rencontrés lors du développement d'applications. Ce sont donc des structures théoriques traduites en API (application programming interface) puis implémentées dans un développement donné. Il existe un grand nombre de design pattern, pour des cas de figures très différents les uns des autres.

Notre conférencier a donc commencé par rappeller les nombreux bénéfices que le développement et l'implémentation de design pattern pouvaient apporter à une application: Une application qui utilise un design pattern sera plus facile à programmer, plus facile à étendre, plus facile à debugger, et plus adaptée au travail en équipe. Le développement sera sans doute un peu plus long qu'une application classique, mais cet investissement serait bien vite rentabilisé au regard des nombreux bénéfices susmentionnés. Voilà qui promet beaucoup, mais Mike Chambers a-t-il des arguments concrets à la hauteur de ces promesses alléchantes?

L'un des design pattern les plus utilisé est celui du Model View Controller (MVC) qui a pour objet de gérer les relations d'une application cliente vis-à-vis de données côté serveur de manière cohérente. Le principe est ici de distinguer de manière forte les classes chargées d'afficher les données, la ou les Classes View, de celles chargées de les manipuler (envoi, reception, modification...), la classe Controller.

Après avoir donné un premier exemple à l'intérêt assez nébuleux sur lequel je ne reviendrai pas, Chambers rentre enfin dans le vif du sujet avec une application d'aggregateur de news au doux nom de MXNA (que vous trouverez sur son site). Il nous présente alors un fla dont la scène ne contient qu'un seul MovieClip, qui lui même contient tous les éléments de l'application. Ce grand MovieClip est une instance de sa classe Controller, elle même sous classe de MovieClip bien entendu.
Dans cette classe, on notera que toutes initialisations sont faites dans une méthode onLoad pour éviter les problèmes de chargement de composant (qui se font parfois un peu tard comme vous l'avez peut être noté). La classe joue ensuite son rôle de "cerveau" de l'application, transmettant les données vers et depuis flash, indiquant les événements adéquats aux composants UI d'affichage.
On notera l'utilisation lors du broadcast d'événement de la classe mx.Utils.Delegate apparue avec Ellipsis et qui a pour objet de determiner le scope de la diffusion d'un événement et la fonction qui y est associée. La classe View, quant à elle, remplit parfaitement son rôle en affichant les données qui lui sont transmises à la survenance d'un événement donné, et en diffusant elle-même un évenement lors de modifications éventuelles.

Malheureusement, Chambers a manifestement été pris par le temps puisqu'il finira un peu vite la présentation de cet exemple, puis passera rapidement sur les deux exemples suivants qui auraient pourtant pu s'avérer intéressants.
Le premier était une application du webservice de recherche de google codée, contrairement aux exemples précédents, en AS1. On aura donc pas l'occasion d'y apprendre grand chose si ce n'est que notre interlocuteur utilise, lorsqu'il développe une application avec onglets, un dataProvider label(nom de l'onglet)/data(reference du clip de l'onglet) qui se chargera de gérer la visibilité des clips à la survenance d'un évenement de clic sur l'onglet.
Le dernier exemple était une implémentation Flex de son aplication MXNA, 100% texte donc, sur laquel notre ami Mike ne passera donc que très peu de temps. Dommage car c'était prometteur, mais plus d'infos devraient être disponibles sur son site dès la sortie de la prochaine version de Flex.

Pour conclure, cette conférence s'est avérée suprenante à de nombreux égards, inégale car frustrante sur certains aspects, mais elle aura au moins eu pour mérite de montrer la volonté de Macromedia de démocratiser les design pattern vers la communauté flash dont ces pratiques issues des langages de bas niveau sont ignorées, ou assez mal connues.

par Dehats.