web-dev-qa-db-fra.com

Vaadin 7: Utilisation de l'interface utilisateur vs Navigateur + Vues

Dans Vaadin 7, une application Web peut avoir plusieurs points d'entrée; les interfaces utilisateur. Chaque UI ne peut avoir qu'un seul Navigateur contenant Afficher s.

Nous travaillons sur une application qui nécessite une navigation à plusieurs niveaux, et pour certains écrans, nous ne savons pas si nous devons avoir une seule interface utilisateur avec un navigateur ou plusieurs interfaces utilisateur avec un composant de menu partagé.

Quels sont les avantages et les inconvénients de l'interface utilisateur et du navigateur? Existe-t-il des directives concernant ce choix?

vaadinvaadin7
30
cporte

Je recommande d'utiliser une interface utilisateur avec Navigator car à mon avis, c'est suffisant pour faire le travail. Le principal inconvénient de nombreuses interfaces utilisateur est le rechargement lors du basculement entre elles. Vous devez également vous souvenir de la cohérence souhaitée, par exemple. d'avoir le même en-tête dans chaque interface utilisateur. Et d'après mon expérience, vous rencontrerez certainement plus de problèmes ;-)

Pour le rendre propre, vous devez utiliser MVP patter . J'utilise similaire à celui-ci avec com.google.common.eventbus.EventBus pour gérer les événements. J'ajoute eventBus à mes vues, y poste des événements et les gère dans le présentateur approprié, sans implémenter d'écouteurs, ce qui, à mon avis, est plus problématique. Comme MVP réserve déjà 'présentateur' et 'voir' j'appelle Vaadin voir 'page'.

Vous pouvez créer un en-tête, un menu principal de pied de page, puis un conteneur de contenu (par exemple, une mise en page) pour câbler le navigateur avec:

Navigator n = new Navigator(UI.getCurrent(), layout);

Pour gérer la navigation, j'ai créé PagesEnum et lorsque je change de vue, je poste ChangePageEvent qui obtient PageEnum.SOME_PAGE comme paramètre. En option, il existe également un identifiant d'élément à afficher. Donc, dans MainPresenter, j'ai:

@Subscribe
public void changePage(ChangePageEvent event) {
    String url = event.getPageName();
    if (event.hasId()) {
        url += "/" + event.getEntityId();
    }
    navigator.navigateTo(url);
}

Ensuite, il existe différentes possibilités:

  • dans la méthode enter de la page (vue Vaadin), assurez-vous que le sous-menu approprié est affiché.

  • ajoutez-le en tant que paramètre à ChangePageEvent et gérez-le dans la méthode changePage.

  • codez-le en dur dans PageEnum comme nouveau champ, par exemple. subMenu et créez d'autres énumérations pour les sous-menus, modifiez-les dans la méthode changePage.

Le sous-menu sera probablement en dehors du conteneur avec lequel vous câblez Navigator, vous pouvez donc y créer SubMenuPresenter et SubMenuView pour gérer les modifications de sous-menu.

15
dzezzz

le sujet de votre question m'a beaucoup fait transpirer en 2013. J'ai étudié, analysé et testé divers aspects des interfaces utilisateur et du navigateur Vaadin 7.

J'ai regardé un grand nombre de framework, wiki et papier sur le sujet; liés et non liés à Vaadin 7.

C'était il y a quelque temps (début 2013), je ne suis pas frais sur le sujet; de toute façon, voici quelques-uns des liens que je suis en mesure de ressusciter:

Nos exigences étaient quelque peu similaires au scénario de Vaadin MVP Lite; mais nous avions besoin de plus d'abstraction et de flexibilité dans la composition des vues. J'ai fait de gros efforts pour utiliser le navigateur fourni, mais il n'était pas facilement personnalisable.

Navigator est une classe concrète. Les interfaces utilisateur ne peuvent avoir qu'un seul navigateur. Dans le constructeur Navigator, vous pouvez trouver cette ligne:

this.ui.setNavigator(this);

Navigator fait un excellent travail pour la plupart des applications avec des besoins simples et fournit des fonctionnalités intéressantes dès le départ, mais il n'est pas vraiment destiné à une extension ou à une personnalisation. Un autre aspect à garder à l'esprit est que lorsque vous changez de vue avec Navigator, vous changez tous les composants à l'écran; vous ne pouvez pas changer de petits morceaux.

Ensuite, j'ai trouvé ce guide qui m'a mis sur une route intéressante: Composition de l'interface utilisateur, Chapitre 7 - MSDN Microsoft

L'article est vraiment sympa et éclairant; bien qu'il ait de nombreux points communs avec la façon dont Delphi ou tout autre cadre basé sur des composants fonctionnent, le concept de "région" était vraiment une bénédiction. Les autres chapitres sont également très intéressants (Développement d'applications modulaires et MVVP).

Nous avons finalement adopté le concept de région avec une seule interface utilisateur. En bref, cela fonctionne comme ceci:

  • Il existe un composant GUI capable d'héberger d'autres composants; Les endroits où il peut héberger d'autres composants sont comme des "trous". Chaque trou est enregistré et il s'agit d'une région liée à un nom de chaîne (hasmap simple)
  • Grâce au nom de la région, on peut "mettre" un autre composant Vaadin dans une région afin de le rendre visible.

Ce qui se passe lorsque l'interface utilisateur est modifiée, c'est qu'une région est enregistrée (l'ensemble de l'interface utilisateur) en tant que région "racine". Ensuite, un composant qui représente le formulaire de connexion est hébergé dans la région "racine". Si une tentative de connexion réussie est effectuée, un autre composant est hébergé dans la région "racine" (suppression du composant de connexion); ce composant est également un hôte: il enregistre une autre région appelée "principale" et dispose également d'un menu de navigation sur le côté gauche. Maintenant, si l'on veut afficher un composant (la page d'accueil, par exemple), on peut récupérer la région "principale" et mettre le composant à afficher.

Vaadin Navigator implémente le bookmarking et le support du bouton retour. J'étais triste parce que nous ne l'avons pas développé mais ce n'était pas une exigence pour notre application. À mon humble avis, les gars de Vaadin ont pris une décision difficile mais bonne en gardant Navigator simple; la gestion de l'État n'est pas facile à mettre en œuvre. Ce serait bien pour l'avenir d'avoir un navigateur plus extensible. Quoi qu'il en soit, je pense que le navigateur actuel répond à la plupart des besoins moyens.

Ma réponse est plus longue que prévue; J'espère que mes efforts peuvent aider.

14
Jako