Flex BlazeDS – Intégration BlazeDS / Spring: le livre blanc (PDF)
UniversalMind à publié sur l'un de ses blogs StrikeFish, un livre blanc présentant les Best Practices concernant l'intégration de BlazeDS avec Spring.
Voir l'article original de l'auteur.
Télécharger le livre blanc BlazeDS Best Practices
Ce "white paper" expose certaines une manière d'intégrer Spring avec BlazeDS ainsi que l'installation des deux systèmes. Il n'est pas très complet, à mon avis, mais cela peut vous donner quelques pistes. Il prône l'utilisation de Spring BlazeDS Integration (SBI) couplé avec BlazeDS plutôt que SpringFactory qui devient vieillissant.
Voilà donc quelques bons conseils avant de tutoriaux Adobe Flex plus poussé sur flex-tutorial.fr sur BlazeDS / Spring.
Flex BlazeDS – Spécifier la configuration BlazeDS à l'exécution (services-config.xml et context-root)
Dans le tutorial précédent, on a vu comment spécifier la configuration de BlazeDS à l'application Adobe Flex au moment de la compilation. On va voir dans cet article, comment la spécifier à l'exécution, et les avantages que cela apporte. Cette démarche est aussi valable pour la définition de la configuration LiveCycle pour vos applications Flex / Air.
Cet article est une traduction de l'article de Christophe Coenraets: Externalizing Service Configuration using BlazeDS and LCDS
Vue d'ensemble de la configuration de BlazeDS / LCDS
Lorsque les développeurs commencent à utiliser les RemoteObject, ils vont se demander quand et à partir de quel emplacement est lue la configuration serveur.
Cette question remonte assez vite quand une application cesse de fonctionner et que vous venez de la déplacer de serveur ou tout simplement de la mettre en ligne.
Quand vous créez un nouveau projet BlazeDS ou LCDS dans Flex Builder, vous sélectionnez J2EE comme "Application Server Type". Cela ajoute un argument de compilation pointant vers votre fichier services-config.xml. Si vous jetez un oeil du côté des propriétés de votre projet Flex Builder, vous verrez quelque chose comme:
-services "c:\blazeds\tomcat\webapps\samples\WEB-INF\flex\services-config.xml"
Quand vous compilez votre application, les valeurs requises du services-config.xml sont intégrées au SWF. Pour faire simple, le fichier services-config.xml est lui à la compilation et pas à l'exécution comme on pourrait le penser. Pour rendre les choses plus abstraites, vous pouvez utiliser des tokens comme {server.name}, {server.port} et {context.root} dans le fichier services-config.xml. Cependant, {content.root} sera substitué à la compilation alors que {server.name} et {server.port} sont remplacés à l'exécution en utilisant le nom du serveur et le numéro de port du serveur par lequel le SWF a été chargé (c'est la raison pour laquelle vous ne pouvez pas utiliser ces tokens pour des applications Air).
Heureusement, le framework Flex propose une API ActionScript permettant de configurer vos canaux à l'exécution et d'externaliser complètement votre configuration de service de votre code. En effet, vous ne voulez pas recompilez votre application quand vous la déplacez de serveur. Cela marche de cette manière:
var channelSet:ChannelSet = new ChannelSet();
var channel:AMFChannel = new AMFChannel("my-amf", "http://localhost:8400/lcds-samples/messagebroker/amf");
channelSet.addChannel(channel);
remoteObject.channelSet = channelSet;
Ce n'est cependant toujours pas ce que l'on souhaite car l'URL du endpoint est toujours en dur dans le code de l'application Flex. L'étape suivante est donc de passer cette valeur d'URL à l'exécution. Il y a de très nombreuses manières de passer ces valeurs au SWF à l'exécution comme les flashvars par exemple. Ici, on va lire un fichier de configuration en utilisant un HTTPService au démarrage de l'application. Ce fichier de configuration inclus (entre autres) les informations nécessaires à la création du ChannelSet en ActionScript.
Flex BlazeDS – Spécifier la configuration BlazeDS à la compilation (services-config.xml et context-root)
Dans les tutoriaux d'initiation à BlazeDS Turnkey, on a spécifié la configuration de votre serveur applicatif Tomcat (intégré à BlazeDS Turnkey) au moment de la création du projet. On a ainsi spécifie l'emplacement du fichier services-config.xml de BlazeDS qui contient la définition des canaux de communication entre l'application client et le serveur applicatif. On a aussi précisé le "context-root" qui représente le dossier de votre serveur applicatif contenant votre Web Application. Pour spécifier toute cette partie configuration, il est très simple de le faire au moment de la compilation mais vous pouvez aussi le faire au moment de l'exécution pour pouvoir changer votre configuration à partir d'un fichier XML par exemple.
On va voir ici comment préciser la configuration à la compilation.
Utilisation des tokens dans le fichier services-config.xml
Avant de poursuivre, il faut bien comprendre comment fonctionne le fichier services-config.xml. Ce fichier contient ce que l'on appelle des "tokens". Ces tokens sont des identifiants qui vont être remplacés à l'exécution de l'application par des valeurs correspondant au contexte d'exécution de l'application.
Par exemple, vous pouvez voir des lignes comme:
<endpoint url="https://{server.name}:{server.port}/{context.root}/messagebroker/streamingamf"
/>
Dans l'URL, on voit bien le token {server.name}, entouré par des crochets. Ce token va être remplacé au moment de l'exécution par le nom du serveur. Par exemple, si votre application s'exécute à l'adresse http://www.mondomaine.com/monAppli/monSwf.swf, Flex va automatiquement remplacer {server.name} par www.mondomaine.com. Et de même pour {server.port}.
Le token {context.root} est, lui, remplacé au moment de la compilation.
Note aux utilisateurs d'applications Adobe Air connectés à BlazeDS
Si vous comptez utiliser votre application web BlazeDS depuis une application Adobe Air, vous ne pourrez pas utiliser ces token. En effet, Adobe Air ne pourra pas deviner la valeur de {server.name} car votre application est une application bureautique, qui n'est pas hébergée sur un serveur. Vous devrez donc spécifier l'URL complète de votre service comme par exemple:
<endpoint url="http://your_server_name:8400/samples/messagebroker/streamingamf"
/>
Spécifier le fichier services-config.xml à la compilation
Quand vous compilez votre application Adobe Flex, vous pouvez spécifier l'emplacement du fichier de configuration au compilateur. Le fichier services-config.xml définit les URL des canaux que l'application Adobe Flex utilise pour communiquer avec le serveur BlazeDS. Les URLs des canaux sont compilées dans le SWF final.
Swiz Tutorial Vidéo – Introduction à Swiz en 20 minutes
Les adeptes de flex-tutorial.fr l'ont sûrement remarqué, il n'y a, pour l'instant, aucun article traitant de l'utilisation d'un framework spécifique tel que Cairngorm, Mate, PureMVC, Swiz… Les raisons sont plutôt simples:
- Je ne travaille en environnement professionnel avec aucun framework spécifique (à part Flex bien sûr)
- Aucun des framework ne sort vraiment du lot. Malgré le soutien de Cairngorm par Adobe, celui-ci est sûrement le plus décrié par la communauté Flex, notamment car il est très proche de ce qui a été fait pour Java, en reproduisant les mêmes erreurs
- Il serait très long d'apprendre les spécificités de chaque framework pour pouvoir faire des comparaisons
- La plupart des framework apporte une complexité qui ne me semble pas nécessaire dans la plupart des cas d'utilisation.
Si vous voulez en apprendre plus sur un framework en particulier, vous pouvez vous référrer à leurs sites respectifs. Si vous êtes motivé pour écrire des tutoriaux pour certains de ces framework pour les publier sur flex-tutorial.fr, vous êtes le bienvenu, il vous suffit d'aller sur le lien Publiez Vos Tutos pour en savoir plus.
Pour changer, voici donc un tutorial vidéo réalisé par Joe Rinehart sur son blog firemoss.com:
Swiz in 20 minutes from Joe Rinehart on Vimeo.
Pendant ces quelques 19 minutes de vidéo, Joe Rinehart construit une application de 0, en liaison avec son service ColdFusion. Malgré la simplicité de l'exemple, on peut voir quelques concepts intéressants de Swiz.
Silverlight 4 beta: Ca bouge chez Microsoft
Hasard (ou pas) du calendrier, 2 jours après la sortie de Adobe Air 2 et Flash Player 10.1 beta, Silverlight 4 sort en beta lui aussi.
Voir l'annonce officielle de la sortie de Silverlight 4 en version beta sur le site de Microsoft
Pour ceux qui ne connaissent pas Silverlight (si on est pas développeur, on peut facilement passer à côté), c'est un framework RIA proposé par Microsoft. Celui se place sur le même marché que Flex et Flash Player (Silverlight est lui exécuté sur un player du même nom). C'est le principal concurrent de Flex sur le marché des RIA, étant donné que GWT reste derrière et utilise une "logique" différente (technologie web JavaScript / Ajax générée par du Java) et que JavaFX est une grande blague.
De *très* nombreux sites / blogs font la comparaison des deux technologies de manière plus ou moins objectives entre Flex et Silverlight et le constat est souvent le même et la grande majorité du temps, Flex en sort vainqueur. Il faut quand même noter que Silverlight avait un train de retard par rapport à Flex (1 ou 2 ans) qu'il a tenté de rattraper à tambour battant. La preuve, Silverlight 4 beta sort alors que Flex 4 est lui aussi en beta.
Le but de cet article n'est pas de "tirer sur l'ambulance" (on pourrait en parler pendant des heures) mais plutôt de voir comment évolue la concurrence.
D'après ce que je peux lire sur l'article de Microsoft, Silverlight 4 va apporter de très nombreuses fonctionnalités. Notamment des choses qui nous paraissent assez banal quand on utilise Flash Player, la gestion de l'impression, de la webcam et du microphone (qui n'était pas ou partiellement géré en SL3) ou bien un composant DataGrid avec resize et classement de colonnes. Voici tout de même les points que je trouve intéressants:
- Avoir le même code compilé pour une application web et desktop grâce à CLR (.NET Common Runtime). De son côté, les applications Flex restent dans Flash Player. Quand on veut une application bureautique, il faut se tourner vers Adobe Air. Cette séparation n'est pas complètement stupide selon moi, je me demande vraiment comment cette unification est gérée en elle-même dans le code SL, des if() dans tous les sens ?
- Support du navigateur Google Chrome (et oui)
- Amélioration de leur composant DeepZoom qui est sympa (démo) mais qui, pour un framework applicatif, ne trouve pas vraiment sa place selon moi
- Support du multi-touch et des "gestures". Fonctionnalité qui sera présente dans Flex quand Flash Player 10.1 sera sorti.
- Support des "toats window" pour les applications bureautiques. Les "toasts" sont ces fenêtres qui apparaissent en base à droite de l'écran pour vous indiquer la connexion d'un utilisateur MSN par exemple. Il ne me semble pas que cette fonctionnalité soit présente de base dans Adobe Air. Il y a bien sûr des classes existantes qui permettent de le faire (je l'ai déjà mis en place) mais pas en natif.
- Pour les applications bureautiques vérifiées, la communication avec des applications comme Word, Excel et Outlook
Pour le reste, consultez l'annonce officielle (voir plus haut). On s'aperçoit que Silverlight arrive bientôt à la cheville de Flex avec même certains domaines dans lequel il serait meilleur (la vidéo d'après ce que j'ai compris).
Mes projets (Open Source)
Autres
