Allez on reprend proprement …

Bon, suite à la sortie de wisdom 0.6.1, j’ai décidé de reprendre les choses proprement.

Parce que j’ai réfléchi, et j’ai constaté plusieurs erreurs bêtes :

  • J’avais pensé créer un repository Git, mais il ne m’a finalement servi à rien. C’est idiot.
  • D’accord il n’y a pas de tests avec karma, mais je peux utiliser fluentlenium, non ?

Donc cette fois-ci, je vais essayer de faire les choses proprement, avec un repository git bien taggé, avec des tests d’interface, avec les archétypes qui vont bioen, et je vais essayer aussi de parler un peu d’angular.

Donc, reprenons du début …

Pour commencer, je crée le projet facilement puisque Eclipse me permet d’utiliser les archétypes, et que wisdom en propose maintenant un chouette. Donc je mets les bons paramètres, je clique dans le wizard d’Eclipse sur Finish … et c’est parti, j’ai mon application angular-google-shop que vous retrouverez rapidement dans Github (ce point bien précis est dans le tag 01_-_Après_l'appel_de_l'archétype_maven).

Et là, c’est évidement le moment du premier appel à mvn wisdom:run …

Histoire de ne pas reproduire le pataquès précédent, je vais tout de suite me créer un autre contrôleur (un collègue me soufflait d’ailleurs que ce serait bien cool d’avoir des outils de scaffolding comme dans Grails … pas bête).

Donc on y va pour le tutorial angular …. Sans passer par la case Bootstrapping, puisque j’ai déja fait mon projet.

Je la remplace gaillardement par la création d’un autre contrôleur, que j’appelle GoogleShopController, et dont le contenu est à peu près ça

@Controller
public class GoogleShopController extends DefaultController {
}

Maintenant, je vais le remplir … Ce que j’ai déja fait dans Un peu de wisdom, ça fera du bien

Créons donc un template statique  1 – Static Template

Donc, dans mon contrôleur, je crée une View et une méthode pour l’afficher :

    /**
     * Ici "list" est le nom du fichier du template, sans l'extension thl.html
     */
    @View("list")
    Template list;

    /**
     * Et donc quand on va aller sur http://localhost:9000/list, ça va afficher le template {@link #list}
     */
    @Route(method = HttpMethod.GET, uri = "/list")
    public Result todoList() {
        return ok(render(list));
    }

Et le fichier .thl.html qui va bien … Parce que je l’avais pas fait au début, heureusement j’ai eu droit à une belle exception lors de l’affichage, qui m’a poussé à aller voir le monitoring, qui m’a indiqué cette chouette erreur :

Wisdom Monitor __ Controllers_2014-07-08_15-07-00C’est clair, non ?

Bien, j’en suis donc arrivé à la fin de l’étape 1 du tutoriel, et le résultat est dans le tag 01_-_Etape_01_du_tutoriel_Angular_JS_avec_template_statique.

Et voilà les templates  2 – Angular Templates

Rien de bien sorcier là-dedans, mis à part évidement l’ajout des webjars :

        <dependency>
            <groupId>org.webjars</groupId>
            <artifactId>angularjs</artifactId>
            <version>${angular.version}</version>
        </dependency>
        <dependency>
            <groupId>org.webjars</groupId>
            <artifactId>bootstrap</artifactId>
            <version>${bootstrap.version}</version>
        </dependency>

C’est vraiment cool, je l’ai déja dit.

Bien, au passage, j’avais oublié d’ajouter la CSS de Bootstrap.

Et, encore une fois au passage, Wisdom intègre maintenant un chouette gadget pour ne pas trop s’emmerder avec les chemins des assets :

        <link th:href="${#routes.asset('css/bootstrap.css')}" rel="stylesheet"/>

Vous voyez la « fonction » thymeleaf #routes.asset('..') ? Eh bien elle convertit le chemin côté serveur en un chemin utilisable côté client, en s’occupant de toutes ces histoires de transformation de chemin. Bien joué ! D’ailleurs, elle plante joliment sur le chemin que j’ai entré pour angular, preuve que je n’arrive décidément pas à mettre la main dessus …

Ah, ça y est, j’ai trouvé :

        <script th:src="${#routes.asset('angular.js')}"></script>

Dingue, non ?

Tiens, au passage, une petite observation sur Angular …

Dans cette étape, on utilise pour la première fois ng-repeat="...". Un truc me trouble avec ce bidule : j’ai pas l’impression que ce soit du javascript qui y est écrit …je me trompe ? Eh bien non, ng-repeat utilise une « expression« . Alors ça c’est bizarre …

Et c’est là qu’arrivent les tests jasmine/karma … pour lesquels je dois écrire un Watcher … A moins bien sûr que je ne décide de faire un test Fluentlenium qui accède à la page HTML de tests Jasmine pour les exécuter … Mouais, je vais plutôt faire ça, tiens …
Bon, j’ai pas été au bout, en revanche, l’approche est tellement bonne que je vais en discuter avec la liste wisdom. En fait c’est assez simple : il faut faire un bout d’application qui déclare un contrôleur JasmineRunner. Ce contrôleur définit une route qui cahrge la page de tests de Jasmine et qui utilise cette page pour produire les résultats des tests. Vous pouvez regardez dans le tag qui va bien 02_-_Etape_02_du_tutoriel_avec_templates_Angular_et_tests_Jasmine.

Filtrons 3 – Filtering Repeaters

Ca va aller vite …

Mis à part que protractor se traduit évidement par un vrai test Fluentlenium 🙂

Et là, c’est le drame : je n’arrive pas à trouver la bonne syntaxe pour que ce test marche. En bonus, la syntaxe de Protractor n’a que peu de rapport avec celle de Fluentlenium. Pour tout dire, Protractor me donne l’impression d’un outil très spécifique à Angular, que je trouve de fait d’un intérêt assez faible.

Grmbl ..

Bon, après quelques heures de recherche, il s’est avéré que le test ne marchait pas parce que le driver Selenium par défaut ne supporte pas trop bien la syntaxe Angular.

Et donc, maintenant que j’ai un test Fluentlenium, je peux dire que l’étape 3 est accomplie ! Ce qui donne donc le tag 03_-_Après_l'ajout_du_filtrage.

Trions 4 – Two-way Data Binding

Là aussi, c’est assez rapide puisque je sais déja ce qu’il y a à faire, en fait plus rien de compliqué puisque toute l’infrastructure existe !

En revanche, définitivement, je préfère la syntaxe Fluentlenium. En effet, comme on n’y utilise que le HTML, on « bloque » l’interface dans une forme donnée, sans trop se préoccuper de ce qui est ait au niveau Angular, alors que Protractor fait tout le contraire.

Et du coup, encore un joli tag : 04_-_Après_l'ajout_du_tri.

Bon, comme les étapes suivantes sont du même accabit, je vais accélérer un peu, hein …

5 – XHRs & Dependency Injection

Rien de bien compliqué, juste une copie de fichiers « au bon endroit ».

Il y a toutefois un truc malin dans le mock du service HTTP : le fait de flusher à la main la requête permet d’avoir un contrôle très fin sur ce qui se passe. C’est bien vu !

Bon, par contre, ne pas indiquer dans le tutorial que les tests end-to-end peuvent ne plus marcher, c’est pas très sympa … Mais j’ai quand même le tag 05_-_XHR

6 – Templating Links & Images

Bon là il y a un peu de modification de chemins, mais rien de grave … Quelques modifications dans les tests, aussi, mais vraiment rien de grave. Et le tag est 06_-_Liens_et_images.

7 – Routing & Multiple Views

Alors là, je l’ai déja dit, mais globalement, quand ils disent dans le tutorial

The routing functionality added by this step is provided by angular in the ngRoute module, which is distributed separately from the core Angular framework.

Ca veut juste dire d’ajouter le bon script :

<script th:src="${#routes.asset('angular-route.js')}"></script>

Bon il y a aussi un peu de code à modifier, mais rien d’insurmontable … dans le tag 07_-_avec_deux_routes.

8 – More Templating

Dans le tag 08_-_avec_un_beau_template_pour_les_détails. Je dois juste à l’honnêteté de dire que j’ai réutilisé le test d el’étape 7, parce qu’il y avait franchement une répétition.

9 – Filters

Ca donne un joli tag de plus 09_-_avec_des_filtres_de_rendu … Et l’envie certaine d’intégrer les tests Jasmine dans le build.

10 – Event Handlers

Trop facile ! Y compris le test Fluentlenium qui va bien. D’où le tag 10_-_avec_des_événements.

11 – REST and Custom Services

Là, comme pour les routes, il faut ajouter un module dans bower, c’est-à-dire que c’est déja fait avec webjars … Bon, le mauvais point de mon runner Jasmine actuel, je dois le dire, c’est qu’il n’arrive pas à récupérer les scripts utilisés dans list.thl.html, et c’est dommage. Mais j’imagine qu’un peu de lecture de thymeleaf m’y aiderait …

Ah, petite blague : Angular a écrit son tutorial avec Jasmine 1.3, et ne l’a pas mis à jour. Mais jasmine 2.0 change le style d’écriture des custom matchers, d’où un beforeEach un peu différent de la version fournie avec angular (que je n’ai par ailleurs aps réussi à faire marcher de façon satisfaisante).

J’en ai aussi profité pour m’assurer que je compilais bien en 1.7 …

Et j’ai donc créé le tag 11_-_avec_un_service_REST.

12 – Applying Animations

Bon, il y a le traditionnel ajout d’un module angular …

 <script th:src="${#routes.asset('angular-animate.js')}"></script>

Et l’ajout de …jQuery ? WTF ?!#
Ah, au fait, notez bien qu’à cause d’un « bug » Wisdom, si vous ajoutez un webjar, il faut relancer wisdom:run à la main pour l’instant … Bref …

Revenons-en à nos animations. C’est pas compliqué compliqué, je trouve juste bizarre d’avoir une animation jQuery alors que le tutorial dit bien

jQuery isn’t required to do JavaScript animations with AngularJS, but we’re going to use it because writing your own JavaScript animation library is beyond the scope of this tutorial

Est-ce que c’est pas une façon déguisée de dire que les animations avec jQuery sont quand même plus simples qu’avec angular ?

Cela dit, j’ai mon tag 12_-_avec_des_animations. Et j’ai fini le tutorial !

Conclusion

J’espère vous avoir convaincu, malgré le côté un peu expérimental de cette histoire, de l’intérêt d’utiliser wisdom. Pourquoi ?

  • Parce que le packaging javascript utilisant les webjars est bien plus simple
  • Parce que les tests Fluentlenium sont eux aussi bien plus simples à écrire que les tests protractor
  • Parce que je n’ai pas parlé des optimisations des images, de l’utilisation de LESS, de Typescript, ou d’autres fonctionnalités encore plus chouettes
  • Et enfin parce que lorsqu’on package une application wisdom, on package un tout : client et serveur, bénéficiant à la fois de la facilité de Javascript, et de l’écosystèpme serveur Java.

La suite ?

Je pourrais, dans une version ultérieure, faire un peu de code serveur : générer le phones.json à aprtir d’une servlet quelconque, gérer la sécurité, faire du push via websockets, … Mais pour ça, on verra plus tard.

 

Publicités

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s