Publié par

Il y a 9 ans -

Temps de lecture 7 minutes

Flash Catalyst, Flash Builder l’avis de Xebia ! (suite)

Après avoir réalisé le projet sous Catalyst comme présenté dans le précédent billet, nous voici prêt à passer aux choses sérieuses : le développement de l’application.

Récupération du projet Flash Catalyst

Commençons donc par récupérer ce que notre designer a réalisé. Ce dernier nous génère grâce à Flash Catalyst un fichier fxp. Pour le récupérer dans Flash Builder, il suffit d’aller dans Fichier > Importer un projet Flex (FXP) et de sélectionner le fichier à importer.

Une fois cette importation terminée, le projet apparaît comme un projet Flex classique dans Flash Builder. Il contient la librairie de Flash Catalyst. Le projet compile et s’exécute à merveille. Inspectons maintenant le code généré par Flash Catalyst.

La partie design de Flash Builder

Ouvrons l’application principale, c’est-à-dire le Main.mxml dans Flash Builder et intéressons nous à la partie Design (Conception si vous avez comme moi la version française) :

Dans cette vue il est maintenant possible de visualiser les différents états possibles d’un composant.

La librairie Spark de Flex 4

Observons ensuite le composant bouton Button1, le code généré donne ceci :



  [HostComponent("spark.components.Button")]
  
    
    
    
    
  
  
  
  
  
    
      
        
          
        
      
    
  

Ce composant utilise Flex 4 et notamment la nouvelle librairie spark qui permet de réaliser des composants plus «customisables». C’est grâce à cette librairie que l’on peut faire collaborer designer et développeur. Comme vous pouvez le voir ici, le code MXML est vraiment différent de ce que l’on a pu voir jusqu’à maintenant avec Flex 3.
On peut retrouver toutes les informations données dans Catalyst telles que :

  • le fait que le composant soit un bouton <fx:Metadata>HostComponent("spark.components.Button")</fx:Metadata>,
  • les différents états des boutons (up, down, over, disabled),
  • et l’apparence du bouton en lui même.

Pour plus d’informations, vous pouvez consulter cet article sur les nouveautés de Flex 4.

Intégration au backend Java

L’introspection des services avec Flash Builder

Passons maintenant à l’intégration avec un backend Java: nous allons pour cela utiliser Flash Builder 4. Une des grandes nouveautés de cet IDE est la possibilité de réaliser l’introspection des différents services exposés côté Serveur. Il peut s’agir de services Java avec LCDS (LiveCycle Data Service ES) ou BlazeDS, ou encore de services PHP avec AmfPHP par exemple.

Le service sur lequel nous allons travailler côté Java est un simple war contenant un POJO TravelService renvoyant une liste fixe d’objets Travel.

Nous allons utiliser la fonctionnalité d’introspection que fournit Flash Builder 4. Pour ce faire, commençons par configurer le web.xml pour le développement en ajoutant la servlet permettant de réaliser l’introspection des classes Java par Flash Builder. Pour réaliser cette configuration, je me suis basée sur cet article qui fournit toutes les librairies nécessaires.

        RDSDispatchServlet
    RDSDispatchServlet
        flex.rds.server.servlet.FrontEndServlet
        
      messageBrokerId
      _messageBroker
    
    
      useAppserverSecurity
      false
    
        10
    

    
        RDSDispatchServlet
        /CFIDE/main/ide.cfm
    

Cela permettra à Flash Builder de réaliser l’introspection des classes côté Java. La propriété useAppserverSecurity est à false durant la période de développement pour faciliter l’accès aux données.

Pour l’exposition des services, nous utilisons Spring BlazeDS configuré par annotation de la façon suivante.

@Service("travelService")
@RemotingDestination(channels={"my-amf"})
public class TravelService {

Le channel est défini de façon classique dans un fichier de configuration services-config.xml dont voici un extrait :
Définition du channel :

            
        

Configuration du channel par défaut :


  
             
     

Lançons maintenant notre serveur Tomcat côté Java pour y déployer notre war.

Côté Flash Builder, faites un clic droit sur votre projet puis sélectionnez Propriétés > Serveur Flex. Donnez le type de serveurs d’application J2EE et sélectionnez BlazeDS.

Le dossier de sortie permet à Flash Builder de pouvoir déployer l’application Flex sur le serveur d’application.

Après avoir validé la configuration, nous allons maintenant pouvoir visualiser les services disponibles pour cette application.

Allez dans le menu Données > Connexion à BlazeDS. Une authentification est demandée mais pour notre application aucun mot de passe n’est nécessaire. Sélectionnez donc « Aucun mot de passe requis », puis Ok.

Une fois validé, vous pourrez visualiser les services disponibles côté Java exposés par BlazeDS :

A ce stade vous pouvez sélectionner le service et l’associer à votre projet.

Tester son service avec Flash Builder

En cliquant droit sur votre service, vous pouvez réaliser des opérations de test. Le test permet d’afficher les valeurs de retour de vos méthodes. Par exemple pour la méthode loadAll proposée par TravelService, nous pouvons voir les valeurs que retourne notre service.

Associer le service à l’IHM

Le but étant de montrer ce que Flash Builder est capable de faire, nous allons utiliser tout ce qu’il nous propose en évitant le plus possible de coder.

Commençons par aller dans la vue design du Main.mxml, dans l’état voyages, sélectionnez la liste contenant les éléments San Francisco, cliquez droit sur le composant et sélectionnez Lier aux données.

Flash Builder propose les services précédemment configurés pour notre projet. Sélectionnez le champs de liaison aux données (dans notre cas destination) puis validez. Flash Builder va supprimer la liste de San Francisco pour la remplacer par le service sélectionné.
Maintenant en allant sur http://localhost:8080/FlexProjectXke/, nous pouvons voir notre liste. Mais n’étant pas correctement configurée, les éléments apparaissent ainsi object Travel. Nous allons donc faire quelques réajustements pour que l’affichage se fasse correctement.

A vrai dire, la définition de la destination ne fonctionne pas ici car la liste n’utilise pas le labelField mais fait appel à des composants « custom ».
Mais où doit être effectuée cette modification ? Commençons par repérer où se trouve la liste des données dans le Main.mxml :

    
    
    
    
    
  

La liste fait appel au composant DataList1, regardons ce qu’il contient :

    
      
    
  

L’itemRenderer RepeatedItem1 dans DataGroup fournit le rendu de chaque élément affiché dans la liste. C’est exactement à lui que l’on va s’intéresser pour personnaliser l’affichage des données.

  
    
    
    
  
  
  
  

Maintenant ajoutons l’image dans le Main.mxml, pour qu’elle soit affichée lorsqu’on sélectionne un pays.


Et voilà le résultat :

Conclusion

L’intégration dans Flash Builder de la maquette réalisée par Flash Catalyst ne fût pas aussi simple que prévue et il a fallu chercher et modifier un peu le code. Rien de très important certes, mais sur des maquettes plus complexes cela peut devenir plus compliqué. Comment en sommes nous arrivés là ? La création de l’élément répété a été faite par rapport à un texte sur fond d’image (noir si non sélectionné et gris sinon). Le problème est que la liste de données transportait initialement le chemin vers cette image, chose que le designer n’aurait pas dû faire si il s’était concerté avec le développeur. Une très bonne communication est nécessaire entre les deux mondes pour que le développeur ait un projet facilement exploitable et intégrable. A mon avis, le designer doit être sensibilisé à la qualité du code que Flash Catalyst pourrait générer en arrière plan. Sinon, le travail d’intégration au backend risque d’être laborieux.
Un autre inconvénient de Flash Catalyst concerne le code Flex généré: un peu lourd comparé à ce que le développeur aurait pu réaliser lui même, il fournit pas mal d’images pour obtenir le rendu de départ, rendant le code moins compréhensible au premier abord.
Enfin Flash Builder 4 apporte beaucoup d’amélioration au développement d’application. L’auto-complétion y est améliorée. Et la récupération des services via Flash Builder permet d’éviter toute duplication des classes côté Flex, il s’occupe de gérer l’appel des services. Un gros point négatif à rayer de votre liste d’inconvénients vous empêchant de débuter un projet Flex/Java. Un outil à tester sans hésiter !

Publié par

Commentaire

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Nous recrutons

Être un Xebian, c'est faire partie d'un groupe de passionnés ; C'est l'opportunité de travailler et de partager avec des pairs parmi les plus talentueux.