Accueil > Java EE > A la découverte d’Angular JS

A la découverte d’Angular JS

Cet article est le premier d’une série, proposée par Henri Darmet, qui a été amené à évaluer le framework Javascript phare de Google : Angular JS. Vu la notoriété de l’outil et l’engouement qu’il suscite (et que suscitent les frameworks Javascript, en général), il s’est dit qu’il était opportun de partager cette expérience.

La vocation de cette série d’articles est double :

  • Offrir un tutorial « réaliste » (permettant de construire une application dans la « vraie vie »)
  • Réfléchir sur les qualités et les défauts de cet outil, pour pouvoir en estimer l’intérêt

Pour démarrer, le site d’Angular JS (http://angularjs.org/) offre un bon tutoriel : il montre comment construire une petite application catalogue, présentant des téléphones mobiles. Le sujet servira donc de base pour ces articles. Mention spéciale à Google : ils ont un vrai savoir-faire dans la rédaction de documentation utile. C’est clair, concis et efficace. On rentre vite dans le sujet, et si on ne comprend pas toujours tout au premier abord, on n’est jamais, non plus, complètement perdu.

Qu’apprend-on ? Qu’Angular est un framework Javascript permettant d’animer des pages Web (comprenez : ce n’est pas une bibliothèque de somptueux composants (comme Sencha), les composants devront être rajoutés) et que ce framework repose sur cinq principes architecturaux hyper connus :

  • le MVC (Modèle Model-View-Controller)
  • l’injection de dépendance
  • le « templating » (faculté de définir sa vue de façon déclarative, c’est-à-dire une page HTML)
  • le « binding »  (faculté de lier un champ d’un objet Javascript avec un item graphique du template pour que toute mise à jour soit simultanée)
  • l’usage de composants et la possibilité d’en créer de nouveaux

Premier coup de griffe : « hyper connus » implique « pas hyper innovants ». Tous ces principes existent depuis des années, voire des dizaines d’années, dans d’autres outils comme Flex, Java FX, JSF+ Spring/Seam, GWT, …  L’implémentation de ces concepts dans Angular est originale (et parfois déroutante) mais pas particulièrement novatrice. Les applications que vous écrirez avec Angular JS ressembleront furieusement aux anciennes.

Les concepteurs d’Angular sont d’ailleurs honnêtes sur ce sujet : Angular est un framework permettant de faire de l’édition de données dans un environnement HTML 5. Il y est d’abord question de manipuler des champs, des boutons, des grilles, etc. Si vous cherchez à faire World Of Warcraft en Javascript, vous n’avez pas tapé à la bonne porte ! Plus sérieusement, Angular sera adapté pour les applications de gestion (et là, il va puissamment vous aider), mais ne l’est pas (c’est-à-dire qu’il risque de vous gêner) si vous voulez réaliser un outil très « drag-and-drop » (type Balsamiq Mockups). Ce n’est donc pas un outil « universel » (comme l’est GWT par exemple, plus puissant, mais plus complexe), et il n’est d’ailleus pas vendu ainsi.

La meilleure définition que l’on peut donner d’Angular JS est peut-être la suivante : c’est un « Spring (+Spring MVC) côté client HTML 5 » : on y définit des composants, on les assemble par injection de dépendance puis on les lie au reste du monde (par REST justement). Dans ce rôle, il est très pertinent.

Un petit mot sur la nature « MVC » d’Angular : c’est à peu près faux et heureusement ! Car le vénérable MVC à la mode STRUTS est mort en 2007-2009 de ses limites, et vouloir le ressusciter confinerait à l’acharnement thérapeutique. Le modèle « new style », c’est le « MVP » (model-view-presenter). J’en rappelle les nuances :

  • En « MVC », on traite une interaction utilisateur en deux phases : d’abord le controller traite la requête reçue (validation, exécution de la commande associée) PUIS la View génère une réponse
  • En « MVP », on accroche à la View un jeu de réflexes portés par le Presenter (qui peut donc en posséder des dizaines). Chacun de ces reflexes s’activera sur une action particulière de l’utilisateur. L’interaction, donc, est beaucoup plus atomique.

Clairement, le modèle proposé par Angular est « MVP » (bon point !). Le soi-disant controller d’Angular n’a pas du tout comme objectif de traiter une quelconque requête. Il n’est exécuté qu’une fois, au moment où la page s’installe. C’est en fait un constructeur de « Presenter » (et pas le Presenter lui-même). Le « Presenter », c’est le bien mal nommé objet « Scope », objet central, fondamental, dans la mécanique Angular. Détail amusant : la documentation Angular précise que l’héritage des controller se fait grâce… à l’héritage des scopes !

Donc, vous, amis JSF-iens, GWT-iens, Flex-iens, vous serez beaucoup moins dépaysés que vous, amis Struts-iens.

Parlons un peu d’injection de dépendances. Elle est simple et efficace : chaque fois que l’on écrit un composant (comme un controller qui est une fonction Javascript), il faut définir, dans la liste de ces paramètres, les « beans » dont il va avoir besoin. Le premier d’entre eux est justement l’objet « scope » qu’il va falloir muscler.  Retenons, pour l’instant, qu’Angular propose un vrai mécanisme d’inversion de contrôle, mais que son expression est assez éloignée de celle de Spring. Il faut s’y faire. Une fois qu’on s’y est fait, on ne peut qu’en apprécier la clarté.

Les mécanismes frères de templating et de binding ont été soigneusement mis au point par l’équipe de conception d’Angular. Le résultat est remarquable de puissance, de robustesse et de discrétion. Le développeur n’a pas à polluer son code par des dizaines de lignes absconses pour « installer » la ligature entre le Presenter et la View, une référence « à la JSP » dans la page HTML suffit dans 90% des cas. De ce point de vue, on est très proche d’une philosophie de type JSF (à opposer à une approche Wicket, très complète mais plus lourde).

Parlons un peu de « componentisation » (néologisme très beau et qui fait savant, comme son petit frère « componental »). Angular définit clairement la notion de composants (graphiques ou non) et d’ensemble de composants, appelés « modules ». Les modules jouent le rôle des « packages » Java. Angular définit une notion assez proche de « l’import » via les dépendances entre modules. Un composant sera essentiellement :

  • une association template/controller
  • un service (stub contenant, par exemple, l’appel à un service REST)

La réutilisation de code est donc possible avec Angular. Ceci dit, je n’ai pas (encore ?) trouvé comment assembler simplement (de façon compliquée, j’ai trouvé) des composants graphiques les uns avec les autres au moment de la construction de l’application. Cela permettrait, par exemple, de définir d’une part un composant « Grille et détail » générique muni des fonctions standards d’affichage et de manipulation d’une liste d’objets, et d’autre part deux composants de présentation d’une certaine entité (comme le sempiternel client), le premier le présentant sous la forme d’une ligne, l’autre sous la forme d’un formulaire, et ensuite d’assembler ces trois composants à priori indépendants pour en faire un composant spécialisé dans la présentation de cette entité. C’est vraiment dommage et c’est à mon sens, une grosse limite. Quelqu’un a-t-il des idées ? Sur ce point, GWT et Wicket – pour ne parler que d’eux – me paraissent significativement plus puissants et aboutis. Déception, donc.

Et Javascript dans tout ça ? Javascript est bien là, et même trop là ! Si on vous a vendu qu’Angular vous permettait de vous affranchir des problèmes inhérents à Javascript, on vous a menti. Angular va dans le bon sens, mais la route est trèèèèèèèèèèèèèèèèès longue. Voilà ce qui vous attend :

  • RIEN ne fonctionne si au fin fond d’UN script vous avez oublié de référencer UN bean dans le constructeur d’UN composant. Sans que l’on vous dise, bien sûr, pourquoi plus rien ne marche. Silence radio total.
  • La programmation Angular demande une maîtrise très avancée de la programmation utilisant les lambda expressions (ou closures). Si vous n’êtes pas un Jedi en la matière, sachez que vous avez à peu près 100% de chances d’écrire au moins un réflexe qui mettra TOUTE votre application en carafe si l’utilisateur s’excite en production parce que le serveur ne répond pas assez vite.
  • Vous allez très vite apprendre que sous Chrome, pour vider le cache, le raccourci clavier, c’est Ctrl-Maj-Suppr. Je ne compte plus les heures perdues à tenter de comprendre pourquoi une correction n’a rien apporté, jusqu’au Ctrl-Maj-Suppr libératoire !

Bon, assez médit pour une première fois, dans le prochain article nous verrons comment faire les premiers pas avec Angular.

Categories: Java EE Tags: ,
  1. Jerome
    30/01/2014 à 09:56 | #1

    Voila une série qui commence bien.
    En FR, sans langue de bois, avec des comparaisons de précédents dans le domaine.

    J’ai utilisé angular pour voir.
    La doc était pas terrible car pas dans l’ordre. Heureusement, on trouve pas mal de vidéos et il y a egghead.io

    Au final, j’ai réussi à faire un générateur de code java en angular :)

  2. 01/02/2014 à 14:11 | #2

    Excellent, j’adore l’esprit mordant qui anime cette série !

    Les explications sont très claires, moi qui suis pourtant plutôt hostile au javascript…

    De quoi bien initier ma prochaine revue de web !

    Merci ! o/

  1. 31/01/2014 à 11:00 | #1
  2. 07/02/2014 à 12:16 | #2


9 + = douze