Prendre un Café

Pour les besoins du boulot, j'ai du me mettre à Flex, le framework d'Adobe orienté RIA en Flash.

Je pensais que mon passé de flasheur m'aiderait à monter rapidement en compétence sur cette techno, ben non : c'est tout à fait autre chose que ce que je connaissais de l'IDE traditionnel, dont je m'étais arrêté à la version 8. Avec Flex on a affaire à un framework complet de génération d'interfaces riches basées sur l'emploi de composants décrits et paramétrés en XML et de la dernière mouture du langage ActionScript en version 3. Quelques exemples d'applications réalisées avec Flex sont disponibles, et pour certaines, ça en jette carrément.

Le langage MXML

La description des interfaces s'opère au moyen du langage MXML^[1], basé sur XML un peu comme ce que proposent XUL ou XAML ou même XHTML (qui reste une implémentation particulière et standardisée d'XML). Deux types principaux de composants sont disponibles : les conteneurs (boîtes, panneaux, fenêtres, etc.) et les éléments de contrôle (champs texte, listes, datagrids, tree, etc.)

Le nombre de conteneurs et de contrôles est impressionnant, on se prend à rêver de la même richesse en HTML ^[2]. La plupart des composants sont visibles sur l'explorateur de composants Flex, sur le site d'Adobe. Et le meilleur reste sans doute à venir quand on voit le catalogue de composants supplémentaires open source comme ceux du projet FlexLib...

Le format généré après compilation d'un ensemble de fichiers MXML constituant une application Flex est le SWF, le format natif d'Adobe Flash, lisible par tout bon Flash Player 9 qui se respecte, implanté sur plus de 80% du parc machines desktop mondial d'après les dernières statistiques disponibles sur le site d'Adobe.

Voila un exemple de code MXML décrivant l'interface d'une application simpliste :

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute">
   <mx:Panel title="Dire bonjour" x="10" y="10" layout="absolute" width="303">
      <mx:TextInput id="firstname" x="10" y="10"/>
      <mx:Button label="Dire bonjour" click="result.text='Bonjour, '+firstname.text" x="178" y="10"/>
      <mx:Label id="result" x="10" y="40" width="265"/>
   </mx:Panel>
</mx:Application>

Le code est assez parlant, mais voici quelques éléments significatifs :

• Le conteneur principal de l'application déclare l'espace de noms mx, ce qui nous permettra d'utiliser les composants natifs de Flex
• L'application déclare un conteneur sous la forme d'un Panel contenant trois contrôles :
  • un InputText, champs de saisie textuelle
  • un Button, un bouton d'action
  • un Label, un champs de texte potentiellement dynamique
• Chaque élément peut se voir nanti d'un attribut id qui doit être unique si renseigné ; il permet de référencer facilement un élément de l'arbre DOM
• La gestion des évènements peut se faire directement en MXML : ici, quand on clique sur le bouton, le contenu texte du label est modifié en fonction de la valeur textuelle du champs de saisie.

Style et mise en forme

Dans l'exemple précédent, on voit que les styles sont appliqués sous forme d'attributs XML. C'est une solution pratique à court terme mais qui peut rapidement s'avérer problématique à maintenir dès que votre application grossit. Aussi, pour séparer la couche de présentation de la description des contenus, tout comme en HTML, Flex permet l'utilisation de feuilles de styles CSS embarquées ou externalisées. Beaucoup de propriétés CSS ont du être créées ou adaptées aux spécificités du balisage MXML et des composants proposés, mais le résultat est une grande souplesse d'utilisation et une large palette de mise en forme disponible. Pour preuve, un petit tour du côté de l'explorateur de styles Flex s'impose.

Le langage ActionScript 3

ActionScript 3 est l'évolution logique des précédentes versions, étendant le périmètre fonctionnel et accentuant son caractère professionnel, notamment dans l'implémentation objet, les types natifs et l'organisation en packages des différents objets de programmation.

Composants personnalisés

Une des grandes forces de Flex à mes yeux est la simplicité avec laquelle on peut créer ses propres composants en héritant de composants basiques préexistants et de les manipuler via son propre espace de noms. Par exemple, la création d'un composant dérivé d'un formulaire présentant un champs de login/mot de passe donne à peu près ceci :

<?xml version="1.0" encoding="utf-8"?>
<mx:Form xmlns:mx="http://www.adobe.com/2006/mxml" width="280" height="105">
   <mx:FormItem label="Login">
      <mx:TextInput id="username"/>
   </mx:FormItem>
   <mx:FormItem label="Mot de passe">
      <mx:TextInput id="password" displayAsPassword="true"/>
   </mx:FormItem>
   <mx:FormItem>
      <mx:Button label="Connexion"/>
   </mx:FormItem>
</mx:Form>

Si on nomme notre fichier de composant LoginForm.mxml et qu'on le stocke dans le répertoire ./components de notre projet Flex, on va pouvoir l'utiliser de la façon suivante dans une application :

<?xml version="1.0" encoding="utf-8"?>
<mx:Application 
   xmlns:mx="http://www.adobe.com/2006/mxml" 
   xmlns:niko="components.*"
   layout="absolute">
   <mx:Panel title="Connexion">
      <niko:LoginForm id="loginform"/>
   </mx:Panel>
</mx:Application>

On a déclaré un nouvel espace de noms, ici niko (mais on aurait pu mettre ce qu'on veut) pointant vers les fichiers sous le répertoire components du projet. Simple, non ? En tout cas, cela devient un jeu d'enfant de produire des composants réutilisables.

Le nerf de la guerre, l'accès aux données distantes

Flex propose trois modes d'accès aux données distantes, par le biais de trois composants :

• L'objet HTTPService, comme son nom l'indique, permet d'effectuer des requêtes HTTP sur une url et d'en récupérer la réponse. Un objet bien pratique quand on veut s'interfacer avec une architecture REST, par exemple.
• L'objet WebService permet de s'interfacer avec un webservice au format WSDL via SOAP. Quand on dispose de tels service, c'est un plaisir de se baser dessus depuis Flex puisqu'on a qu'à réferencer les méthodes à utiliser et les déclencher depuis leur référence.
• Mais l'objet de loin le plus intéressant à mes yeux est RemoteObject, implémentation du protocole RPC dans Flex, pendant Flash/ActionScript du RMI en Java. Comme je fais peu de Java, j'ai tendance à plutôt utiliser AMFPHP^[3] pour publier mes services en utilisant PHP. Un très bon tuto de mise en oeuvre du couple AMFPHP/Flex se chargera d'illustrer le concept plus efficacement que je ne le fais ici.

FlexBuilder

Adobe propose un IDE dédié à la réalisation d'applications Flex, FlexBuilder. Cet outil, basé sur le célebrissime Eclipse, permet de disposer d'un environnement complet de développement comprenant entre autres un éditeur de code (MXML en mode source/wysiwyg, ActionScript, CSS, etc.), un débogueur avancé à la Java, un gestionnaire de projets, la compilation automatique et surtout un accès à l'immense catalogue des plugins Eclipse. D'ailleurs, FlexBuilder est également disponible sous la forme d'un plugin à installer sur une instance d'Eclipse existante : de quoi travailler sur vos projets Flex/PHP de façon centralisée, par exemple.

Inconvénient majeur de cet outil, il est payant. Et coûte relativement cher, puisque proposé aux alentours de 500€. Néanmoins, le SDK de Flex étant gratuit, vous pouvez tout à fait vous passer de FlexBuilder et compiler vos applications à la main. Une bonne nouvelle ne venant jamais seule, Adobe a décidé de publier la prochaine mouture du framework sous licence libre ^[4], aussi nous devrions voir fleurir des alternatives à FlexBuilder et assister à un taux d'adoption plus conséquent de la technologie.

Organisation du code, frameworks

Au vu de l'étendue fonctionnelle de Flex et des différents formats de fichiers mis en oeuvre ainsi que de leurs interactions potentielles, il est clair que maintenir la moindre petite application peut vite relever du cauchemar les développements avançant. Pour faire face à cette problématique, Adobe propose un surframework du nom de Cairngorm mettant en oeuvre les bonnes pratiques d'architecture logicielle en implémentant le motif de conception MVC bien connu des utilisateurs de frameworks de développement rapide orientés web.

Même si le projet semble extrêmement intéressant, je n'ai pas encore pour l'heure pu jouer avec.

Conclusion

Pour l'heure et après avoir pas mal galéré tâtonné avec l'outil au début, je dois reconnaître maintenant et avec un peu de recul que c'est assez efficace. C'est relativement déstabilisant pour quelqu'un qui comme moi avait l'habitude de l'IDE Flash Authoring classique, mais au final FlexBuilder semble beaucoup plus sérieux pour tout ce qui concerne la programmation et l'organisation des fichiers (Eclipse oblige.) Même le templating y gagne à mon sens, mais par contre impossible de faire de la création graphique avancée directement dans FlexBuilder, l'outil n'est clairement pas l'ami des infographistes de vocation.

Pour enfoncer le clou, j'ai pu comparer l'utilisation de Flex et de XUL, ayant enchaîné deux projets coup sur coup les mettant en oeuvre. L'excellente documentation de Flex et la richesse des outils gravitant autour de la techno font que pour l'heure Flex me semble l'un des meilleurs choix pour développer une RIA, si l'on écarte le couple HTML/Ajax qui garde une toujours une place de choix dans mon arsenal webdeuzéroesque

Je relaie ici cette chouette initiative d'un groupement de projets open source pour inciter à l'adoption et au déploiement de php5 en lieu et place de l'antique et moins performant php4 : Go PHP 5 !

Php4 nous a rendu de fiers services, mais il est plus que temps de reconnaître que cette version est maintenant largement dépassée et que le maintien de son utilisation ne sert pas l'essor du langage sur des projets de grande envergure... d'autant que la fin du support officiel de php4 est annoncée pour cette année.

Le pire c'est que php6 et ses alléchantes petites révolutions vont arriver l'année prochaine, je sens qu'on est pas sorti de l'auberge :/

Edit : La mort de php4 officiellement annoncée sur php.net. Le vendredi 13 lui a porté malchance ^^

Dans un précédent billet, nous avons vu comment créer un weblog basique avec l'admin-generator de Symfony. Nous allons reprendre là où nous en étions et ajouter la liste des commentaires à notre back-office de gestion des billets grâce à un simple appel de composant, qui n'est autre qu'un template partiel associé à un contrôleur dédié.

Création du module de gestion des commentaires en back-office

Si ce n'est déjà fait, on crée notre module de gestion des commentaires

# symfony propel-init-admin back comments Comment

Création du composant qui va lister les commentaires d'un billet

Bien. On va maintenant créer un composant postcomments qui affichera la liste des commentaires associés à un objet Post, en créant un nouveau fichier apps/back/modules/posts/actions/components.class.php et en y insérent le contenu ci-dessous :

<?php
class postsComponents extends sfComponents 
{
  
  /**
   * List comments for a given Post
   * 
   */
  public function executePostcomments()
  {
    $post_id = $this->getRequestParameter('id');
    if (!is_null($post_id))
    {
      $c = new Criteria();
      $c->add(CommentPeer::POST_ID, $post_id);
      $c->addDescendingOrderByColumn(CommentPeer::CREATED_AT);
      $this->comments = CommentPeer::doSelect($c);
    }
  }
  
}

On crée maintenant le template partiel associé au contrôleur, dans le fichier apps/back/modules/posts/templates/_postcomments.php :

<?php if (isset($comments)): ?>
  <?php if (count($comments) > 0): ?>
    <?php use_helper('Comment', 'Text') ?>
    <dl>
    <?php foreach ($comments as $comment): ?>
      <dt>
        <?php echo sprintf('Posté le <strong>%s</strong> par <strong>%s</strong> :', 
                           format_date($comment->getCreatedAt(), 'd/MM/yyyy à H:m'),
                           format_comment_author($comment->getAuthor(),
                                                 $comment->getSite())) ?>
      </dt>
      <dd>
        <?php echo simple_format_text($comment->getContent()) ?>
      </dd>
      <dd>
        [<?php echo link_to('Éditer', 'comments/edit?id='.$comment->getId()) ?>]
        [<?php echo link_to('Supprimer', 
                            'comments/delete?id='.$comment->getId(),
                            'confirm=Êtes-vous sûr ?') ?>]
      </dd>
    <?php endforeach; ?>
    </dl>
  <?php else: ?>
    <p>No comment yet.</p>
  <?php endif; ?>
<?php endif; ?>

Utilisation d'un helper pour des tâches courantes de templating

La fonction format_comment_author est un helper maison, que nous définissons dans un nouveau fichier lib/helper/CommentHelper.php :

<?php
/**
 * Returns a formatted html string for author including website link if any
 * 
 * @param  string   $name
 * @param  string   $site
 * @param  boolean  $nofollow
 * @return string 
 */
function format_comment_author($name, $site=null, $nofollow=true)
{
  if (!is_null($site) && preg_match('/^http/i', $site))
  {
    return sprintf('<a href="%s"%s>%s</a>', 
                   $site, 
                   $nofollow === true ? ' rel="nofollow"' : '',
                   $name);
  }
  else
  {
    return $name;
  }
}

Mise à jour du back-office de gestion des billets

Ceci fait, modifions le fichier de configuration du back-office d'administration des billets créé précemment et situé dans le fichier apps/back/modules/posts/config/generator.yml, afin d'appeller notre nouveau composant postcomments pour la vue d'édition d'un billet :

  [...]

    # Customisation du formulaire d'ajout/édition
    edit:
      
      [...]

      # Affichage d'une sélection de champs
      display:         [author_id, title, excerpt, body, post_sections, ~postcomments]

Vous noterez le caractère ~ précedant le nom du composant : encore une convention Symfony qui nous simplifie la vie

Gestion de l'échappement

Vous avez tous déjà entendu parler des failles XSS ? Pour nous en prémunir partiellement, nous allons activer l'échappement automatique des contenus passés à une vue, en ajoutant ces directives dans le fichier apps/back/config/settings.yml :

all:
  .settings:
    escaping_strategy: both
    escaping_method:   ESC_ENTITIES

Ainsi, dans notre cas toutes les chaînes seront échappées en entités HTML pour plus de sécurité. Pour plus d'information, rendez-vous dans la section dédiée de la documentation officielle.

Au final, voici ce que ça donne quand on édite un billet :

Champs virtuels

Notre liste de billets, pour l'instant, ne nous informe pas pour chacun le nombre de commentaires associés. On va y remédier simplement en créant un getter ad-hoc dans notre objet de donnée Post et en appellant le champs virtuel associé. Dans le fichier lib/model/Post.php, on rajoute la méthode suivante :

public function getCommentsNumber()
  {
    return $this->countComments();
  }

Et dans le fichier apps/back/modules/posts/config/generator.yml, on affiche le champs virtuel comments_number dans la vue en liste :

  [...]

    # Customisation des colones de la vue en liste
    list:
      display:         [=title, excerpt, Author, comments_number, created_at, updated_at]

Voici ce que ça donne :

En conclusion

Voila, notre application prend forme doucement. On pourrait passez des heures à ajouter des détails par-ci par-là, mais je vous laisse le faire en compagnie de la documentation