Le framework Flex permet d’écrire très rapidement des IHM fonctionnelles, notamment grâce au langage MXML. Celui-ci permet effectivement de décrire l’interface avec peu de lignes de code.

Seulement, voilà, une fois l’étape du POC passée, les fichiers MXML s’accumulent, le code ActionScript s’insinue petit à petit dans le code MXML pour implémenter les handlers d’événements, les appels de services, la logique métier. Après quelques temps, il devient de plus en plus difficile de savoir d’où viennent les données affichées (ie. quel code a mis à jour la donnée ?), d’où provient un appel de service (surtout d’où proviennent les valeurs des arguments de cet appel).

Dans cet article, nous verrons quelques bonnes pratiques permettant d’assurer la maintenabilité d’une application Flex.

Séparation des responsabilités

La première étape consiste à séparer les responsabilités du code de l’application. En effet, lorsqu’une même méthode doit collecter les données (ex : dans un formulaire), les préparer pour l’appel d’un service distant, appeler le service et mettre à jour la vue, il devient difficile de la tester ou de retrouver l’origine d’un bug.

Commençons par le modèle de données qui gagnera à se retrouver dans des classes séparées. En effet, il sera alors plus facile d’identifier les données à mettre à jour. Par exemple, lorsque le résultat d’un appel de service arrive, les données reçues seront placée dans ce modèle. Plus besoin de se poser la question de savoir si toutes les données ont été mises à jour, elles sont uniques et regroupées dans ces classes de modèle. On créera, par exemple, un modèle par vue (au sens fonctionnel de l’application).

Ensuite, les appels de services méritent eux aussi d’être encapsulés dans des classes dédiées afin de ne pas écrire 3 fois le même code technique et de les écrire de 3 façons différentes. Il deviendra alors simple d’ajouter des fonctionnalités communes aux appels de services (ex : authentification, gestion des exceptions, …) et de les remplacer par des mocks dans les tests.

On retrouve ainsi quelques-unes des recommandations du pattern MVC et de ses cousins (MVVM, MVP, …), c’est toujours bon de se les remémorer de temps à autre.
En Flex, il existe un certain nombre de frameworks comme Cairngorm, PureMVC ou encore Mate (et bien d’autres) qui vous permettront de mettre en place cette séparation des responsabilités et ainsi d’améliorer la maintenabilité (en même temps que la testabilité) de votre application. Il ne faut cependant pas obligatoirement sélectionner l’un de ces frameworks tant que quelques règles d’organisation du code ont été définies et partagées par tous les développeurs du projet. Ces frameworks ne sont qu’un moyen d’appliquer ces règles.

Circulation des données

La seconde étape consiste à définir « un sens de circulation » des données dans l’application afin de faciliter le debuggage de celle-ci (ie. mieux comprendre d’où viennent les données et où vont les données) et de favoriser la réutilisation et testabilité des composants Flex écrits.

La partie « vue » d’une application Flex se définie par un arbre de composants (MXML et ActionScript) :

Les nœuds de l’arbre étant des composants conteneurs (*Box, Canvas, List, …) contenant d’autres composants plus primitifs (Label, Button, …) ou d’autres conteneurs.
Avec une séparation entre le modèle et les appels de services et la vue, il reste que n’importe quel composant peut se binder sur le modèle de données et peut effectuer un appel de service. Ce composant n’est alors plus réutilisable dans un autre contexte : il dépend des données sur lesquelles il est bindé et ne peut plus être utilisé pour en afficher d’autres. Pour lever cette limite, il faut que les données sur lesquelles il se binde lui soit injectées.
De même pour les appels de services, pour que le composant puisse être utilisé dans un autre contexte (qui nécessite l’appel d’un autre service ou qui ne nécessiterait pas d’appel du tout), il faut supprimer la dépendance vers cet appel de service (ie. le composant ne devrait même pas « savoir » qu’un appel est effectué lorsqu’un événement intervient).

La solution à ces 2 problèmes de dépendance est de repousser le problème au composant parent . Ce composant parent pourra alors, soit déporter à nouveau le problème à son parent (en ajoutant des informations au passage si besoin), soit être lui-même dépendant du modèle et du service. En fait, à partir d’un certain seuil dans la hiérarchie de composants (en la remontant), il n’est plus vraiment envisageable de parler réutilisation (cela peut être le composant racine) et avoir des dépendances n’est plus vraiment problématique.

On obtient alors une circulation des données qui ressemble à ceci :

Les données redescendent la hiérarchie via le binding (ie. un composant binde ses attributs aux attributs des composants qu’il contient) :

Dans View1.mxml :

<Componentx title="{modelView1.viewTitle}" />

Dans ComponentX.mxml :

<mx:Label text="{title}" />

Et elles remontent par l’intermédiaire d’événements envoyés par les composants les plus bas dans la hiérarchie. Ces événements sont retransmis (avec du code ou avec la fonctionnalité de bubbling qui leur permet de remonter automatiquement la hiérarchie de composants) ou transformés en événement de plus haut niveau par le composant parent.

Dans ComponentX.mxml :

<mx:Button click="dispatchEvent(new AddItemEvent(this.item))" />

Dans View1.mxml :

<Componentx addItem="serviceProxy.addItem(event.item)" />

Ce mode de fonctionnement revient en fait à définir une API claire des composants développés :

• Les attributs exposés reçoivent les données en entrée
• Les données ressortent via les événements envoyés par le composant

Au passage cela facilite ainsi la testabilité du composant.

Conclusion

Une fois ces 2 principes appliqués sur une application Flex, celle-ci devrait mieux résister à l’augmentation de la quantité de code et rester maintenable plus longtemps. Il faut cependant garder à l’esprit que ces principes ne seront probablement pas suffisant et de nouveaux devront être imaginés s’adaptant au contexte de chaque projet afin de favoriser la lecture du code de l’application dans sa globalité.

Suggestion d'articles :

1. Quand Spring s’invite dans une application Flex …
2. Flex vs Silverlight
3. Référencer les applications RIA Flex et Silverlight

Alors que Macromedia (racheté en 2005 par Adobe) était parti seul devant, début 2004, dans le développement d’applications RIA en sortant la première version de Flex, voilà que fin 2006 (plus de 2 ans après donc), Microsoft dévoile une première version de sa réponse à Flex nommée Silverlight. Seulement, cette première version n’était là que pour « occuper le terrain » car elle restait encore très loin derrière Flex qui passait à peu près au même moment en version 2. D’ailleurs, à peine cette première version de Silverlight sortie, Microsoft annonçait déjà les premières versions Alpha de la v2 qui viendrait avec une machine virtuelle plus performante, une version allégée de la CLR .Net, en lieu et place du moteur Javascript de la v1. Alors que la v2 est sortie en fin d’année dernière, la v3 sort seulement un peu plus de 6 mois après. Il semble donc que malgré son retard, Microsoft produit à un rythme impressionnant de nouvelles versions de Silverlight en apportant à chaque fois un nombre non négligeable de nouvelles fonctionnalités. Même si Adobe continue de faire évoluer sa plateforme et s’apprête à sortir la version 4 d’ici la fin de l’année, les deux technologies sont aujourd’hui au coude à coude.
Dans cet article, nous ferons un tour panoramique de ces deux technologies afin de pointer leurs similitudes et différences.

Le principe de fonctionnement

Les deux technologies, que ce soit Flex ou Silverlight, fonctionnent exactement selon le même principe :
Il s’agit d’une application embarquée dans une page HTML (donc téléchargée depuis un serveur web) dont l’exécution s’effectue sur le poste client et est totalement déléguée à un plugin tiers du navigateur web, le Player Flash pour Flex et un nouveau plugin fourni par Microsoft pour Silverlight.
Flex profite bien évidemment de la popularité de déploiement du Player Flash installé sur une grande majorité des machines connectées à Internet. Pour le plugin Silverlight, tout reste à faire mais Microsoft rattrape vite son retard, notamment en profitant d’autres canaux de distribution que le navigateur web tel que Windows Update.

Une fois démarrées, ces applications fonctionnent en mode client-serveur, c’est à dire en gardant l’état de l’application (ie. la session utilisateur) sur le poste client et en effectuant des appels de services avec le serveur.

Le modèle de programmation

Concernant le modèle de développement, on retrouve là encore de grandes similitudes entre Flex et Silverlight qui utilisent toutes les deux un format de fichier XML pour décrire l’IHM : MXML pour Flex et XAML pour Silverlight (emprunté à WPF). Ces fichiers XML permettent de décrire l’agencement des composants graphiques et de paramétrer les propriétés de ces composants.

Exemple MXML :

<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml">
    <mx:Text text="Hello World !" />
</mx>

Exemple XAML :

<UserControl x:Class="SilverlightApplication2.Page"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    Width="400" Height="300">
    <Grid x:Name="LayoutRoot" Background="White">
        <TextBox Text="Hello World !" />
    </Grid>
</UserControl<

Associés à ces fichiers XML, un langage de programmation objet est utilisé afin de traiter la dynamique de l’application : les événements utilisateur et la logique de l’IHM. Alors que Flex utilise l’ActionScript 3 qui est le langage de prédilection du Player Flash, Silverlight s’appuit sur C# (et même d’autres languages tels que IronPython ou IronRuby). C’est un gros avantage pour Silverlight qui profite de la maturité de C#, beaucoup plus avancé qu’ActionScript tant en terme de langage que d’outillage. En effet, C# a été pensé dès le départ pour le développement d’application alors qu’ActionScript a commencé en tant que langage de scripting pour les applets Flash pour ensuite évoluer vers un langage objet typé fortement.

Ce n’est pas seulement le langage en lui-même dont profite Silverlight mais aussi de tout l’écosystème .Net. En effet, une application développée avec Silverlight pourra profiter de la plupart des bibliothèques .Net (après recompilation), mais aussi du grand nombre d’outils disponibles pour le développement .Net.
L’écosystème Flex, qui est en pleine ébullition, rattrape son retard avec des bibliothèques et des outils de développement en tout genre qui sortent régulièrement, notamment grâce à une communauté très active de projets opensource. Ils restent cependant jeunes face à .Net.

Enfin, même si la machine virtuelle de Silverlight est récente, elle a hérité des capacités de la CLR .Net et profite donc de la maturité de celle-ci comme par exemple des systèmes de compilation Just In Time ou de Garbage Collecting. La machine virtuelle du Player Flash, malgré ses évolutions récentes pour inclure ces mécanismes, reste moins avancée. Cette dernière profite cependant de la maturité de son moteur de rendu graphique, le Player Flash ayant toujours été adapté à l’animation graphique.

Les composants et le développement

Stratégies de chargement d’une application

En ce qui concerne les composants disponibles avec chacune des solutions, on retrouve à peu près les même composants en allant piocher dans des bibliothèques tierces. Silverlight vient cependant avec une bibliothèque de base moins complète que celle de Flex qui s’explique notamment par le choix du mode de compilation d’une application qui diffère d’une solution à l’autre.

En effet, le plugin Silverlight installé sur le poste de l’utilisateur ne contient pas seulement la machine virtuelle mais aussi la bibliothèque de composants de base alors que le Player Flash n’installe que la machine virtuelle (qui implémente seulement l’API bas-niveau de Flash). Cela se traduit par un plugin Flash de 1.8Mo et un plugin Silverlight de 4.7Mo. Le choix d’inclure la bibliothèque de composants de base dans le plugin Silverlight peut s’expliquer par le fait que la plupart des applications utiliseront ces composants et il n’est ainsi pas nécessaire de les retélécharger en même temps que chaque application.
De son côté, la solution n’incluant pas la bibliothèque de base dans le plugin a pour avantage de décorréler le cycle de vie du Player Flash et du SDK Flex mais ce n’est pas la seule raison. En effet, la stratégie de compilation Flex, et notamment la phase de link avec les bibliothèques, diffère de celle de Silverlight. Par défaut, lors de la compilation d’une application Flex, les composants disponibles dans les bibliothèques utilisées (dont le SDK et donc les composants de base) ne sont inclus dans le fichier SWF final que s’ils sont effectivement utilisés par l’application. Ainsi, toute la bibliothèque de composants de base Flex n’est pas inclue dans toutes les applications Flex contrairement à la stratégie de compilation d’une application Silverlight qui embarquera la totalité des bibliothèques utilisées. Flex implémente d’autres stratégies de compilation dont une similaire à la stratégie Silverlight (ie. le téléchargement des bibliothèques dans leur globalité) ou encore la possiblité de télécharger le SDK complet, de le mettre en cache et de le partager pour toutes les applications Flex tout en gardant une « inclusion sélective » des composants des autres bibliothèques utilisées.
Dans l’absolu, aucune solution n’est meilleure qu’une autre, tout dépendra du contexte de déploiement. Flex offre cependant une plus grande souplesse en permettant de maitriser plus finement la taille de l’application.

Création de composants

Une autre différence entre Silverlight et Flex se situe lors de la création de composants personnalisés.
En effet, Silverlight permet de créer deux types de composants, les composants utilisateurs qui sont écris en XAML et les composants personnalisés qui sont complètement écris en C# pour avoir la main sur le rendu du composants. Le premier type est simple à écrire (XAML + code behind en C# comme le reste de l’application Silverlight) mais ne permet pas d’hériter d’autres composants. Le second, par contre, permet l’héritage de composants mais doit être écrit totalement en C# et est donc beaucoup plus complexe à écrire.

En Flex, la création de composants reste plus simple. Pour créer un composant, il suffit de déplacer le morceau de MXML voulu dans un nouveau fichier. La balise racine de ce morceau de MXML devient le composant parent (en terme d’héritage objet). Pour avoir la main sur le rendu du composant, il suffit de surcharger la méthode adéquate de ce même composant (en mélangeant le MXML et l’AS). Flex favorise donc la création de composants réutilisables en ne proposant qu’une solution fexible plutôt que de multiples pour chaque cas d’usage.

Description de l’IHM

Le XAML permet d’aller plus loin en terme de description de l’IHM par rapport à MXML en offrant la possibilité de pouvoir dessiner avec le langage de balisage. Cette fonctionnalité est surtout utile pour des outils WYSIWYG (le résultat en XML étant peu Human Friendly) tel que Expression Blend pour Silverlight. Flex n’offrira cette fonctionnalité qu’avec la version 4 et son format FXG (http://opensource.adobe.com/wiki/display/flexsdk/FXG+1.0+Specification) manipulable avec les outils de la Creative Suite d’Adobe (et son future outil FlashCatalyst pour faire le pont entre designers et développeurs).

Styliser une application

Pour styliser une application, Flex et Silverlight utilisent là aussi des stratégies différentes :
Tout d’abord en ce qui concerne le style simple, c’est à dire les éléments stylisables prévus par le développeur d’un composant, Silverlight utilise des balises XAML pour déclarer des styles qui seront utilisés lors de l’instanciation d’un composant (via l’attribut Style).

Par exemple :

<Grid>
  <Grid.Resources>
    <Style TargetType="Button" x:Key="MyStyle">
      <Setter Property="Stroke" Value="Red"/>
    </Style>
  </Grid.Resources>

  <Button Style="{StaticResource MyStyle}" />
</Grid>

Flex, de son côté, utilise CSS (adaptés au système de composants Flex bien sûr). Celà permet d’utiliser une syntaxe connue des développeurs web et moins verbeuse que du XML.

Dans un fichier CSS :

Button {
  color: #FF0000;
}

Dans un fichier MXML :

<mx:Style source="style.css" />
<mx:Button />

Pour aller plus loin dans le style d’une application, il est utile de pouvoir complètement redessiner les composants. Silverlight utilise la notion de template qui permet de redéfinir en XAML le rendu d’un composant :

<Style TargetType="Button" x:Key="MyButton">
  <Setter Property="Template">
    <Setter.Value>
      <ControlTemplate TargetType="Button">
        <Border Background="Red">
          <TextBlock Text="Fixed text: " />
          <ContentPresenter Content="{TemplateBinding Content}“ />
        </Border>
      </ControlTemplate>
    </Setter.Value>
  </Setter>
</Style>

En Flex par contre, du moins jusqu’a la version 3, il est possible d’utiliser des skins Flash réalisées avec le studio Flash ou directement écrites en ActionScript. La solution de Silverlight est dans ce cas plus abordable et plus flexible puisque le template peut être aussi complexe que nécessaire, ce n’est pas juste une skin. Flex supportera de modifier le rendu d’un composant avec la version 4 en séparant la définition de la vue du reste du composant.

Système d’animation

Les systèmes d’animation de Silverlight et Flex offrent des possiblités équivalentes tout en ayant des approches différentes.
En Silverlight, une animation cible une propriété d’un composant dont elle lissera la transition d’une valeur à une autre.

<Storyboard x:Name="myStory">
  <DoubleAnimation From="0" To="42" Duration="0:0:2"
                   x:Name="moveAnimationX"
                   Storyboard.TargetName="myButton"
                   Storyboard.TargetProperty="x" />
  <DoubleAnimation From="0" To="42" Duration="0:0:2"
                   x:Name="moveAnimationY"
                   Storyboard.TargetName="myButton"
                   Storyboard.TargetProperty="y" />
</Storyboard>

<Button x:Name="myButton" />

Puis en C# :

1
2

...
myStory.Begin();

Alors qu’en Flex, une animation est de plus haut niveau et s’appliquera sur un composant. Son type déterminera le ou les attributs ciblés et se déclenchera lorsque l’attribut sera modifié (il est cependant possible de fonctionner de la même manière qu’en Silverlight : en déclanchant l’animation qui modifiera l’attribut d’un composant).

<mx:Move id="moveEffect" />

<mx:Button id="myButton" moveEffect="{moveEffect}" />

Puis en ActionScript :

1
2
3

...
myButton.x = 42;
myButton.y = 42;

La solution Flex est moins verbeuse, le MXML s’écrit plus facilement par un développeur alors que le XAML est encore une fois, plus destiné aux outils WYSIWYG.

Communication Client / Serveur

Un dernier point de comparaison qui diffère entre Flex et Silverlight est le système de communication client-serveur. Les deux technologies permettent toutes les deux d’effectuer des appels XML / HTTP et SOAP / HTTP selon un modèle de sécurité très proche (ie. appel de service sur le serveur d’où est téléchargé l’application et appel entre différents domaines géré avec un fichier de configuration : crossdomain.xml pour Flex et accesspolicy.xml pour Silverlight).

Pour simplifier le parsing du XML, Silverlight permet d’utiliser Linq alors que Flex utilise E4X (EcmaScript For XML : une syntaxe proche de l’objet pour parser du XML). Ceci permet donc aux 2 technologies de se connecter sur n’importe quel type de serveur qui sait exposer des WebServices SOAP ou REST.

Cependant, elles viennent chacune avec leur technologie d’appel de services qui permet de grandement simplifier la communication entre le client et le serveur. En effet, en utilisant des appels de service WCF en Silverlight ou AMF/HTTP en Flex (disponible en Java, PHP, Python ou Ruby), cela permet de bénéficier d’une (dé)sérialisation automatique que ce soit sur le client ou le serveur et simplifie grandement le développement de ce type d’applications.

Conclusion

Beaucoup de caractéristiques de chacune des technologies Flex et Silverlight n’ont pas été abordées dans cet article pour se concentrer sur ce qui peut servir à les différencier ou qui permet de mieux faire ressortir les avantages de l’une ou l’autre.

Silverlight, malgré le retard avec lequel la première version est sortie, a sû le rattraper en réutilisant la CLR, plus avancée que le Player Flash, mais aussi en s’appuyant sur tout l’ecosystème .Net tant en terme de langage avec C#, qu’en terme d’outillage.
Ainsi, aujourd’hui, les deux technologies ont des capacités équivalentes et quand une fonctionnalité n’existe pas dans l’une, la version suivante prévoit de combler le vide.

En terme de développement, Flex semble plus abordable lorsque l’on s’attarde sur le code écrit, tant en XML (MXML est globalement moins verbeux que XAML mais ce n’est pas un problème si l’on fait confiance aux outils WYSIWYG de Microsoft), qu’en AS et C# (pour l’appel de services par exemple ou la création/le parsing de XML en C# qui utilise une API plus complexe qu’en AS).

Enfin, l’écosystème dans lequel ces applications seront déployées a aussi son importance puisque, même si Flex et Silverlight s’intègrent parfaitement partout où il est possible de faire au moins du XML / HTTP, leur technologie de communication respective avec le serveur facilite grandement le développement mais lie du coup la technologie cliente avec la technologie serveur.
La cible des utilisateurs est aussi un critère déterminant sachant que pour une cible grand public, le Player Flash reste le plus déployé à l’heure actuelle alors que pour des applications internes, la disponibilité du plugin Silverlight ou Flash est maitrisable.

Pour aller plus loin sur la comparaison de Flex et Silverlight, allez voir la vidéo de la session Du RIA pour mon SI Microsoft Silverlight vs Adobe Flex présenté à l’Université du SI 2009.

Suggestion d'articles :

1. Référencer les applications RIA Flex et Silverlight
2. Formation Silverlight Tour à Paris les 19,20 et 21 janvier
3. Quand Spring s’invite dans une application Flex …

Ces derniers temps, il ne se passe pas un mois sans que l’on entende parler d’un nouveau framework destiné au développement d’application Flex. Parmi ceux-ci, deux d’entre eux retiennent notre attention puisqu’ils sont hébergés au sein de Spring. Ces deux projets sont Spring Actionscript (en incubation pour le moment) et Spring Flex.

Spring Flex n’est qu’une extension au projet Spring que les développeurs Java connaissent bien. Il permet d’exposer des classes Java sous forme de services BlazeDS depuis la configuration Spring.

Spring ActionScript par contre, est un conteneur IoC destiné à la partie cliente d’une application Flex. C’est sur celui-ci que nous nous attarderons dans cet article.

Les principes de base de Spring Actionscript

À l’origine, Spring Actionscript était un framework nommé Prana Framework et ne faisait pas partie de Spring. Son auteur a débuté Prana en suivant les même principes que Spring Java afin qu’un développeur Java connaissant déjà Spring puisse s’y retrouver rapidement.
C’est pourquoi le fichier de configuration ressemble très fortement à celui que l’on peut trouver en Java :

1
2
3
4
5
6
7
8
9
10
11
12
13
14

<objects>
	...
	<object id="remoteObject"
                class="mx.rpc.remoting.mxml.RemoteObject" abstract="true">
		<property name="endpoint"
                       value="http://localhost:8080/flexapp/messagebroker/amf" />
		<property name="showBusyCursor" value="true" />
	</object>
 
	<object id="myService" parent="remoteObject">
		<property name="destination" value="myService" />
	</object>
	...
</objects>

De même que pour la récupération d’un Object (là où Spring Java parle de Bean) :

1
2
3
4
5

applicationContext = new FlexXMLApplicationContext(["springas.xml"])
applicationContext.load()
...
var myObject: MyObject = applicationContext.getObject("myObject");
...

On retrouve donc la notion de contexte d’application depuis lequel on peut retrouver les objets déclarés dans le fichier de configuration.
Une petite différence cependant est la méthode load() de l’object context. En effet, le fichier de configuration (« springas.xml » dans l’exemple) est téléchargé par l’application Flex sur le serveur (via HTTP donc) lors de l’appel à cette méthode.

Maintenant que nous avons vu que nous retrouvons les même principes de fonctionnement que Spring Java sur notre application Flex, quand utiliser l’injection de dépendance de SpringAS ?

Un premier cas d’utilisation est de déclarer tout ce qui concerne la configuration de l’application comme par exemple la déclaration des services (HTTPService, WebService ou RemoteObject). Ceci évite donc d’avoir à recompiler l’application lors d’un changement dans la configuration des services.

Un autre cas d’utilisation est lorsqu’une application Flex est architecturée avec des responsabilités séparées dans différentes classes ; typiquement avec une architecture MVC, MVP ou autre.
Spring Actionscript supporte d’ailleurs, dans des « modules » séparés, Cairngorm et PureMVC. Ces deux frameworks MVC facilitent l’organisation du code d’une application Flex en séparant les responsabilités, mais le couplage entre les classes reste fort  dû à une utilisation abondante du pattern Singleton. SpringAS permet de les découpler en les liant seulement au travers d’interfaces et en injectant l’implémentation réelle d’après le fichier de configuration.

Intégration avec Spring Flex

Comme expliqué précédemment, les fichiers de configuration servant à initialiser le context SpringAS sont téléchargés sur le serveur via HTTP. Qui dit HTTP, dit URL mais pas forcément fichier. On peut ainsi générer ce fichier de configuration depuis une servlet (ou tout autre mécanisme de génération serveur) ?

Ça devient intéressant en utilisant Spring Flex. Celui-ci permet d’exposer une classe Java en tant que service Flex (au sens service BlazeDS et donc AMF/HTTP) juste à l’aide d’une déclaration dans le fichier de configuration Spring (Java cette fois-ci). Dans le fichier de configuration de SpringAS, on peut retrouver la déclaration des RemoteObjects, le pendant client de ces services Java. Pourquoi réécrire et maintenir cette configuration dans le fichier de configuration SpringAS alors que cela a déjà été fait dans la configuration Spring Java ?
Une simple servlet Java peut ainsi récupérer la liste des classes Java exposées en tant que service Flex depuis la configuration Spring Java et générer la configuration SpringAS (ici la même configuration que le premier exemple de l’article) :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

WebApplicationContext context = WebApplicationContextUtils.getWebApplicationContext(getServletContext());
String eol = System.getProperty("line.separator");
 
result.append("< ?xml version=\"1.0\" encoding=\"utf-8\" ?>").append(eol);
result.append("<objects>").append(eol);
 
URL requestURL = new URL(request.getRequestURL().toString());
result.append("<object id=\"remoteObject\" class=\"mx.rpc.remoting.mxml.RemoteObject\" abstract=\"true\">").append(eol);
result.append("<property name=\"endpoint\" value=\"http://").append(requestURL.getHost());
result.append(":").append(requestURL.getPort());
result.append(getServletContext().getContextPath());
result.append("/spring/messagebroker/amf\" />").append(eol);
result.append("<property name=\"showBusyCursor\" value=\"true\" />").append(eol);
result.append("</object>").append(eol);
 
String[] beanNames = context.getBeanNamesForType(FlexRemotingServiceExporter.class);
for (String beanName: beanNames) {
	result.append("<object id=\"").append(beanName).append("\" parent=\"remoteObject\">").append(eol);
	result.append("<property name=\"destination\" value=\"").append(beanName).append("\" />").append(eol);
	result.append("</object>").append(eol);
}
result.append("</objects>").append(eol);
 
response.getOutputStream().print(result.toString());

Conclusion

L’introduction de Spring sur la partie cliente d’une application peut être intéressante car elle apporte une certaine souplesse en séparant ce qui est de la configuration du reste du code, mais aussi en facilitant la testabilité de l’application en réduisant le couplage entre classes. Enfin, la génération de la configuration SpringAS sur le serveur permet d’imaginer des applications plus flexibles en « cablant » l’application dynamiquement (selon les droits de l’utilisateur par exemple).

Cependant, quelques problèmes persistent :

• il n’est pas possible d’utiliser d’annotations pour injecter automatiquement les attributs d’une classe alors que Actionscript les supporte. Un début de solution existe mais n’est pas encore inclu dans SpringAS,
• les classes qui ne sont pas utilisées (ie. qui n’ont pas de variables du type de la classe) par l’application principale mais seulement utilisées via le fichier de configuration ne seront pas inclues dans l’application à la compilation. Ceci est dû au fonctionnement du compilateur Flex qui n’inclut que les classes réellement utilisées. Or il n’a aucun moyen de déterminer que certaines classes seront utilisées après le chargement du fichier de configuration SpringAS. Pour contourner le problème il faut soit utiliser l’option « -includes » du compilateur et lui lister ces classes afin de le forcer à les inclure, soit déclarer des attributs fictifs (qui ne seront pas réellement utilisés) du type de ces classes dans l’application principale.

Enfin, même si SpringAS apporte de la souplesse à une architecture qui s’appuie sur Cairngorm, elle n’en diminue pas la complexité (il y a toujours autant, voir plus, de classes à créer). Un début de framework MVC semble en cours de développement au sein de SpringAS, peut-être nous apportera-t-il à la fois la simplicité et la souplesse. D’ici là, l’intérêt d’utiliser SpringAS pour une application Flex n’est pas donné et dépendra de chaque application et de son choix d’architecture.

Suggestion d'articles :

1. Intégrer GWT & Spring
2. Comparaison Google Guice et Spring
3. Spring-Batch : par quel bout le prendre ?

Pourquoi référencer une application dans les moteurs de recherche ?

Le référencement est une étape non négligeable du développement d’un site Internet. Ne pas référencer son application dans les moteurs de recherche revient à imprimer une plaquette publicitaire sans la distribuer. Si les moteurs de recherche savent parfaitement référencer un site HTML, qu’en est-il des applications RIA développées avec des technologies telles que Flex ou Silverlight ?

Pourquoi le référencement d’une application RIA pose-t-il problème ?

Les sites HTML standards répondent aux normes du consortium W3C. Il est ainsi facile pour les moteurs de recherche de parser et d’indexer les différentes pages d’un site en s’appuyant sur ces normes. Ces normes permettent également à votre navigateur de comprendre la façon dont il doit afficher la page HTML. Dans le cadre des applications RIA, le serveur envoi un fichier SWF (Flex) ou XAML (Silverlight) à votre navigateur qui doit utiliser des plugins pour interpréter ces fichiers. Les moteurs de recherche sont identiques à votre navigateur, ils ne savent pas encore comment bien indexer ces fichiers (bien que la spécification du format SWF soit publique depuis l’an dernier). Google et Yahoo! ne se contentent que d’indexer les textes statiques et suivre les liens hypertextes des SWF. Faites une simple recherche sur Google avec le mot-clé filetype:swf et vous observerez qu’il comprend le format du fichier et qu’il en indexe quelques textes, mais il faut avouer que cela est très pauvre. Faites la même recherche avec le mot-clé filetype:xaml et vous constaterez que Google ne comprend rien du tout. Précisons que le faible nombre de texte s’explique également par la manière dont est exécutée l’application, les données ne sont pas toujours présentes dans les fichiers SWF et XAML mais proviennent de services. Même si quelques textes sont récupérés des fichiers SWF, on ne peut modifier l’importance des mots clés. Tous les textes ont la même valeur contrairement à ce que l’on peut faire en HTML avec les balises titres (h1 à h6).

OK, mais ce problème est-il nouveau ?

La problématique du référencement des applications RIA n’est pas nouvelle, elle se posait déjà lorsque les applications Flash fleurissaient sur le net. A cette époque, le haut débit n’était pas très répandu. Le choix le plus répandu était de diviser le site en deux parties : un site Flash pour les connexions haut débit et un site HTML pour l’accès bas débit. Cette technique permettait d’être dans l’air du temps avec un site Flash tout en garantissant le référencement dans les moteurs de recherche avec la partie HTML.

Et les choses ont vraiment changé aujourd’hui pour le référencement d’une application Flex ?

Aujourd’hui les débits de connexion Internet ont évoluées ainsi que la technologie Flex qui permet de faire des applications riches permettant d’interagir avec des fichiers externes contrairement au Flash qui se résumait au fichier SWF. Comme il est impossible de réaliser un bon référencement sur ces fichiers, il faut orienter le référencement vers du contenu HTML alternatif et interdire le référencement des fichiers SWF en configurant le fichier robots.txt comme suit :

1
2

User-agent: *
Disallow: /monApplicationFlex.swf

Du contenu HTML alternatif ! Les méthodes n’ont donc pas évolué ?

Aujourd’hui, on ne construit plus un site alternatif complet mais on ajoute simplement du contenu HTML utile au référencement à la place de l’application Flex. La librairie JavaScript SWFObject permet de réaliser cette astuce simplement. Voici un exemple :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

<html xmlns="http://www.w3.org/1999/xhtml">
 <head>
 <title>Exemple d'utilisation de SWFObject</title>
 <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
 <script type="text/javascript" src="swfobject.js"></script>
 </head>
 <body>
 <div id="monContenuAlternatif">
   <h1>Mon application Flex</h1>
   <p>description de mon application</p>
 </div>
 <script type="text/javascript">
   swfobject.embedSWF("monApplicationFlex.swf", "monContenuAlternatif", "800", "400", "9.0.0");
 </script>
 </body>
</html>

Avec cette méthode, les moteurs de recherche ne voient que le contenu HTML alternatif du bloc monContenuAlternatif car ils n’interprètent pas le JavaScript. Quant aux utilisateurs, ils voient l’application Flex monApplicationFlex.swf se charger à la place du contenu du bloc monContenuAlternatif s’ils possèdent le lecteur Flash. L’intérêt est que l’on peut produire du contenu HTML hiérarchisé. Ainsi lorsqu’un moteur de recherche référencera cet exemple, il donnera plus d’importance au titre « Mon application Flex » qu’au paragraphe « description de mon application ». De la sorte, on peut optimiser à souhait le référencement de ce contenu alternatif et avoir un site respectant les standards du web. L’inconvénient de cette méthode est que les personnes ayant désactivé JavaScript mais possédant le lecteur Flash, ne verront pas se charger l’application Flex. Adobe revendique que 99% des internautes auraient le lecteur Flash d’installé tandis que le W3C rapporte un taux d’activation du JavaScript de seulement 95%.

Super mais je n’ai qu’un seul contenu alternatif dans ce cas, non ?

Au même titre qu’un site HTML classique, une URL correspond à un contenu, mais rien ne nous empèche que le contenu alternatif soit dynamiquement généré par le serveur. De la même manière, rien ne nous empèche de multiplier le nombre de pages HTML afin que l’application web soit accessible depuis plusieurs URL.

Mais ces différentes URL lanceront la même application Flex, alors pourquoi plusieurs pages ?

Tout d’abord, multiplier le nombre de page d’une application web est important pour le référencement. C’est autant de liens retour (backlinks) possible vers notre application, ce qui pourra la rendre plus populaire. En outre, les différentes URL lanceront la même application Flex mais son état peut dépendre de cette URL. Prenons l’exemple d’une application Flex répertoriant des livres. Il serait intéressant d’accéder directement aux livres d’un auteur depuis une URL. Par exemple, l’URL www.monsite.com/auteur/octo afficherait la liste des livres publiés par OCTO. Afin que l’application Flex fasse ce traitement, il suffit de récupérer ces informations de l’URL et de les transmettre à notre application en variable (FlashVars) :

1
2
3
4
5
6

<script type="text/javascript">
 var url = window.location.toString(); // http://www.monsite.com/auteur/octo
 var value = url.substr(url.indexOf(".com/", 0) + 5); // Pour ne garder que auteur/octo
 var flashvars = {url : value};
 swfobject.embedSWF("monApplicationFlex.swf", "monContenuAlternatif", "800", "400", "9.0.0", null, flashvars);
</script>

Dans cet exemple, notre application Flex récupère « auteur/octo » dans la variable url et sait qu’elle doit afficher les livres de l’auteur OCTO. On pourrait se dire que ce JavaScript est inutile car Flex gère le deep linking qui permet de bénéficier de tous les avantages de la navigation par URL. Pour cela, Flex s’appuie sur les fragments suivant les ancres symbolisés par le symbole #. Notre application Flex gèrait naturellement l’URL www.monsite.com#auteur/octo sans le JavaScript précédent. Le souci est que les fragments suivant les ancres ne sont pas référencés par les moteurs de recherche, ils ne référenceront pas l’URL www.monsite.com#auteur/octo mais l’URL www.monsite.com.

Intéressant, n’aurais-je pas pu récupérer ces informations dans ma page HTML au lieu de l’URL ?

C’est tout à fait envisageable si nos pages sont générées par le serveur, la variable FlashVars url aurait pu être directement valorisée à « auteur/octo » par celui-ci. En produisant du code xHTML, il est même possible de transmettre ce code dans une variable FlashVars à l’application Flex qui le parsera comme un simple fichier XML afin d’en exploiter les données. Voici un exemple étayant cette méthode :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

<html xmlns="http://www.w3.org/1999/xhtml">
 <head>
  <title>Exemple innerHTML</title>
  <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
  <script type="text/javascript" src="swfobject.js"></script>
 </head>
 <body>
  <div id="auteur">
   <h1>OCTO</h1>
   <ul>
    <li>Gestion des Identités</li>
    <li>Une Politique pour le Système d'Information</li>
   </ul>
  </div>
  <script type="text/javascript">
   var innerHTML = document.getElementById('auteur').innerHTML;
   var flashvars = {auteur : innerHTML};
   swfobject.embedSWF("monApplicationFlex.swf", "auteur", "800", "400", "9.0.0", null, flashvars);
  </script>
 </body>
</html>

Dans cet exemple, l’application Flex reçoit dans sa variable FlashVars auteur le contenu du bloc auteur. En parsant ce contenu XML, l’application Flex récupère le nom de l’auteur ainsi que sa liste de livres.

Très bien, je vois qu’il y a plusieurs possibilités pour les applications Flex, mais est-ce pareil pour les applications Silverlight ?

Dans son Kit de développement logiciel, Silverlight embarque un fichier JavaScript qui permet d’avoir le même comportement que SWFObject pour les applications Flex. Voici un simple exemple illustrant cette technique :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

<html xmlns="http://www.w3.org/1999/xhtml">
 <head>
 <title>Exemple d'utilisation de Silverlight</title>
 <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
 <script type="text/javascript" src="Silverlight.js"></script>
 </head>
 <body>
 <div id="monContenuAlternatif">
   <h1>Mon application Flex</h1>
   <p>description de mon application</p>
 </div>
 <script type="text/javascript">
   var monContenuAlternatif = document.getElementById("monContenuAlternatif");
   Silverlight.createObject("monApplicationSilverlight.xaml", monContenuAlternatif, "objectId", {width:'800', height:'400', minRuntimeVersion:'2.0'});
 </script>
 </body>
</html>

Les utilisateurs possédant le plugin Silverlight voient l’application à la place du contenu HTML alernatif que seuls les moteurs de recherche analyseront. Il en est de même avec l’utilisation de plusieurs URLs. Reprenons notre exemple de l’URL www.monsite.com/auteur/octo, nous allons récupérer les informations de cette URL et les transmettre à notre application en paramètre d’initialisation :

1
2
3
4
5
6

<script type="text/javascript">
 var url = window.location.toString(); // http://www.monsite.com/auteur/octo
 var value = url.substr(url.indexOf(".com/", 0) + 5); // Pour ne garder que auteur/octo
 var param = "url=" + value;
 Silverlight.createObject("monApplicationSilverlight.xaml", monContenuAlternatif, "objectId", {width:'800', height:'400', minRuntimeVersion:'2.0'}, null, param);
</script>

Par la même méthode, on pourrait facilement transmettre le contenu HTML alternatif en paramètre à notre application Silverlight afin d’exploiter son contenu.

Génial mais n’y a-t-il pas de techniques supplémentaires avec Silverlight ?

Il est existe une qui permet d’utiliser le fichier XAML de l’application Silverlight comme source du contenu HTML alternatif car le XAML est un document XML valide. L’utilisation d’un fichier XSLT permet de transformer les données intéressantes du XAML en contenu HTML. Regardons à travers un exemple afin de reproduire le contenu HTML de l’exemple innerHTML :

1
2
3
4
5
6
7
8
9
10
11
12
13
14

<html xmlns="http://www.w3.org/1999/xhtml">
 <head>
 <title>Exemple XSLT avec Silverlight</title>
 <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
 <script type="text/javascript" src="Silverlight.js"></script>
 </head>
 <body>
 <asp :Xml ID="XHTML" runat="server" DocumentSource="monApplicationSilverlight.xaml" TransformSource="transform.xslt" EnableViewState="False"/>
 <script type="text/javascript">
   var auteur = document.getElementById("auteur");
   Silverlight.createObject("monApplicationSilverlight.xaml", auteur, "objectId", {width:'800', height:'400', minRuntimeVersion:'2.0'});
 </script>
 </body>
</html>

1
2
3
4
5
6
7
8

<canvas xmlns="http://schemas.microsoft.com/client/2007" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
 <textblock x:Name="auteur" Text="OCTO" Foreground="Blue" FontFamily="Arial" Canvas.Top="50" Canvas.Left="50">
  <linebreak />
  <run Text="Gestion des Identités"/>
  <linebreak />
  <run Text="Une Politique pour le Système d'Information"/>
 </textblock>
</canvas>

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

<xsl :stylesheet version="1.0" xmlns:sl="http://schemas.microsoft.com/client/2007" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" exclude-result-prefixes="sl">
<xsl :output omit-xml-declaration="yes" indent="yes"/>
 </xsl><xsl :template match="/">
  <xsl :apply-templates select="*"/>
 </xsl>
 <xsl :template match="sl:Canvas">
   <xsl :apply-templates select="*"/>
 </xsl>
 <xsl :template match="sl:TextBlock">
  <div id="auteur">
   <h1><xsl :value-of select="@Text"/><xsl :value-of select="text()"/></h1>
   <ul>
    <xsl :apply-templates select="*"/>
   </ul>
  </div>
 </xsl>
 <xsl :template match="sl:Run">
  <li><xsl :value-of select="@Text"/><xsl :value-of select="text()"/></li>
 </xsl>

A l’exécution de notre page ASP.NET, la transformation du contenu de notre application Silverlight représenté par le fichier XAML sera réalisée par le fichier XSLT. Ce qui nous donnera le résultat suivant.

1
2
3
4
5
6
7

<div id="auteur">
 <h1>OCTO</h1>
 <ul>
  <li>Gestion des Identités</li>
  <li>Une Politique pour le Système d'Information</li>
 </ul>
</div>

Serons nous toujours obligé de faire tout ça pour référencer nos applications RIA ?

Rien n’est sur pour l’instant mais les acteurs majeurs veulent améliorer la situation. Le 1er juillet 2008, Google, Yahoo et Adobe ont annoncé qu’ils collaboraient ensemble pour améliorer le référencement des fichiers SWF. L’ouverture de la spécification du format SWF est un pas dans cette direction. Dans l’avenir, Google, qui ne référence que les textes statiques et les liens hypertextes, souhaite pouvoir référencer les contenus dynamiques des SWF, référencer les images, comprendre le deep linking, agir sur les boutons des formulaires, etc. Nul doute que les algorithmes de référencement des applications Flex vont suivre le chemin parcouru par les sites HTML. Des bonnes pratiques d’optimisation pour les moteurs de recherche (SEO) pour les applications RIA naîtront au fil du temps.

Suggestion d'articles :

1. Flex vs Silverlight
2. Quand Spring s’invite dans une application Flex …
3. Une architecture d’application Flex maintenable

Lorsqu’on regarde une application « grand public », on note au moins les besoins suivants : rien de génial la dedans, interagir avec des données, de consulter et de naviguer dans du contenu mise en forme. A côté de ces besoins, on recherche souvent « THE » solution, celle qui va résoudre tous nos problèmes, celle qui va répondre à tous nos besoins. Reste que si une telle technologie existait, on l’aurait déjà trouvée. Un peu comme les alchimistes qui recherche à transformer le plomb en or…

J’ai cette impression que ces applications devront – au moins à moyen terme – mixer les technologies. Flex est adapté pour réaliser des interactions utilisateurs trés riches, trés visuelles : slider, drag&drop, transitions visuelles et autres effets visuels… . A l’inverse, HTML reste la technologie la plus adaptée pour gérer du contenu mis en forme, pour assurer la navigabilité dans ce contenu. Dès lors, comment faire communiquer ces deux mondes : Flex et HTML.

Adobe répond à cette question et propose l’ExternalInterface. Cette classe permet d’exécuter des méthodes JavaScript depuis Flex ou des méthodes Flex depuis JavaScript et bien entendu de passer des arguments; des données d’un monde à l’autre.

Communiquer entre les deux mondes…

Pour interagir avec JavaScript et HTML depuis une application Flex, l’objet ExternalInterface propose une méthode call() qui permet de préciser le nom de la méhtode JavaScript a appeler ainsi que les paramètres qui seront transmis. Au niveau HTML, on définit cette fameuse méthode JavaScript point d’entrée dans le monde HTML

1
2
3
4
5
6

<script>
function setSelectedItem(obj)
{	
	//do what you wanna do
}
</script>

Au niveau du code Flex

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

<mx :Application....
<mx:Script>	
	< ![CDATA[
		import mx.controls.Alert;
 
		private function clickHandle(e:Event) : void {
			//appel de méthode JS
			if (ExternalInterface.available)
			{
				ExternalInterface.call("setSelectedItem", selItem.text);
			}
		}	
 
		<mx:VBox>
			<mx :TextInput id="selItem"/>
			<mx :Button click="clickHandle(event)"/>
		</mx>

La méthode setSelectedItem définie dans le JavaScript sera exécutée sur l’évènement « click » depuis l’application Flex…

Passer du monde JavaScript au monde Flex n’est guère plus complexe. Au niveau du code HTML tout d’abord où l’on note :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

function getMyApp(appName) {
        if (navigator.appName.indexOf ("Microsoft") !=-1) {
            return window[appName];
        } else {
            return document[appName];
        }
    }
 
function callFlexMethod() {
	var param = "blabla;
	var param2 = 12;
        getMyApp("myApp").myFlexFunction(param, param2);
    }
 
 <div id="fromJS">
 	<button onclick="callFlexMethod();">click !!</button> 
 </div>

Au niveau du code Flex enfin, on note l’utilisation de la méthode addCallback(). Cette méthode permet d’enregistrer les méthodes exposées par l’application Flex et donc accessible depuis le JS de la page HTML.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

<mx :Application ... creationComplete="initApp()">
	</mx><mx :Script>	
	public function initApp():void {
        	ExternalInterface.addCallback("myFlexFunction",myFunc);
     }  
 
     public function myFunc(s:String, i:uint):void
     {
     	try
     	{
		if(i>0)
	     		selItem.text = s;
...
     	} catch (e:Error) {
		//gestion des erreurs
     	}
     }
		]]>
	</mx>
			<mx :VBox>
				<mx :TextInput id="selItem"/>
...
			</mx>

Et le Flex Ajax Bridge?

Un des inconvénients que l’on peut voir à l'ExternalInterface reste le caractère manuel de la tâche. Manuelle sur au moins deux points :

Alors Adobe propose un bridge (concrètement un fichier js qu’il est possible de générer depuis Flex Builder) permettant de plus facilement faire interagir les deux mondes. Imaginez le composant graphique suivant dans votre application Flex:

1
2
3
4

<fab :FABridge xmlns:fab="bridge.*" />
...
<mx :TextInput id="selItem"/>
...

En fait, ce bridge permet de manipuler des objets ActionScript depuis le monde JavaScript, sans aucun ajout de code. Bref, d’utiliser l’ensemble des APIs fournies par ActionScript depuis JavaScript.

1
2
3
4
5
6
7
8
9
10
11

...
<script>
function doIt()
{
 	var flexApp = FABridge.flash.root();
	var flexObj = flexApp.getSelItem();
	...
	alert(value.getTextWidth() + '  ' + value.getText());
}
</script>
...

Remarque : les méthodes getTextWidth() et getText() sont « celles » définies sur l’API ActionScript de TextInput

Faire communiquer le monde HTML/Javascript et le monde Flex est donc plutôt simple. L’ExternalInterface propose certes une solution assez manuelle mais présente peut-être l’avantage de bien définir les « ponts » entre les deux mondes. A contrario, le « Flex Ajax Bridge » permet à JavaScript d’accéder à l’ensemble des APIs ActionScript. Un bridge trés ouvert qui enrichi drastiquement JavaScript mais qui couple fortement les deux mondes, les deux IHMs.

Suggestion d'articles :

1. Référencer les applications RIA Flex et Silverlight
2. OpenESB/Sun Java CAPS 6, quel avenir?

L’agrégation d’IHM ! ou nouveau buzz, les mashups ! Bref, ce besoin d’agréger dans le navigateur des informations provenant de sites multiples peut se trouver freiné par une règle de sécurité séculaire (enfin depuis Netscape 2.0…) : la Same Origine Policy.

La Same Origin Policy a pris naissance avec Netscape 2.0 et vise à empêcher l’accès – en lecture ou en écriture – à des serveurs dont le nom de domaine est différent de celui dont provient le document, la page en cours…Derrière cette limitation, se cache l’idée de confiance et la volonté d’empêcher un document d’un domaine A de voir son intégrité modifiée par un document d’un domaine B.

La Same Origin Policy induit donc la notion de domaine, et donc que deux domaines seront identiques à la condition qu’ils aient le même protocole (http, https…), le même  » host  » et le même port.

Il y a cependant quelques passe-droits à cette  » policy  » que sont les iframe et l’accès à des ressources de type JavaScript. Autrement dit, il est tout à fait possible depuis une ressource d’un domaine www.myhost.com:80 de référencer une ressource JavaScript du domaine www.myhost.com:7777. Comme illustrer sur le schéma suivant, la ressource file.js peut être référencée et utilisée. En revanche, il est impossible de faire d’accéder à cette ressource depuis un objet de type XmlHttpRequest.

C’est même sur ce principe que reposent certaines optimisations de distribution des ressources. Un nom de domaine pour les images, un nom de domaines pour les css…

« Same Origin Policy » et Flex

Flex propose sa solution pour contourner la Same Origin Policy : un fichier domain.xml qui permet de définir quels sont les domaines autorisés à requêter le domaine ayant le fichier en question…Compliqué ? pas tant que ça.

Imaginons deux domaines : www.company.com qui servirait le fichier swf et services.company.com qui proposerait une API quelconque, là n’est pas le débat.
Par défaut, les requêtes émises depuis le client (donc la ressource swf associée au domaine www.company.com) ne sont pas autorisées à requêter le domaine services.company.com.

Considérons maintenant l’exemple de fichier domain.xml suivant :

1
2
3
4
5
6

 
< ?xml version="1.0"?>
   < !DOCTYPE cross-domain-policy SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">
   <cross -domain-policy>
      <allow -access-from domain="*.company.com" />
   </cross>

Ce fichier, une fois déposé sur le serveur au domaine services.company.com autorise les requêtes de toutes ressources provenant des domaines de type *.company.com et a fortiori www.company.com.

Autrement dit, ce fameux fichier doit être mis à disposition sur les serveurs pouvant être accédés par d’autres domaines et non pas l’inverse.

Same Origin Policy et JavaScript

En technologie JavaScript, rien n’est nativement prévu et il est de prime abord impossible de faire une requête http vers un domaine, un host différent du document en cours. Le lecteur averti (je l’adore celle là ) aura remarqué l’utilisation de  » prime abord « .

Néanmoins et comme présenté plus haut, la  » Same Origin Policy  » n’empêche absolument pas de référencer des urls de domaines différents dans une balise

script. Et c’est là que ca devient génial !Prenez le code suivant (attention aux espaces superflus) :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

 
<html>
    <head>
        <script src="lib/prototype/prototype.js" type="text/javascript">
        </script>
    </head>
    <body>
        <h3>Same Origin Policy Sample</h3>
        <script> //balise script #1
            function processIt(data){
                for (var i = 0; i < data.responseData.results.length; i++) {
                    document.write(data.responseData.results[i].title);
                    document.write(data.responseData.results[i].visibleUrl);
                    document.write("<br/>");
                }
            }
        </script>
        <script src="http://ajax.googleapis.com/ajax/services/search/web?v=1.0&q=Octo%20Technology&callback=processIt"> //balise script #2
        </script>
    </body>
</html>

La première balise script parse le résultat d’un objet  » data  » qui est un tableau. La seconde balise script référence une url google qui dans un navigateur retourne :

1

processIt({"responseData":   {"results":[{"GsearchResultClass":"GwebSearch","unescapedUrl":"http://www.octo.com/","url":"http://www.octo.com/","visibleUrl":"www.octo.com","cacheUrl":"http://www.google.com/search?  q\u003dcache:8jNCWXNMhgEJ:www.octo.com","title":"\u003cb\u003eOCTO Technology\u003c/b\u003e - Cabinet  d\u0026#39;architectes en Systèmes d\u0026#39;Information","………

Le truc intéressant avec les données retournées, c’est leur format : une méthode processIt – qui prend le nom définit dans le paramètre callback de l’url – qui prend en paramètre un tableau complexe au format JSON.

A l’exécution, le navigateur interprète la seconde balise script et récupère la ressource référencée dans l’attribut src, ie. le flux proposant une méthode avec en paramètre un tableau de valeurs. Ainsi la seconde balise script devient un simple appel à la méthode processResult, elle-même définie dans le document associé au domain  » 127.0.0.1 « , avec des paramètres particuliers…

Au final, la page suivante s’affiche (vous aurez noté le haut travail de design ) :

L’autre point intéressant est les requêtes envoyées par le navigateur.

On note bien que le chargement du document depuis le domain  » 127.0.0.1  » réalise un GET sur une ressource du domaine ajax.google.com.

Pour conclure…

Contourner la  » same origin policy  » est donc possible de façon assez simple et permet d’adresser une partie des problématiques de mashup. L’exemple précédent, bien que simpliste, permet sans problème d’imaginer de modifier dynamiquement – ie via JavaScript – la seconde balise script – ie. le DOM – et notamment la valeur de l’attribut src. Il serait ainsi possible de réagir à d’autres interactions d’un utilisateur, ailleurs dans le document…

Reste néanmoins à savoir si le contournement de cette policy est la meilleure idée que vous ayez eu jusqu’à présent car comme dans toute zone de confiance, il vous faudra être certain de la qualité des flux JSON échangés…