IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Le framework MVP (Places et Activités) dans GWT

Le framework MVP (Places et Activités) dans GWT

Date de publication : xx/xx/2011

Par Celinio FERNANDES (Autres articles)
 

Ce tutoriel a pour but de présenter le framework "MVP Places et Activités" qui a été intégré dans GWT à partir de la version 2.1.
Lors de la conférence Google Talk IO 2009, Ray Ryan a présenté les meilleures pratiques pour le développement GWT. Dans sa présentation, il décrit le pattern MVP et ses avantages : des tests plus faciles et une séparation plus claire de la logique de présentation.

I. Le modèle MVP
I.I Définition
I.II MVP vs MVC
II. La couche VUE
II.I Les vues
II.II Les places
II.II.I Définition
II.II.II Implémentation
II.II.II.a L'interface PlaceHistoryMapper
III. La couche PRESENTATEUR
III.I Les activités
III.I.I Définition
III.I.II Implémentation
IV. Client Factory
V. Le bus d'évènements (EventBus)
VI. ActivityManager
VII. ActivityMapper
VIII. Gestion de l'historique de navigation avec PlaceHistoryMapper
IX. Liens
X. Remerciements

I. Le modèle MVP


I.I Définition

Martin Fowler est à l'origine de ce pattern MVP. Après réflexion, il a décidé de décliner ce pattern en 2 versions :
- Supervising Controller
- Passive View

Pour résumer les choses très brièvement, dans MVP, le modèle ne communique pas avec la vue et la communication entre la vue et le présentateur est bi-directionelle c'est-à-dire que la vue communique avec le présentateur et le présentateur communique avec la vue.


Le modèle MVP implémenté dans GWT est plus ou moins inspiré de l'OS Androïd : on retrouve les notions de places (?) et d'activités.
Les vues sont des interfaces.
Il existe plusieurs autres frameworks GWT qui implémentent le pattern MVP. On peut citer :
  • GWT-Presenter
  • Mvp4g
  • Gwt-Platform
  • GWT-MPV
  • GWT-PECTIN
  • GUIT
  • xxx
  • xx
  • xx

    Trois concepts clés pour la mise en place du pattern MVP sont :
    • 1. Les vues (Views) sont des interfaces (de sorte qu'il soit possible de les tester sans GWTTestCase, parmi d'autres raisons).
    • 2. Les presentateurs sont des POJOs qui ne contiennent pas de Widgets.
    • 3. Les vues et les presentateurs font référence les uns aux autres à travers des interfaces uniquement. Cependant dans le style original de MVP, un présentateur peut appeler des méthodes de l'interface de la vue, mais pas l'inverse.

  • I.II MVP vs MVC

    xxxx

    II. La couche VUE


    II.I Les vues

    xxxx

    II.I Les places

    xxxx

    II.II.I Définition

    Une place dans GWT 2.1 est un objet Java représentant un état particulier de l'interface graphique.
    Elle correspond à une URL associée à une vue.

    II.II.II Implémentation

    Ces classes contiennent les informations concernant la navigation de l'application.
    Une place peut désigner un écran (écran de recherche par exemple) ou une "action", par exemple la modification d'un article avec la référence 123.
    Donc une place ne représente pas vraiment un écran mais où l'application est.
    Les liaisons entre les URLs et les places se font avec l'interface PlaceHistoryMapper
    Par exemple :
    /** * Déclaration de toutes les places disponibles dans l'application */ @WithTokenizers({ HomePlace.Tokenizer.class, ContactRechercherPlace.Tokenizer.class, ContactAjouterPlace.Tokenizer.class, ContactModifierPlace.Tokenizer.class }) public interface AppPlaceHistoryMapper extends PlaceHistoryMapper { ... }
    Une place hérite de la classe com.google.gwt.app.place.Place

    Une place est accessible à l'URL suivante :
    http://{nomDomaine}/#{nomPlace}:param
    Par exemple :
    http://localhost:8888/#ArticleEditPlace:Valise correspond à l'URL de l'edition de l'article Valise.


    II.II.II.a L'interface PlaceHistoryMapper

    Les places de l'application doivent être spécifiées dans l'interface com.google.gwt.place.shared.PlaceHistoryMapper à l'aide de l'annotation @WithTokenizers

    III. La couche PRESENTATEUR


    III.I Les activités

    Une activité a le rôle de présentateur.

    III.I.I Définition

    Les classes d'activité implémentent l'interface com.google.gwt.app.place.Activity

    III.I.II Implémentation

    La méthode start(AcceptsOneWidget containerWidget, EventBus eventBus) est invoqué par le manager d'activités.

    IV. Client Factory

    Cette classe fait en quelque sorte de l'injection de dépendance. Elle est chargée de fournir des instances d'objets tels que l'EventBus, le GWT PlaceController et les implémentations des vues.

    Todo: parler de Deferred Binding

    V. Le bus d'évènements (EventBus)

    L'EventBus met à jour l'ActivityManager.

    VI. ActivityManager

    http://google-web-toolkit.googlecode.com/svn/javadoc/2.1/com/google/gwt/activity/shared/ActivityManager.html

    VII. ActivityMapper

    http://google-web-toolkit.googlecode.com/svn/javadoc/2.2/com/google/gwt/activity/shared/ActivityMapper.html

    VIII. Gestion de l'historique de navigation avec PlaceHistoryMapper

    Notion d'history token. Il y a une place par défaut vers laquelle on est dirigé quand il n'y a pas d'history token dans l'URL.
    L'annotation @Prefix s'appuie sur History.newItem(java.lang.String).

    IX. Liens


    X. Remerciements

    Je tiens à remercier xxxx, yyyy pour les conseils, remarques et relectures, ainsi que RideKick pour la correction orthographique.
    Je remercie aussi www.developpez.com me permettant de publier cet article et Nono40 pour ses outils.

    ---------------------------------- A VOIR --------------------------
    http://gaegwtbestpractices.blogspot.com/2010/07/converting-to-mvp-architecture.html
    http://gwt.acrinta.com/
    https://github.com/ashtonthomas/gwt-seminar
    http://yuanatruntimeexception.blogspot.com/2010/10/gwt-21-rc-1-mvp-introduction.html
    http://code.google.com/webtoolkit/doc/trunk/tutorial/projects/hellomvp.zip
    http://tbroyer.posterous.com/
    http://tbroyer.posterous.com/gwt-21-activities
    http://stackoverflow.com/questions/5458442/how-can-i-use-the-new-gwt-mvp-framework
    http://www.david-ackerman.com/blog/2011/03/gwt-confusion/
    http://andyoid.com/?p=38
    http://feima2011.wordpress.com/2011/03/05/gwt/
    http://polyforms.org/architecture/new-mvp-in-gwt-2-1/
    http://code.google.com/webtoolkit/articles/mvp-architecture.html
    http://www.amateurinmotion.com/articles/2010/01/17/gwt-history-management.html
    
    http://nirajrules.wordpress.com/2009/07/18/mvc-vs-mvp-vs-mvvm/
    ---------------------------------
      
     im looking at the MVP example... they say to make your presenters implement an interface for handling clicks and so on from the view
     doesnt that completely go against "keep views dumb" ?
     ie. shouldnt the presenter get the actual view elements and register click handlers itself?
     
     i was wrong :P
    "This is fine for a simplistic view, but as soon as you start to do something more complex, you quickly realize that something has to give. 
    Either the presenter needs to know more about the view (making it hard to swap out views for other platforms), or the view needs to know more 
    about the data model (ultimately making your view smarter, thus requiring more GwtTestCases)."
    


    Copyright © Celinio FERNANDES. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à 3 ans de prison et jusqu'à 300 000 Euros de dommages et intérets.