Tutoriel : UiBinder et le design pattern MVPObjectifCréer des vues avec UiBinder tout en respectant l'architecture du design pattern MVP. IntroductionUiBinderIl existe deux manières d'implémenter une interface graphique pour GWT. Voyons ensemble ces deux méthodes qui nous permettront de construire l'écran ci-dessous.
La première est similaire à la construction d'un écran en SWING : on modélise l'ensemble des composants de l'écran à partir de classes Java, puis on rattache ces composants entre eux en respectant la hiérarchie des conteneurs/contenus. Ci-dessous le code GWT permettant de construire la vue : Panel mainPanel = new FlowPanel();
Label label = new Label("Hey! How are you ?");
label.getStyle().setFontWeight("bold");
mainPanel.add(label);
Button button = new Button("I'm fine, thanks!");
mainPanel.add(button);Cette méthode peut paraître simple aux premiers abords, cependant elle présente plusieurs inconvénients sur des écrans plus complexes :
Ce dernier point est selon moi un gros handicap dans le développement d'une application GWT professionelle par une équipe composée de développeurs et de designers. Heureusement une seconde méthode appelée UiBinder permet de créer des écrans sans rencontrer les problèmes évoqués ci-dessus. Dans les grandes lignes, UiBinder sépare la construction de l'écran en deux fichiers distincts :
Voici le code de la partie statique de la vue en UiBinder : <div> <label style="font-weight: bold;">Hey! How are you ?</label> <g:Button>I'm fine, thanks!</g:Button> </div> Contrairement à l'implémentation de l'écran en Java on identifie facilement chaque composant, le passage par des Panel n'est plus indispensable car l'écran est agencé en XHTML et tous les composants dans le code seront obligatoirement affichés (pas d'oublis). UiBinder est bel et bien adapté à des applications qui souhaitent se doter d'une interface graphique propre et maintenable. Pour de plus amples informations sur UiBinder, je vous recommande de vous référencer à la documentation officielle fournie par Google : http://code.google.com/intl/fr-FR/webtoolkit/doc/latest/DevGuideUiBinder.html Le design pattern MVPLe design pattern MVP (Model View Presenter) est un cousin du design pattern MVC (Model View Controller). Ces trois éléments forment un groupe dédié à la gestion d'un écran (affichage, dynamisme, liens vers les autres écrans, etc...). Chacun des éléments a un rôle bien distinct :
La principale différence du pattern MVP avec le pattern MVC se situe au niveau du Model : celui-ci n'est connu que du Presenter dans le MVP, contrairement au MVC où le Controller et la View manipulent le Model. Dans le MVP, notre View se cantonne à son rôle de vue, c'est à dire afficher des données simples à l'écran (Integer, String, etc...), et elle ne dépend pas du Model. Le Presenter se charge alors de faire le lien entre le Model et les composants de la vue. Voici un schéma illustrant cette différence :
Plusieurs frameworks adaptés à GWT proposent de faire du MVP. Le projet Niiuzu se base sur le framework Mvp4g (cf. lien officiel Mvp4g). Création d'un nouvel écranPour créer un écran en MVP avec une vue en UiBinder, nous avons besoin de quatre fichiers :
Le PresenterIl jouera le rôle du maître d'orchestre de l'écran et sera responsable de tout le dynamisme de l'écran. Voici les fonctions qu'il aura à remplir :
Dans Mvp4g, il devra implémenter BasePresenter (cf. Javadoc Mvp4g) et être rattaché à l'interface de la vue et à son implémentation Java. Les liens avec les autres écrans seront possibles grâce à l'EventBus de Mvp4g. Interface de la vueLe seul intérêt de l'interface est de filtrer les accesseurs de la vue. En effet il est tout à fait possible de manipuler la vue dans le presenter directement à partir de la partie Java de l'implémentation de la vue (MyViewImpl.java). Or cette implémentation étendra la classe GWT Composite qui donnera accès à toutes les méthodes de la classe qu'elle étend (Widget, Composite, ...). Voici un exemple qui illustre ce problème. Soit une interface IView et une implémentation de vue ViewImpl : public interface IView {
void myMethod();
}
public class ViewImpl extends Widget implements IView {
@Override
public void myMethod() { /* nothing! */ }
}Le Presenter qui connaitra l'implémentation de la vue ViewImpl aura accès à la méthode myMethod ainsi qu'à toutes les méthodes de la classe Widget. En revanche le presenter qui ne connaitra que l'interface de la vue IView n'aura accès qu'à la méthode myMethod. Notre interface sert en quelques sortes de masque. Concrétement ce masque nous évite de retrouver des view.addStyleName("style") ou encore des view.setWidget(widget) qui ne respectent pas l'architecture mise en place. Implémentation de la vue, partie JavaLe but principal de la partie Java de la vue est de donner l'accès aux composants de la vue. Idéalement ces composants seront accessibles aux travers d'interfaces fournies par GWT telles que :
Ci-dessous un exemple d'accesseur présent dans la partie java de l'implémentation de la vue. On cherche ici à donner accès au composant contenant la valeur saisie par l'utilisateur. Le Presenter a besoin de récupérer et éditer la valeur à partir d'un HasValue, dans l'implémentation de la vue le composant est une Textbox. @UiField
private Textbox nameTextbox;
@Override
public HasValue<String> getNameHasValue() {
return nameTextbox;
}La javadoc de GWT est un excellent moyen de connaître les implémentations de chaque composant (cf. Javadoc GWT). Implémentation de la vue, partie XMLCe fichier XML contient la structure de l'écran, les composants manipulés par le Presenter, ainsi que le style CSS. Exemple dans Niiuzu
Références |
Super Tuto !
Bon tuto pour commencer et apprendre les bases du mvp
c'est une bonne Tuto merci