Discussion :

[abdou32]

Étant nouveau dans le domaine de la conception, j’ai besoin de votre aide pour la modélisation de mon projet. Donc, je dois modéliser un composant d’interface pour l’utiliser dans d’autres projets de développement …
Voici plus de détails sur le travail que je dois réaliser:

Composant Grid

Un tableau (grille) offrant plus de flexibilité.

Spécifications
1. Un tableau (grille) dont chaque cellule peut contenir un composant de l’un des types suivants :
a. Image
b. Checkbox
c. Bouton radio
d. Textbox (ce qui ajoute la possibilité de saisir)
e. Textarea (ce qui ajoute la possibilité de saisir)
f. Texte (libellé)
g. Bouton
h. URL
i. …

2. Les largeurs et hauteurs des cellules doivent pouvoir être manipulées par programmation
3. L’utilisateur doit pouvoir modifier la largeur des cellules avec la souris, ceci dans le but de permettre à l’utilisateur de modifier le visuel
4. Permettre de trier les colonnes. Les colonnes peuvent être triées ou non. Les accents doivent être pris en charge. Une option de tri client/serveur devra être offerte au programmeur.
5. Y ajouter une recherche, en entête. Les colonnes dans lesquelles la recherche sera possible apparaîtront dans une liste de critères. L’utilisateur aura le loisir d’inclure et d’exclure des critères à l’aide d’une grammaire du genre google. Il sera possible de choisir des plages de valeur («valeur entre X et Y ). La saisie d’un critère de recherche devra se faire en Ajax pour compléter les mots dans le cas de champs qui proviennent de la base de données. Des critères de recherche « custom » pourront être sauvegardés (très utile !).
6. Un « pager » pour naviguer dans de multiples pages sera offert en option. Il devra contenir les bouton premier, dernier, avance rapide, recul rapide, avance de un, recule de un, et un « goto no. de page ». L’avance et le recul rapides seront optionnels. L’avance rapide devra être paramétrable.
7. Les entêtes ne devront pas « scroller ». Les scrolls horizontal et vertical devront être paramétrables.
8. Les colonnes devront pouvoir s’ajuster (en largeur) soit au contenu, soit au libellé de la colonne, ou fixées par programmation.
9. Les colonnes devront pouvoir se regrouper (en arbre).
10. L’affichage des colonnes (quelle colonne est visible ou non) devra pouvoir être modifié par l’utilisateur.
11. La customisation d’une grille doit pouvoir être sauvegardée pour usage futur.
12. À la programmation, le développeur doit pouvoir obtenir des événements lors d’un changement de valeur d’une cellule.
13. Les lignes du tableau peuvent être sélectionnées et cette sélection doit être rendue disponible (multi-sélection optionnelle).


Si quelqu’un pouvait m’aider, je lui en serais très reconnaissant. Le but n’est évidemment pas de faire ce travail à ma place, mais d’essayer de me faire comprendre comment je peux modéliser ce composant et quels design patterns a utilisé?

Merci d’avance!

[wiztricks]

Il n'y a rien à comprendre ou à modéliser: ce sont les spécifications des possibilités techniques d'une IHM.
Reste à trouver dans les produits existants ceux qui remplissent ces fonctions et voir laquelle est la plus adaptée en fonction des savoirs faire locaux.

Il y a aujourd'hui au moins 3 sortes d'IHM qui permettent de réaliser cela:

1- RDA : on prend Eclipse ou Netbeans et l'application est intégrée via plugins en utilisant les fonctionnalités offertes par ces outils.

2- RIA : Flex, Silverlight, Ajax,... le browser telécharge et interpréte

3- Client lourd : n'importe quel GUI - GTK, QT,... - qui s'interface avec la persistance via XMLHTTPRequest.

1 & 3 sont similaires au sens ou beaucoup d'intelligence est dans le poste de travail. Ils sont différents car ils ne permettent pas le même type de déploiement des mises a jour et des nouvelles applications (1 est proche de 2)
RDA et client lourd disposent d'un potentiel d'autonomie locale qui pourrait être utile dans des applications de nomadisme ou de travail en mode non connecté. RIA aussi mais je trouve que ce n'est pas 'builtins', naturel dans l'approche proposée.

Dans tous les cas, pensez applications construites à partir de services offerts par des serveurs WEB: L'IHM utilisera dans ce cas, une API homogène pour s'interfacer avec le reste du monde.
-W

[abdou32]

Salut wiztricks et merci de ta réponse,

C’est vrai que c’est des spécifications des possibilités techniques d'une IHM et peut-être dans mon premier envoi je n’ai pas bien expliqué mon besoin,

Donc le besoin et le suivant :

Ce qui m’a été demander de faire et de modéliser et développer ce composant d’interface avec le framework GWT sans utiliser aucune librairie externe et avec utilisation de « patterns ».

Je veux vraiment savoir quels patterns à utiliser pour faire la modélisation de ce composant d’interface?

Merci !

[wiztricks]

GWT est un framework qui permet de developper une webapp sur un modele Widget plutôt que cheminement dans une suite d'écrans (à la Struts).
Les deux frameworks sont construits sur le pattern MVC (Model View Controller).

Il y a pas mal de littérature sur MVC avec GUI style Widget sur Spring (voir google). Ils devraient permettre de positionner les différents composants de GWT si tant est que celui si soit conforme à un pattern particulier (ca discutaille entre MVC, PAC et HMVC)
PAC = Presentation-Abstraction-Control il permet aussi de hiérarchiser.

D'après ce que je comprends, vous devez réaliser des interfaces qui vont permettre de construire la View, le Model, le Controller.
Les patterns 'générique' pour les interfaces sont adapter, wrapper, proxy, facade.

Exemple: 'Checkbox' existe sans doute dans GWT une composante View (le contenu qui est affiché) et une partir controller puisqu'il faudra prendre en compte les case qui ont été cochées.
Est ce que vous pouvez l'utiliser tel que? Faut-il "habiller" la CheckBox de Google pour... Est ce que l'habillage peut se traiter sous forme d'un simple héritage ou doit s'interfacer de façon plus souple (grâce aux patterns précédents).

Cela étant, il y a beaucoup d'exigences qui optent pour des fonctionnalités assez spécifiques, i.e. on veut bien travailler avec GWT mais pas faire n'importe quoi: elles ferment l'API de GWT.
Exemple: L’utilisateur doit pouvoir modifier la largeur des cellules avec la souris, ceci dans le but de permettre à l’utilisateur de modifier le visuel

l'exigence "6. Un « pager » pour naviguer dans de multiples pages sera offert en option. Il devra contenir les bouton premier, dernier, avance rapide, recul rapide, avance de un, recule de un, et un « goto no. de page ». L’avance et le recul rapides seront optionnels. L’avance rapide devra être paramétrable." est délicieuse!
Car nous y trouvons Model, View, Controller tout à la fois. Et des possibilités qui débordent de celles de GWT puisque pour que ça fonctionne, il faudra faire in fine des requêtes à la base: il faut donc créer et gérer un "contexte" au niveau de la session pour savoir où on en.
Et l'interface à la base doit être 'ouvert' => peut importe qu'entre l'IHM il y ait un ORM, un driver ODBC,.. D'autant que GWT ne va produire (à ma connaissance) que des requêtes HTTP avec du XML dedans.
Essayez de fermer un peu tout çà (préciser les limites de ce que fait ou pas l'iHM)
Bon courage
- W