Discussion :

[thomine]

Bonjour,

Je m'intéresse à GWT. L'utiliser modifie la manière de gérer les interfaces graphiques puisqu'il fonctionne sur le mode de la programmation évènementielle.

Pour illustrer la question que je me pose, partant d'un exemple simple : la gestion d'une liste de clients (affichage de la liste des clients, ajout, modification, suppression). Cette liste peut être modifiée par plusieurs utilisateurs simultanément.

En programmation web non évènementielle, à chaque fois qu'on modifie la liste, on recharge tous les éléments pour réafficher la liste. Je suis donc toujours "à jour" par rapport à la base de données.

En programmation évènementielle, si j'ajoute un élément, je vais appeler ma couche métier pour lui notifier de l'ajout et ajouter l'élément à ma liste au niveau de l'affichage. D'une certaine manière, mon affichage va évoluer en parallèle des informations persistées. N'est ce pas gênant ? Je ne verrai par exemple pas les ajouts / modifications / suppressions faits par les autres utilisateurs.

Je me fais peut-être beaucoup de nœuds au cerveau pour pas grand chose, mais :
Existe-il des bonnes pratiques sur la manière de gérer l'affichage par rapport à la partie métier / persistance ?

J'espère avoir été clair. Par avance, merci pour vos réponses.

[hegros]

Bonsoir

une bonne pratique pour la couche présentation c'est d'utiliser le pattern observateur.

[thomine]

Bonsoir,

Merci hegros pour ta réponse.
Si je te comprends bien (et pour conserver l'indépendance de la couche métier par rapport à la couche présentation), mes services métiers doivent implémenter une interface (ou classe abstraite) Observable.
Quand j'ajoute un client, ma couche présentation appelle explicitement le service métier correspondant. Le service métier notifie alors tous les observateurs qu'un client a été ajouté.
Ai-je bien compris ?

Merci !

[hegros]

oui observable ou subject, il y a une documentation abondante sur le sujet sur le site avec des exemples

[souviron34]

Je m'intéresse à GWT. L'utiliser modifie la manière de gérer les interfaces graphiques puisqu'il fonctionne sur le mode de la programmation évènementielle.

Le principe des interfaces graphiques depuis 30 ans est d'être événementiel !!!!

En programmation web non évènementielle, à chaque fois qu'on modifie la liste, on recharge tous les éléments pour réafficher la liste. Je suis donc toujours "à jour" par rapport à la base de données.

Ce qui est normal, puisque basé sur un protocole (HTML) et non une IHM "normale", c'est à dire événementielle

Pour illustrer la question que je me pose, partant d'un exemple simple : la gestion d'une liste de clients (affichage de la liste des clients, ajout, modification, suppression). Cette liste peut être modifiée par plusieurs utilisateurs simultanément.


En programmation évènementielle, si j'ajoute un élément, je vais appeler ma couche métier pour lui notifier de l'ajout et ajouter l'élément à ma liste au niveau de l'affichage. D'une certaine manière, mon affichage va évoluer en parallèle des informations persistées. N'est ce pas gênant ? Je ne verrai par exemple pas les ajouts / modifications / suppressions faits par les autres utilisateurs.

Je me fais peut-être beaucoup de nœuds au cerveau pour pas grand chose, mais :
Existe-il des bonnes pratiques sur la manière de gérer l'affichage par rapport à la partie métier / persistance ?

J'espère avoir été clair. Par avance, merci pour vos réponses.

Bonsoir,

Merci hegros pour ta réponse.
Si je te comprends bien (et pour conserver l'indépendance de la couche métier par rapport à la couche présentation), mes services métiers doivent implémenter une interface (ou classe abstraite) Observable.
Quand j'ajoute un client, ma couche présentation appelle explicitement le service métier correspondant. Le service métier notifie alors tous les observateurs qu'un client a été ajouté.
Ai-je bien compris ?

Merci !

Tout ceci relève d'une vision "objet" de base..

Chaque utilisateur possède une "vue" sur la base.

Un élément - physique - dans la base n'a qu'un seul état à un moment donné : il n'existe pas (on le crée), il existe (on le voit), il a été modifié, il a été détruit.

Ces 4 opérations sont "en bas" de l'échelle, ce sont celles de la base.

Un utilisateur peut faire ce qu'il veut (si bien sûr il a les droits).

Une appli à un utilisateur, bien conçue, aura été découpée entre BDD, métier, et IHM.

Comme dit plus haut, normalement les IHM fonctionnent sur le principe de l'événementiel. Il y aura donc des "méthodes" Get, View, Modify, Destroy, Create.

MAIS dès que l'on est à plusieurs, les "méthodes" Modify, Destroy, Create nécessitent d'avoir des répercussions en temps réel vers les autres utilisateurs, de même que des mécanismes de synchronisation.

Dans ce cas-là, il y aura simultanément un dialogue Aller-retour vers la base, plus un "broadcast".

Et c'est un avantage certain, comme tu le mentionnes : à quoi ça sert de modifier un élément qui a été détruit par quelqu'un d'autre ?

En conséquence, dans ce genre de schémas, il y a un double étage d'événementiel : au niveau de l'IHM, et au niveau de la BD.

Le fond de tout est de bien séparer les couches, et d'avoir un dialogue cohérent.

[thomine]

Merci pour vos réponses.

Ce qui est normal, puisque basé sur un protocole (HTML) et non une IHM "normale", c'est à dire événementielle

D'où ma question ! Etant surtout habitué au web, je n'ai pas les bons réflexes IHM normale (événementielle quoi !) . Il n'y a (le plus souvent) pas cette notification de changement du modèle à la vue.

Comme dit plus haut, normalement les IHM fonctionnent sur le principe de l'événementiel. Il y aura donc des "méthodes" Get, View, Modify, Destroy, Create.

MAIS dès que l'on est à plusieurs, les "méthodes" Modify, Destroy, Create nécessitent d'avoir des répercussions en temps réel vers les autres utilisateurs, de même que des mécanismes de synchronisation.

Dans ce cas-là, il y aura simultanément un dialogue Aller-retour vers la base, plus un "broadcast".

C'était là le coeur de ma question, donc merci pour ta réponse ! Par rapport à une appli basée sur HTTP simple, je m'interrogeais sur cette synchronisation et cette répercussion en temps réel des infos.
Je comprends maintenant mieux comment est géré ce "broadcast" d'infos à partir du DP Observer.

Le sujet est pour moi résolu ! Merci pour vos contributions.

[hegros]

oui observer est utilisable à différent niveau.

presentation->application

mais aussi on pourrait l'utiliser comme cela

application->couche accès aux données


Soit une notification dans la couche des données notifie l'application qui notifie la présentation and continue...