Cours GWT présentant certains aspects avancés : - Bus d'évènement - Activities & Places - MVP - ClientFactory - RCP

1. ATELIER TECHNIQUE #2
Framework GWT
François ANDRE
SEDOO
OMP

2. Introduction Architecture Premi`ere application
Cr´eation de l’interface
graphique Bus d’´ev`enements
Cin´ematique de l’appli-
cation
Communication
client-serveur
Conclusion
LICENCE
Le contenu de cette présentation est publié sous la licence :
Creative Commons Attribution 4.0 International License
La copie de cette présentation est autorisée sous réserve du respect
des conditions de la licence (creativecommons.org/licenses/by/4.0/).
2

3. Introduction Architecture Premi`ere application
Cr´eation de l’interface
graphique Bus d’´ev`enements
Cin´ematique de l’appli-
cation
Communication
client-serveur
Conclusion
SOMMAIRE
1. Introduction
2. Architecture
3. Premi`ere application
4. Cr´eation de l’interface
graphique
5. Bus d’´ev`enements
6. Cin´ematique de l’application
7. Communication client-serveur
8. Conclusion
3

4. INTRODUCTION

5. Introduction Architecture Premi`ere application
Cr´eation de l’interface
graphique Bus d’´ev`enements
Cin´ematique de l’appli-
cation
Communication
client-serveur
Conclusion
QUELQUES QUESTIONS...
Où doit se situer un traitement ?
Android ou iOS ?
Des gens utilisent-ils encore IE6 ?
Comment économiser les ressources ?
Comment faire une boucle en Javascript ?
Comment déboguer en Javascript ?
Pourquoi ne puis-je pas faire du Swing ?
Le client-serveur, ça avait son charme, non ?
Pourquoi mon application n’est-elle toujours pas finie ?
Google n’a-t-il pas arrêté GWT ?
5

6. Introduction Architecture Premi`ere application
Cr´eation de l’interface
graphique Bus d’´ev`enements
Cin´ematique de l’appli-
cation
Communication
client-serveur
Conclusion
FIABLILITÉ DE LA CIBLE CSS+HTML5+JAVASCRIPT
6

7. Introduction Architecture Premi`ere application
Cr´eation de l’interface
graphique Bus d’´ev`enements
Cin´ematique de l’appli-
cation
Communication
client-serveur
Conclusion
UNE RÉPONSE POSSIBLE
GWT
7

8. Introduction Architecture Premi`ere application
Cr´eation de l’interface
graphique Bus d’´ev`enements
Cin´ematique de l’appli-
cation
Communication
client-serveur
Conclusion
UNE IDÉE SIMPLE
Coder la partie cliente en Java
La compiler en JavaScript
8

9. Introduction Architecture Premi`ere application
Cr´eation de l’interface
graphique Bus d’´ev`enements
Cin´ematique de l’appli-
cation
Communication
client-serveur
Conclusion
AVANTAGES PRINCIPAUX
Intégré dans l’écosystème JEE
Relié à l’écosystème HTML/Javascript
9

10. Introduction Architecture Premi`ere application
Cr´eation de l’interface
graphique Bus d’´ev`enements
Cin´ematique de l’appli-
cation
Communication
client-serveur
Conclusion
REPÈRE HISTORIQUES
Chronologie succincte :
2006 v1.0
...
2009 v2.0
...
Janvier 2014 v2.6.0
Novembre 2014 v2.7.0 RC1
Futur
Évolutions WEB : HTML5, W3C Web Components ...
Évolutions Java : Support Java 8 ...
Évolutions GWT : Integration Javascript ...
10

11. Introduction Architecture Premi`ere application
Cr´eation de l’interface
graphique Bus d’´ev`enements
Cin´ematique de l’appli-
cation
Communication
client-serveur
Conclusion
PLUS D'INFORMATIONS
Site officiel : http://www.gwtproject.org/
Démonstration officielle :
http://samples.gwtproject.org/samples/Showcase/Showcase.html
Communauté
https://groups.google.com/forum/!forum/google-web-toolkit
https://plus.google.com/communities/116543000751323604177
Conférences en ligne :
GWT Create (http://gwtcreate.com/)
Google I/O (chaîne Youtube)
Blogs :
Gwt Daily (http://www.gwtdaily.com/)
Sami Jabber (http://www.samijaber.com/)
Tutoriels :
http://courses.coreservlets.com/Course-Materials/gwt.html
11

12. ARCHITECTURE

13. Introduction Architecture Premi`ere application
Cr´eation de l’interface
graphique Bus d’´ev`enements
Cin´ematique de l’appli-
cation
Communication
client-serveur
Conclusion
ELÉMENTS MIS EN ŒUVRE
13

14. TWITTER BOOTSTRAP

15. Introduction Architecture Premi`ere application
Cr´eation de l’interface
graphique Bus d’´ev`enements
Cin´ematique de l’appli-
cation
Communication
client-serveur
Conclusion
TWITTER BOOTSTRAP
Description : Collection d’outils HTML/CSS/Javascript
Objectif : Compenser l’aspect brut des composants GWT
Rendu moderne
Site web
adaptatif (RWD)
Grande
Popularité
15

16. SPRING FRAMEWORK

17. Introduction Architecture Premi`ere application
Cr´eation de l’interface
graphique Bus d’´ev`enements
Cin´ematique de l’appli-
cation
Communication
client-serveur
Conclusion
SPRING FRAMEWORK
Description : Framework Java permettant la mise en place d’un
conteneur léger
Objectif : Simplification de l’architecture et fiabilisation du code
Inversion de
contrôle (IoC)
Bibliothèques
complémentaires
(accès aux
données, ...)
17

18. JPA : JAVA PERSISTENCE API

19. Introduction Architecture Premi`ere application
Cr´eation de l’interface
graphique Bus d’´ev`enements
Cin´ematique de l’appli-
cation
Communication
client-serveur
Conclusion
JPA : JAVA PERSISTENCE API
Description : API officielle de Mapping Objet-SGBD
Objectif : Simplifier la mise en œuvre de la persistance
Définition du mapping via annotation
Interrogation via JPQL
19

20. MAVEN

21. Introduction Architecture Premi`ere application
Cr´eation de l’interface
graphique Bus d’´ev`enements
Cin´ematique de l’appli-
cation
Communication
client-serveur
Conclusion
MAVEN
Description : Moteur de production
Objectif : Fiabilise les étapes clés du développement (compilation,
test, génération, livraison,...)
Le fichier pom.xml : configuration globale du projet
Arborescence
/src Sources du projet
/src/main Partie principale
/src/main/java Code source
/src/main/resources Fichier de ressources (images, config, ...)
/src/main/webapp Webapp du projet
/src/test Partie test
/src/test/java Code source des tests
/src/test/resources Fichiers de ressources des tests
/target Fichiers produits (classes, .war, .jar)
Compatibilité avec les outils d’intégration continue (Jenkins...)
21

22. ECLIPSE

23. Introduction Architecture Premi`ere application
Cr´eation de l’interface
graphique Bus d’´ev`enements
Cin´ematique de l’appli-
cation
Communication
client-serveur
Conclusion
ECLIPSE
Description : Environnement de développement intégré (EDI)
Objectif : Édition des sources, lien avec le SCM, débogage
GWT ne nécessite pas d’EDI particulier. D’autres EDI (IntelliJ,
Netbeans, vi) peuvent être utilisés.
L’équipe Google fournit un module (plugin) pour Eclipse proposant
certaines fonctionnalités utiles :
Génération
Validation
...
Remarques:
le plugin M2E est déconseillé pour les projets GWT
Distribution privilégiée : Eclipse IDE for Java EE Developers
23

24. Introduction Architecture Premi`ere application
Cr´eation de l’interface
graphique Bus d’´ev`enements
Cin´ematique de l’appli-
cation
Communication
client-serveur
Conclusion
PLUGIN GWT (NAVIGATEUR)
Classical dev mode
Jusqu’à la version 2.6.0, le développement GWT - Dev Mode - repose
sur un module installé sur le navigateur (Chrome, Firefox, IE, Safari).
Ce mode est contraignant pour les développeur de GWT pour les
raisons suivantes :
Le nombre de navigateurs
Les API propriétaires sous jacentes
De plus, lorsque la taille de l’application augmente le temps de
rafraichissement devient bloquant.
Super dev mode
Depuis la version 2.4.0 il est progressivement remplacé par le Super
Dev Mode qui permet de débugger dans les navigateurs supportant le
standard SourceMaps (Chrome, Firefox).
Le plugin SDBG permet de conserver un débuggage dans Eclipse.
24

25. PREMIÈRE APPLICATION

26. GÉNÉRATION D'UN SQUELETTE
APPLICATIF

27. Introduction Architecture Premi`ere application
Cr´eation de l’interface
graphique Bus d’´ev`enements
Cin´ematique de l’appli-
cation
Communication
client-serveur
Conclusion
GÉNÉRATION SQUELETTE APPLICATIF
Utilisation de l’archetype GWT du SEDOO Prérequis:
JVM
Maven / Ant
Eclipse
Etape 1 : Génération archetype
mvn archetype:generate -DarchetypeGroupId=fr.sedoo.archetype
-DarchetypeArtifactId=archetype-gwt -DarchetypeVersion=1.0-SNAPSHOT
-DgroupId=org.mondomaine -DartifactId=testgwt -DarchetypeRepository=http://
Etape 2 : Mise en place configuration eclipse
ant eclipse -DM2_HOME=$M2_HOME
Etape 3 : Import dans eclipse
Import... > Existing Projects into Workspace
27

28. EXPLORATION DU SQUELETTE

29. Introduction Architecture Premi`ere application
Cr´eation de l’interface
graphique Bus d’´ev`enements
Cin´ematique de l’appli-
cation
Communication
client-serveur
Conclusion
EXPLORATION DU SQUELETTE
Architecture Maven classique
/src/main/java
/src/main/resources
/src/main/webapp
...
Architecture GWT classique
Package client Classes de la partie cliente (⇒ Javascript)
Package shared
Classes communes client & serveur
(⇒ Javascript & Java)
Package server
Classes de la partie serveur
(⇒ Application JEE standard)
29

30. Introduction Architecture Premi`ere application
Cr´eation de l’interface
graphique Bus d’´ev`enements
Cin´ematique de l’appli-
cation
Communication
client-serveur
Conclusion
CONTRAINTES PACKAGE CLIENT & SHARED
Les classes doivent utiliser/étendre le JDK émulé par GWT
(http://www.gwtproject.org/doc/latest/RefJreEmulation.html)
Exemples :
Autorisé: Object, HashMap, ArrayList,
com.google.common.base.Strings (Guava)...
Interdit : File, StringUtils (commons-lang), ...
Les classes transitant entre client et serveur doivent être
sérialisables:
• implémenter java.io.Serializable|
• implémenter
com.google.gwt.user.client.rpc.IsSerializable|
des beans:
• Constructeur vide
• Getters et Setters
30

31. Introduction Architecture Premi`ere application
Cr´eation de l’interface
graphique Bus d’´ev`enements
Cin´ematique de l’appli-
cation
Communication
client-serveur
Conclusion
DESCRIPTEUR DU MODULE: MODULE.GWT.XML
Rôle
Pilotage de l’application
Position
au dessus du package client
Contenu
Nom du module <module>
Point d’entrée
<entry-point class=’fr.sedoo.sssdata.client.SssData’ />
Autres modules à importer : <inherits>
Répertoires : <source>
Paramètres divers: langues...
Remplacement dynamique des classes
<replace-with class="fr.sedoo.sssdata.client.ClientFactoryImpl">
<when-type-is class="fr.sedoo.sssdata.client.ClientFactory"/>
</replace-with>
31

32. Introduction Architecture Premi`ere application
Cr´eation de l’interface
graphique Bus d’´ev`enements
Cin´ematique de l’appli-
cation
Communication
client-serveur
Conclusion
CONTENEUR HTML
Rôle
Chargement de l’application
Position
Dans le répertoire webapp
Contenu
Page HTML classique (js, css, balises HTML...)
Chargement du module
<script type="text/javascript" language="javascript"
src="sssdata/sssdata.nocache.js"></script>
Remarque: le script nocache.js charge la compilation adéquate
du module :
La plus récente
Correspondant au navigateur du client et à sa langue
32

33. Introduction Architecture Premi`ere application
Cr´eation de l’interface
graphique Bus d’´ev`enements
Cin´ematique de l’appli-
cation
Communication
client-serveur
Conclusion
COMPILATION ET PERMUTATIONS
Lors de la compilation Javascript, GWT génère une tradution pour
chaque couple
moteur de navigateur supporté (6)
langue indiquée dans le descripteur de module
Les permutations sont une des nombreuses optimisations fournies par
GWT.
33

34. Introduction Architecture Premi`ere application
Cr´eation de l’interface
graphique Bus d’´ev`enements
Cin´ematique de l’appli-
cation
Communication
client-serveur
Conclusion
ENTRY POINT
Rôle
Équivalent de main dans les application Java
Position
Dans le package client
Conformément au fichier gwt.xml
Contenu
Implémente com.google.gwt.core.client.EntryPoint
→ public void onModuleLoad();
• Construit les éléments de l’interface utilisateur
• Optionnellement, supprime certains éléments du conteneur HTML
RootPanel loadingMessage = RootPanel.get("loadingMessage");
DOM.setInnerHTML(loadingMessage.getElement(), "");
• Ajoute l’interface utilisateur dans le conteneur HTML ;
skeleton = new TopSideMenuSkeleton(clientFactory.getEventBus());
RootLayoutPanel.get().add(skeleton)
34

35. Introduction Architecture Premi`ere application
Cr´eation de l’interface
graphique Bus d’´ev`enements
Cin´ematique de l’appli-
cation
Communication
client-serveur
Conclusion
AUTRES FICHIERS REMARQUABLES
Configuration Maven
/pom.xml
Alias Maven
/build.xml
Cibles principales:
• /eclipse: Reconstitution de la configuration Eclipse en fonction
du pom.xml.
A utiliser à chaque modification du pom.xml ou du répertoire
/src/main/webapp
• /package: Génération du war.
Launch Eclipse
/gui.launch : Lancement de l’application en Mode dev
Configuration Spring
/src/main/webapp/WEB-INF/BeanLocations.xml
Configuration JPA
/src/main/resources/META-INF/persistence.xml
35

36. CRÉATION DE L'INTERFACE
GRAPHIQUE

37. COMPOSANTS DE BASES

38. Introduction Architecture Premi`ere application
Cr´eation de l’interface
graphique Bus d’´ev`enements
Cin´ematique de l’appli-
cation
Communication
client-serveur
Conclusion
COMPOSANTS DE BASE
GWT propose un certain nombre de composants de base pour
construire les interfaces:
Widgets élémentaires: boutons, zones de texte, cases à cocher...
Panneaux de positionnement (similaires à Swing): panneaux
horizontaux, verticaux, à onglets...
Comme en Swing, ces éléments sont des classes Java et se
combinent afin de créer l’interface souhaitée.
38

39. Introduction Architecture Premi`ere application
Cr´eation de l’interface
graphique Bus d’´ev`enements
Cin´ematique de l’appli-
cation
Communication
client-serveur
Conclusion
WIDGETS ÉLÉMENTAIRES
Étendent com.google.gwt.user.client.ui.Widget
Exemples :
TextBox
TextArea
Button
RadioButton
CheckBox
DatePicker, CellList...
39

40. Introduction Architecture Premi`ere application
Cr´eation de l’interface
graphique Bus d’´ev`enements
Cin´ematique de l’appli-
cation
Communication
client-serveur
Conclusion
PANNEAUX DE POSITIONNEMENT
Panneaux classiques
(étendent com.google.gwt.user.client.ui.Panel)
Exemples :
HorizontalPanel
VerticalPanel
FlowPanel
HTMLPanel
Permet de mixer des balises HTML et des com-
posants GWT
Remarque: les panneaux héritent aussi de Widget
40

41. Introduction Architecture Premi`ere application
Cr´eation de l’interface
graphique Bus d’´ev`enements
Cin´ematique de l’appli-
cation
Communication
client-serveur
Conclusion
PANNEAUX DE POSITIONNEMENT
Panneaux dynamiques
(implémentent
com.google.gwt.user.client.ui.ProvidesResize et
com.google.gwt.user.client.ui.RequiresResize )
Exemples :
DockLayoutPanel
SplitLayoutPanel
TabLayoutPanel
41

42. LIBRAIRIES COMPLÉMENTAIRES

43. Introduction Architecture Premi`ere application
Cr´eation de l’interface
graphique Bus d’´ev`enements
Cin´ematique de l’appli-
cation
Communication
client-serveur
Conclusion
LIBRAIRIES COMPLÉMENTAIRES
Solutions spécifiques en GWT :
Sencha GXT (http://www.sencha.com/products/gxt/)
Vaadin (https://vaadin.com/home)
Sencha GXT
43

44. Introduction Architecture Premi`ere application
Cr´eation de l’interface
graphique Bus d’´ev`enements
Cin´ematique de l’appli-
cation
Communication
client-serveur
Conclusion
LIBRAIRIES COMPLÉMENTAIRES
Portage de libraries Javascript :
GWTBootstrap3 (https://github.com/gwtbootstrap3)
Gwt-Openlayers (http://www.gwt-openlayers.org/)
Exemple GWTBootstrap3 :
Alert loginFirst = new Alert("You must connect to access to this page");
Remarque: un portage Javascript (Wrapping) peut occasionner un débogage plus difficile.
44

45. Introduction Architecture Premi`ere application
Cr´eation de l’interface
graphique Bus d’´ev`enements
Cin´ematique de l’appli-
cation
Communication
client-serveur
Conclusion
CRÉATION DE COMPOSANTS
Par héritage d’un Widget :
Exemple: création d’une infobulle d’aide Classe :
Utilisation :
HelpTooltip aide = new HelpTooltip("mon texte d’aide");
monPanneau.add(aide);
Résultat :
45

46. Introduction Architecture Premi`ere application
Cr´eation de l’interface
graphique Bus d’´ev`enements
Cin´ematique de l’appli-
cation
Communication
client-serveur
Conclusion
CRÉATION DE COMPOSANTS
Par héritage d’un Composite :
Objectif: Permet de créer un composant en combinant
plusieurs Widgets sans en exposer les méthodes.
Attention : il est nécessaire d’appeler la fonction initWidget sur
un des composants lors du constructeur.
46

47. UIBINDER

48. Introduction Architecture Premi`ere application
Cr´eation de l’interface
graphique Bus d’´ev`enements
Cin´ematique de l’appli-
cation
Communication
client-serveur
Conclusion
UIBINDER : MOTEUR DE TEMPLATES
Rôle
Simplifier la création d’écran complexes avec un moteur de
templates
Principe
Un fichier de description, monFichier.ui.xml, permet de définir
l’écran de manière similaire à une page HTML/JSP...
Dans ce fichier les noms des balises importantes sont indiqués
via l’attribut ui:field
Une classe, monFichier.java permet de définir le comportement
dynamique associé à cet écran.
Cette classe étend Composite
Dans cette classe on retrouve le nom des attributs ui:field
indiqués dans le fichier de description
48

49. Introduction Architecture Premi`ere application
Cr´eation de l’interface
graphique Bus d’´ev`enements
Cin´ematique de l’appli-
cation
Communication
client-serveur
Conclusion
UIBINDER : EXEMPLE
Descripteur : MetadataSearchViewImpl.ui.xml
49

50. Introduction Architecture Premi`ere application
Cr´eation de l’interface
graphique Bus d’´ev`enements
Cin´ematique de l’appli-
cation
Communication
client-serveur
Conclusion
UIBINDER : EXEMPLE
Classe : MetadataSearchViewImpl.java
50

51. Introduction Architecture Premi`ere application
Cr´eation de l’interface
graphique Bus d’´ev`enements
Cin´ematique de l’appli-
cation
Communication
client-serveur
Conclusion
UIBINDER : COMPLÉMENTS
Instantication des champs ui:field
Soit par le fichier de description lors de l’appel à initWidget
dans le constructeur :
initWidget(uiBinder.createAndBindUi(this));
Soit manuellement
• En modifiant l’annotation UiField : @UiField(provided = true)
• En instanciant les champs avant l’appel à initWidget.
Ajout ce comportement sur les éléments
Via l’annotation @UiHandler
La signature de la méthode permet d’indiquer l’évènement géré
@UiHandler("searchButton")
void onSearchButtonClicked(ClickEvent event)
{
...
}
51

52. Introduction Architecture Premi`ere application
Cr´eation de l’interface
graphique Bus d’´ev`enements
Cin´ematique de l’appli-
cation
Communication
client-serveur
Conclusion
UIBINDER : COMPLÉMENTS
Utilisation de Widgets personnels
La balise <ui:UiBinder> permet de définir via des espaces de
nommage les packages utilisables dans la page:
<ui:UiBinder xmlns:ui="urn:ui:com.google.gwt.uibinder"
xmlns:l="urn:import:fr.sedoo.metadata.client.ui.widget.date">
...
<l:Iso19115DateBox ui:field="startDate" />
Des paramètres peuvent être transmis dans les attributs.
Si le Widget possède plusieurs constructeurs, l’annotation
@UiConstructeur permet d’indiquer celui que UiBinder va utiliser.
52

53. CLIENTFACTORY

54. Introduction Architecture Premi`ere application
Cr´eation de l’interface
graphique Bus d’´ev`enements
Cin´ematique de l’appli-
cation
Communication
client-serveur
Conclusion
CLIENTFACTORY
Objectif : Optimiser le temps d’instanciation des objets
complexes
Problème : Certains composants clients sont coûteux à
instancier notamment les différents éléments de l’interface
graphique.
Solution : Utiliser une Factory ayant la charge d’instancier de
manière unique - et si nécessaire - ces différents composants et
de les transmettre aux objets voulant les utiliser (Exemple: le
Presenter dans le modèle MVP) .
Remarque
Par ce mécanisme, les écrans graphiques ne sont créés qu’une seule fois. Ils sont par contre
remis à zéro (exemple : vidage des champs de saisie) lors de chaque utilisation.
Ce concept de Singleton est aussi étendu pour gérer les autres
instances uniques de l’application comme par exemple le bus
d’évènements (cf. infra). 54

55. BUS D'ÉVÈNEMENTS

56. Introduction Architecture Premi`ere application
Cr´eation de l’interface
graphique Bus d’´ev`enements
Cin´ematique de l’appli-
cation
Communication
client-serveur
Conclusion
BUS D'ÉVÈNEMENTS
Objectif : Simplifier la communication entre les composants
Problème : Les interfaces des applications GWT peuvent
contenir de nombreux composants qui doivent dialoguer entre
eux. Toutefois, dans certains cas ce dialogue ne peux pas se
faire directement
Pour éviter un trop fort couplage entre les classes.
Parce que les composants cibles du dialogue ne peuvent pas être
connus du composant source.
Solution : GWT propose un bus permettant l’échange
d’évènements entre composants reposant sur un mécanisme
d’abonnement:
1. Un type d’évènement spécifique est défini.
2. Les composants cibles s’abonnent à ce type d’évènement auprès
du bus.
3. Lorsque nécessaire, le composant source instancie un évènement
et demande sa propagation sur le bus.
56

57. Introduction Architecture Premi`ere application
Cr´eation de l’interface
graphique Bus d’´ev`enements
Cin´ematique de l’appli-
cation
Communication
client-serveur
Conclusion
DÉFINITION D'UN ÉVÈNEMENT
Exemple : évènement signalant la connexion d’un utilisateur -
UserLoginEvent
Il est nécessaire de créer deux classes:
Le gestionnaire : UserLoginEventHandler
L’évènement : UserLoginEvent
Le gestionnaire
Interface qui sera implémentée par les classes écoutant
l’évènement
Doit étendre com.google.gwt.event.shared.EventHandler
57

58. Introduction Architecture Premi`ere application
Cr´eation de l’interface
graphique Bus d’´ev`enements
Cin´ematique de l’appli-
cation
Communication
client-serveur
Conclusion
DÉFINITION D'UN ÉVÈNEMENT
L’évènement
La classe doit étendre
com.google.gwt.event.shared.GwtEvent
Elle définit un attribut statique - traditionnellement nommé TYPE -
qui va identifier l’évènement et permettre de s’y abonner auprès
du bus.
58

59. Introduction Architecture Premi`ere application
Cr´eation de l’interface
graphique Bus d’´ev`enements
Cin´ematique de l’appli-
cation
Communication
client-serveur
Conclusion
ABONNEMENT ET PUBLICATION
Abonnement à un évènement
L’abonnement auprès du bus s’effectue via la méthode
addHandler en passant en paramètres le type de l’évènement et
le composant cible.
Celui-ci doit implémenter le Handler correspondant à
l’évènement :
EVENT_BUS.addHandler(UserLoginEvent.TYPE, monComposantCible);
Publication d’un évènement La diffusion d’un évènement sur le bus s’effectue de la
manière suivante :
UserLoginEvent monEvenement = new UserLoginEvent();
// Valorisation de l’objet monEvenement ...
EVENT_BUS.fireEvent(monEvenement);
59

60. CINÉMATIQUE DE L'APPLICATION

61. Introduction Architecture Premi`ere application
Cr´eation de l’interface
graphique Bus d’´ev`enements
Cin´ematique de l’appli-
cation
Communication
client-serveur
Conclusion
TROIS COMPOSANTS STRUCTURANTS
La cinématique d’une application Ajax diffère d’une application
Web traditionnelle où le serveur joue un rôle de chef d’orchestre.
Les versions récentes de GWT ont introduit un certain nombre de
bonnes pratiques permettant la construction rigoureuse d’une
telle cinématique:
Gestion de l’historique
Activities and Places
Patron Model-View-Presenter
61

62. Introduction Architecture Premi`ere application
Cr´eation de l’interface
graphique Bus d’´ev`enements
Cin´ematique de l’appli-
cation
Communication
client-serveur
Conclusion
GESTION DE L'HISTORIQUE
Objectif : Permettre une gestion complète de l’historique,
notamment la navigation via les boutons Précédent/Suivant
Principe :
Chaque état de l’application est sérialisé sous forme d’une chaine
(token) ajoutée à l’URL actuelle sous forme d’un lien nommé
(c.a.d séparé par un #). Exemple :
http://sedoo.sedoo.fr/portailresif/#WelcomePlace:
Un évènement de type navigation (Précédent, Suivant,
Rafraichissement) déclenche un évènement de type
ValueChangeEvent.
62

63. GESTION DE L'HISTORIQUE

64. Introduction Architecture Premi`ere application
Cr´eation de l’interface
graphique Bus d’´ev`enements
Cin´ematique de l’appli-
cation
Communication
client-serveur
Conclusion
GESTION DE L'HISTORIQUE
Mise en œuvre :
Activation dans le conteneur HTML
<iframe src="javascript:’’" id="__gwt_historyFrame"
style="position:absolute;width:0;height:0;border:0"></iframe>
Une nouvelle étape dans l’historique est ajoutée en appelant
History.newItem(token)
Chaque objet voulant réagir aux évènement de l’historique s’abonne aux
History.addValueChangeHandler(). Chaque abonné devra déterminer
• si l’évènement le concerne
• comment reconstruire l’état correspondant au token.
64

65. ACTIVITIES AND PLACES

66. Introduction Architecture Premi`ere application
Cr´eation de l’interface
graphique Bus d’´ev`enements
Cin´ematique de l’appli-
cation
Communication
client-serveur
Conclusion
ACTIVITIES
Activity : Une activité est une fonctionnalité de l’application
effectuée par un utilisateur.
Exemples : LoginActivity, SearchActivity...
Une activité étend
com.google.gwt.activity.shared.AbstractActivity
Cycle de vie : La gestionnaire d’activité
(com.google.gwt.activity.shared.ActivityManager)
active et désactive les activités via les méthodes suivantes :
start
Invoquée lors du démarage de l’activité. A son is-
sue, l’activité doit fournir la vue lui correspondant.
mayStop
Invoquée pour savoir si l’activité en cours peut s’ar-
rêter.
onStop Invoquée lors de l’arrêt de l’activité.
onCancel
Invoquée lorsque le démarrage n’est pas termn-
iné mais que l’utilisateur a demandé le début d’une
autre activité.
66

67. Introduction Architecture Premi`ere application
Cr´eation de l’interface
graphique Bus d’´ev`enements
Cin´ematique de l’appli-
cation
Communication
client-serveur
Conclusion
PLACES
Place : Une place représente un état d’utilisation d’une activité. Il
doit pouvoir être sérialisé sous forme de token conformément au
mécanisme de gestion de l’historique.
Mise en œuvre :
Une place hérite de com.google.gwt.place.shared.Place.
Le tokenizer associé à la place hérite de
com.google.gwt.place.shared.PlaceTokenizer.
Il permet la sérialisation/désérialisation de l’état via les méthodes
suivantes :
getPlace Construit la place à partir du token.
getToken Sérialise la place sous forme de token.
Bonne pratique
A chaque instanciation d’une activité, une place va lui être transmise afin que l’activité recrée
son état.
67

68. Introduction Architecture Premi`ere application
Cr´eation de l’interface
graphique Bus d’´ev`enements
Cin´ematique de l’appli-
cation
Communication
client-serveur
Conclusion
NAVIGATION VIA LES PLACES
Les places sont le meilleur moyen de naviguer au sein d’une
application GWT.
Le mécanisme est le suivant:
1. Instanciation et valoriastion de la place souhaitée
2. Récupération de l’instance du PlaceController (Cf.
ClientFactory)
3. Appel de la méthode PlaceController.goTo(place)
4. Si la place souhaitée n’est pas la place en cours, l’activité
correspondante à la place est instanciée (cf. page suivante).
5. La méthode start de l’activité est appelée.
Remarques
Ce mécanisme est également celui utilisé lors de l’analyse d’une URL pointant sur une
place de l’application.
Le PlaceController utilise la méthode equals pour comparer place actuelle et
destination. Le cas échéant il peut être nécessaire de surcharger cette méthode
68

69. Introduction Architecture Premi`ere application
Cr´eation de l’interface
graphique Bus d’´ev`enements
Cin´ematique de l’appli-
cation
Communication
client-serveur
Conclusion
NAVIGATION VIA LES PLACES
La correspondance entre Place et Activity est effectuée de la
manière suivante:
1. Le PlaceController envoie un évènement de changement de
place (PlaceChangeEvent)
2. L’évènement est reçu par le gestionnaire d’activités
(ActivityManager)
3. Le gestionnaire d’activités utilise son ActivityMapper qui lui
indique l’activité à démarrer via la méthode
Activity getActivity(Place place);
La classe ActivityMapper est donc le composant central du
mécanisme.
Exemple
public Activity getActivity(Place place) {
if (place instanceof WelcomePlace)
{
return new WelcomeActivity((WelcomePlace) place, clientFactory);
}
...
}
69

70. Introduction Architecture Premi`ere application
Cr´eation de l’interface
graphique Bus d’´ev`enements
Cin´ematique de l’appli-
cation
Communication
client-serveur
Conclusion
NAVIGATION VIA LES PLACES
Activité A ActivityManager ActivityMapper Activité B PlaceController EventBus ClientFactory
évènement
crééPlaceB()
getPlaceController()
goTo(placeB)()
fireEvent(placeChangeRequestEvent(placeB))
onPlaceChangeRequest(PlaceChangeRequestEvent)(placeB)
mayStop()
fireEvent(placeChangeEvent(placeB))
onPlaceChange(placeB)
getActivity(placeB)
nouvelle activité B
onStop()
start()
70

71. PATRON MODEL-VIEW-PRESENTER

72. Introduction Architecture Premi`ere application
Cr´eation de l’interface
graphique Bus d’´ev`enements
Cin´ematique de l’appli-
cation
Communication
client-serveur
Conclusion
PATRON MODEL-VIEW-PRESENTER
GWT étend le traditionnel modèle MVC avec le patron MVP dans
lequel le Presenter tient le rôle central.
Nom Situation Rôle
Model Côté serveur Récupère les données (via les DAO).
View Côté client
Affichage des données transmises par le Presenter.
Transmet au Presenter les évènements importants
(exemple: click sur des boutons,...)
Presenter Côté client
Mobilise le Model et transmet les données à la vue.
Réagit aux évènements transmis par la vue afin nota-
ment de dialoguer avec le Model ou changer de Place
Stratégie
L’objectif est de postionner un maximum d’intelligence au niveau du Presenter afin
que celui-ci puisse fonctionner indifféremment avec plusieurs implémentations de View
(exemple: View pour un écran d’ordinateur de grande taille, View pour un mobile, View
ficitve pour les tests...).
La View est donc dépourvue de traitements outre ceux spécifiques à son
implémentation. Ceci permet de l’exclure plus ou moins de la chaine de test.
72

73. Introduction Architecture Premi`ere application
Cr´eation de l’interface
graphique Bus d’´ev`enements
Cin´ematique de l’appli-
cation
Communication
client-serveur
Conclusion
DIAGRAMME MVP
Presenter
ModelView
73

74. Introduction Architecture Premi`ere application
Cr´eation de l’interface
graphique Bus d’´ev`enements
Cin´ematique de l’appli-
cation
Communication
client-serveur
Conclusion
INTÉGRATION AVEC LE MODÈLE ACTIVITIES AND PLACES
L’activity joue le rôle du Presenter
74

75. Introduction Architecture Premi`ere application
Cr´eation de l’interface
graphique Bus d’´ev`enements
Cin´ematique de l’appli-
cation
Communication
client-serveur
Conclusion
MISE EN PLACE D'UNE VIEW
Une View doit être définie sous forme d’une Interface qui étend
com.google.gwt.user.client.ui.IsWidget.
Le Presenter ne doit connaître que cette Interface.
Si la View doit pouvoir transmettre des informations au
Presenter, l’usage veut que celui-ci soit défini comme une
sous-interface de la View. Dans ce cas:
La View doit définir une methode setPresenter correspondante.
L’Activity doit implémenter le Presenter.
75

76. Introduction Architecture Premi`ere application
Cr´eation de l’interface
graphique Bus d’´ev`enements
Cin´ematique de l’appli-
cation
Communication
client-serveur
Conclusion
RÉCUPÉRATION DE LA VIEW PAR LE PRESENTER
Le lien entre une View et l’implémentation à utiliser dans le
contexte courant est fait par la ClientFactory.
Ceci permet d’envisager la mise en place de plusieurs
implémentations de ClientFactory:
pour les mobiles
pour les tests
...
76

77. Introduction Architecture Premi`ere application
Cr´eation de l’interface
graphique Bus d’´ev`enements
Cin´ematique de l’appli-
cation
Communication
client-serveur
Conclusion
CINÉMATIQUE D'UTILISATION
Classiquement, la cinématique d’utilisation est la suivante:
1. L’Activity récupère l’instance de la View auprès de la
ClientFactory (dans sa méthode start)
2. Si nécessaire, utilise la méthode setPresenter de la View pour
permettre une communication View ⇒ Presenter.
3. L’Activity remet à zéro l’instance de la View (qui a peut être servi
au préalable)
4. L’Activity recherche auprès du Model les informations
nécessaires
5. L’Activity les transmet à la vue qui les positionne.
6. L’Activity affiche la vue via la commande
containerWidget.setWidget(view.asWidget());
77

78. Introduction Architecture Premi`ere application
Cr´eation de l’interface
graphique Bus d’´ev`enements
Cin´ematique de l’appli-
cation
Communication
client-serveur
Conclusion
CINÉMATIQUE D'UTILISATION
ActivityManager MonActivité MaVue MonModèle ClientFactory
start()
getMaVue()
instance de MaVue
setPresenter(this)
reset()
chargeInformations()
afficheInformations()
affiche la vue
78

79. Introduction Architecture Premi`ere application
Cr´eation de l’interface
graphique Bus d’´ev`enements
Cin´ematique de l’appli-
cation
Communication
client-serveur
Conclusion
COMMUNICATION PRESENTER - MODEL
La communication entre le Presenter et le Model s’effectue via le
mécanisme GWT-RPC décrit dans la section suivante.
79

80. COMMUNICATION CLIENT-SERVEUR

81. Introduction Architecture Premi`ere application
Cr´eation de l’interface
graphique Bus d’´ev`enements
Cin´ematique de l’appli-
cation
Communication
client-serveur
Conclusion
GWT-RPC
GWT-RPC (Remote Procedure Call) est un mécanisme simple de
communication client/serveur.
La mise en place d’un service RPC - par exemple MonService - passe
par la création de trois classes:
Côté client
MonService : Définit l’interface du service
MonServiceAsync : Équivalent asynchrone de l’interface
MonService
Côté serveur
MonServiceImpl : Servlet implémentant le service (accès aux
DAO...)
Rappel
Les objets pouvant transiter entre le serveur et le client doivent
être situés dans le package shared
être des beans sérialisables
81

82. Introduction Architecture Premi`ere application
Cr´eation de l’interface
graphique Bus d’´ev`enements
Cin´ematique de l’appli-
cation
Communication
client-serveur
Conclusion
GWT-RPC
82

83. Introduction Architecture Premi`ere application
Cr´eation de l’interface
graphique Bus d’´ev`enements
Cin´ematique de l’appli-
cation
Communication
client-serveur
Conclusion
MISE EN PLACE CÔTÉ CLIENT
Interface MonService
L’interface doit étendre
com.google.gwt.user.client.rpc.RemoteService.
L’annotation @RemoteServiceRelativePath va permettre
d’associer la partie cliente à la servlet correspondante.
83

84. Introduction Architecture Premi`ere application
Cr´eation de l’interface
graphique Bus d’´ev`enements
Cin´ematique de l’appli-
cation
Communication
client-serveur
Conclusion
MISE EN PLACE CÔTÉ CLIENT
Interface MonServiceAsync
Cette classe reprend les méthodes de MonService en leur
rajoutant un aspect asynchrone (via les AsyncCallback ).
Elle peut être générée automatiquement à partir de MonService
(Eclipse propose cette possibilité via le QuickFix Create
asynchronous RemoteService ... )
Elle permet une communication asynchrone afin de ne pas
bloquer le navigateur. C’est uniquement cette classe qui sera
utilisée concrètement.
84

85. Introduction Architecture Premi`ere application
Cr´eation de l’interface
graphique Bus d’´ev`enements
Cin´ematique de l’appli-
cation
Communication
client-serveur
Conclusion
MISE EN PLACE CÔTÉ SERVEUR
Classe MonServiceImpl
Elle étend com.google.gwt.user.server.rpc.RemoteServiceServlet.
Elle implémente MonService.
Fichier web.xml
La classe MonServiceImpl est une servlet. Elle doit être
déclarée et mappée correctement dans le fichier web.xml. Ce
mapping doit correspondre à la valeur indiquée pour l’annotation
@RemoteServiceRelativePath
85

86. Introduction Architecture Premi`ere application
Cr´eation de l’interface
graphique Bus d’´ev`enements
Cin´ematique de l’appli-
cation
Communication
client-serveur
Conclusion
UTILISATION DU SERVICE
Typiquement, un service RPC doit être utilisé par le Presenter.
Instanciation
Elle utilise le mécanisme GWT.create afin de créer la classe
MonServiceAsync:
private final MonServiceAsync MON_SERVICE = GWT.create(MonService.class);
Utilisation
Les appels asynchrones nécessitent la mise en place - souvent anonyme - de classes de
CallBack qui permettent de définir les traitements à effectuer en cas de réussite ou de
succès.
86

87. Introduction Architecture Premi`ere application
Cr´eation de l’interface
graphique Bus d’´ev`enements
Cin´ematique de l’appli-
cation
Communication
client-serveur
Conclusion
ASPECT ASYNCHRONE DES ÉCHANGES
Les appels du client vers le serveur sont asynchrones. Il faut donc
bien veiller à faire en sorte que les traitements dépendants du résultat
(exemple : mise à jour de l’IHM) soient positionnés dans les fonctions
de callBack (onSuccess et onFailure) et non à la suite de l’appel.
87

88. Introduction Architecture Premi`ere application
Cr´eation de l’interface
graphique Bus d’´ev`enements
Cin´ematique de l’appli-
cation
Communication
client-serveur
Conclusion
LIMITATIONS DE GWT-RPC
RPC est un mécanisme assez simple qui contient certaines
limitations. La principale est l’utilisation d’interfaces de type List
ou Set pour les types d’échanges.
Celle-ci est totalement possible. Toutefois, lors de la compilation
en Javascript, une traduction pour chaque implémentation
concrète présente dans l’émulation du JRE (ArrayList, Vector...
)va être ajoutée, alourdissant ainsi le code généré.
Ainsi, les types concrets doivent être privilégiés à ce niveau.
Le mécanisme RequestFactory propose par rapport à RPC un
certain nombre d’améliorations permettant d’avoir des échanges
plus optimisés entre le client et le serveur.
88

89. CONCLUSION

90. Introduction Architecture Premi`ere application
Cr´eation de l’interface
graphique Bus d’´ev`enements
Cin´ematique de l’appli-
cation
Communication
client-serveur
Conclusion
CONCLUSION
Le framework GWT est extrêmement riche, d’autres
fonctionnalités restent à aborder :
Mise en place du multilinguisme (I18n)
Optimisation des ressources Image et Style
Optimisation des échanges Client/Serveur (RequestFactory)
Inversion de contrôle côté client (GIN)
Chargement du code client par tranche (Code spliting)
Déboggage via le navigateur (Super dev mode)
...
De plus la mise en œuvre d’un projet GWT peut également
nécessiter la connaissance de technologies complémentaires :
Architecture REST (SOAP)
Responsive Design
Git & Gitflow
...
90