Modele-Vue-Controleur sur une structure déjà existante sans être intrusif

**TanEk** · 08/12/2008, 22h22

Bonjour,

Je suis actuellement en train de développer un éditeur pour une structure appelée maillage en demi-arête. Je ne vais pas m'attarder sur la structure elle-même. Je pense avoir à peu prêt saisie la notion de modèle-vue-contrôleur mais je n'arrive pas à la mettre en oeuvre dans une structure déjà existante sans être intrusif.

J'ai défini ma structure en demi-arête en arbre telle que suit :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
triangle 1
   half-edge 1
      sommet
   half-edge 2
      sommet
   half-edge 3
      sommet
triangle 2
   half-edge 1
       sommet
   half-edge 2
       sommet
etc.

Voici maintenant le problème que je me pose : ma structure existe déjà et est plutôt un graphe. Ensuite les éléments de l'arbre n'ont rien en commun (des types complètement différents, ils n'ont pas une classe mère commune). Hors dans les exemples fournis sur le net on parle toujours d'un TreeItem et on peut avoir certains noeuds spécialisés mais ils sont quand même des TreeItem par héritage. J'en viens maintenant à mon problème, je dois hériter de cette méthode :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
virtual QModelIndex index ( int row, int column, const QModelIndex & parent = QModelIndex() ) const = 0

pour définir mon modèle. Voici maintenant ma question : comment je fais pour lier ma structure déjà existante à mon modèle ? Si je mets de simples pointeurs (qui seront envoyés au QModelIndex et récupérables avec la méthode internalPointer) vers mes objets je n'ai pas assez d'informations pour trouver le fils connaissant l'index. En effet, comme les types sont complètement différents, si je récupère le pointeur, je ne saurais pas quel type d'objet c'est et donc connaître ses fils.

Je me demande si je ne devrais pas utiliser les rtti seulement les rtti ne doivent pas être utilisés avec des classes ayant au moins une méthode virtuelle ? Et si possible j'aimerai éviter cela.

Si vous avez des suggestions.

Merci d'avance.

**yan** · 08/12/2008, 22h58

Salut

Envoyé par TanEk

Ensuite les éléments de l'arbre n'ont rien en commun (des types complètement différents, ils n'ont pas une classe mère commune)

j'ai pas bien compris cela.
Tu as quand même une structure? S'ils n'ont rien en commun, comment fait tu la différence entre les noeuds et les feuilles?

**TanEk** · 08/12/2008, 23h47

Et bien en gros j'ai ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
 
struct MeshHalfEdge
{
     vector<Face> faces;
};
 
struct Face
{
    HalfEdge halfEdge;
};
 
struct HalfEdge
{
   Face face;
   Sommet sommet;
   HalfEdge next; // prochain
   HalfEdge sym; // Half-Edge Symétrique
};
 
struct Sommet
{
   float x, y, z;
   HalfEdge halfEdge;
};

Pour plus de détails voir : http://www.flipcode.com/archives/The...tructure.shtml. Donc ils n'ont pas de classe mère commune. Tu penses que je devrais rajouter une surcouche genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
class Node
{
public
    Node* getParent(void);
    Node* getChild(int index);
    int getChildCount(void);
};

Comme ceci dans ma structure Half-Edge et ensuite utiliser ceci pour les introduire dans mon modèle d'arbre ? Le truc c'est qu'en faisant ça je rend mes structures polymorphiques et elles deviennent beaucoup plus grosses en mémoire (on peut avoir des meshs à plusieurs millions de vertices).

**yan** · 09/12/2008, 09h23

Envoyé par TanEk

Tu penses que je devrais rajouter une surcouche genre :

Vue que tout est typé, je dirait que non. Au cas ou, Tu devrais quand même demander conseil sur le forum C++ (si tu ne la pas encore fait).
par contre que face contient HalfEdge et HalfEdge contient face ça me parait étrange mais cela correspond a ton article.

Le mieux que tu puisse faire, c'est de te baser sur cette exemple
http://qt.developpez.com/doc/4.4/ite...mpletreemodel/

En suite tu as un treeitem en class mère et:
spécialisation pour
MeshHalfEdge
Face
Sommet

Le seul intérêt de treeitem est de fournir les information pour un noeud de l'arbre. Après y as surement une gestion mémoire à prévoir pour ne pas tout allouer d'un coup.

Dans le principe du model-vue-controleur, l'ihm n'est qu'une vue et ton coeur métier ne doit en aucun cas connaitre ses contraintes. En gros :
model : le coeur de ton application
vue : ihm
controleur : passerelle entre les deux.

En gros, il faut au maximum séparer les chose pour pouvoir facilement passé de Qt à un autre lib comme gtk.

Par contre rien ne t'empêche que ton cœur soit basé sur Qt puisse que Qt fait plus que de l'ihm

je ne sait si je suis claire

[edit]
Le problème de cette structure est qu'il est assez difficile de maintenir tout les liens entre eux. Tu devrait regarder ce tuto qui te simplifiera cette tache
http://loic-joly.developpez.com/tuto...mart-pointers/
A voir si cela ne te rajoutera pas trop de mémoire
Au faite, tu devrais regarder CGAL. Ils ont peut être une classe basée sur cette structure :
http://www.cgal.org/Manual/3.3/doc_h...pter_main.html
http://www.cgal.org/Manual/3.3/doc_h...nk_anchor_1113

**epsilon68** · 09/12/2008, 09h58

tu peux faire des dynamics cast et voir si ca te retourne different de 0 ...
dans ton cas je ne vois guere plus malheureusement.

mais tu peux encapsuler avec un truc du genre:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 
 
class BetterAccess
{
  BetterAccess( void * rawptr ) {  init }
 
  // plein de dynamic cast
  bool isTriangle();
  bool isHalfSpace();
 
  Triangle* triangle() // null si c'est pas un triangle.
 
  void* getChild(int it) {
    if( isTriangle() ) {
       Triangle * mytriangle = triangle();
       return mytriangle->getHalfSpace(i) etc etc etc
    }
    else if( etc etc
  }
}

c'est finalement pas si sale que ca non?

a+

**TanEk** · 09/12/2008, 13h22

Je vous remercie pour vos propositions, je vais demander l'avis sur le forum C++ mais pour le moment je pars sur ce que j'ai dis plus haut (pour Mongaulois : ça revient à ta proposition de faire un TReeItem et de dériver : Node <=> TreeItem).

**epsilon68** · 09/12/2008, 13h31

tu aurais bien tort de faire cela.
tu maintiendras 2 structures (en gros) juste pour faire l'IHM...

Le model a été introduit pour justement abstraire le model, pas la peine d'en refaire un, surtout que tu l'as.

je peux te parler de mon cas, ou j'avais un arbre dans ma DB (Sqlite). J'avais donc developpé une structure que je chargeais au début... Au bout d'un moment, maintenir l'état de mon arbre et de la DB synchro était devenu super lourd !

J'ai tout cassé et maintenant mon model, c'est la DB. Je fais des requetes directes... et c'est vraiment génial, le code s'est tellement simplifié, tu n'as meme pas idée.

... de toute facon c'est à toi de voir.

voila a+

**yan** · 09/12/2008, 14h00

Envoyé par epsilon68

tu aurais bien tort de faire cela.
tu maintiendras 2 structures (en gros) juste pour faire l'IHM...

Le model a été introduit pour justement abstraire le model, pas la peine d'en refaire un, surtout que tu l'as.

En faite, on sait peut être pas compris.
Ce que je dit, c'est qu'il faut séparer son code métier de l'ihm. Si on mélange le traitement avec l'ihm en générale on pleure au bout de quelque temps.
Bien sure, ce n'est pas une généralité.
Par exemple, si son code est une lib qui peut être exploité dans un exe console et qu'il as commencé à tout mélangé (ihm et code métier) ben il se retrouve à tout refaire.
Le model-vue-controleur sert à séparer le code métier de l'ihm. Après y as plusieurs façon.
* Celle que tu as fait où le model accède directement au code métier (DB)
* Celle que je propose : le model accède au code métier au travers des Treeitem. Un treeitem est simplement une interface qui va permettre d'interfacer ses class. Je vais essayer de faire un exemple.
* d'autre que je ne voie pas.

Dans son cas, utiliser ta méthode me semble plus risqué car il doit faire des testes de tout les coté, savoir si ce qu'il doit donner comme data est une face ou un segment ou ....

Au final, ce ne sont que des conseils. C'est difficile de généraliser et cela dépend de ce qu'il veut faire.

**epsilon68** · 09/12/2008, 14h37

on a un MODEL dans Qt pour deja abstraire les données,
donc le code pour modifier ta structure métier n'est donc pas melangé au TreeItemWidget* (details implementation)

donc que tu re-fasses un tree pour l'IHM est un non-sense, une reelle perte de temps.

que tu castes dans un objet qui te facilite l'acces (comme rapidement decrit dans mon precedent post) tu evites tout ce travail.

tu te rends compte de l'effort pour maintenir l'arbre métier plus l'arbre IHM (TreeNode)? et quand tu fais la modif dans l'un ? tu le repercutes comment ? et surtout avec quelle facilité?

non decidement, j'en ai aussi fait l'experience et j'ai compris. Ne pas dupliquer les infos, c'est un point crucial.

**HanLee** · 09/12/2008, 14h38

Envoyé par TanEk

Pour plus de détails voir : http://www.flipcode.com/archives/The...tructure.shtml. Donc ils n'ont pas de classe mère commune. Tu penses que je devrais rajouter une surcouche genre :

L'article indique juste comment est implémentée la structure de données, mais pas comment modifier, construire un maillage à l'aide de cette structure de données.

Le lien vers Stanford est mort. Ca m'intéresse, parce que c'est plus compliqué qu'on le croit.

Lire des informations sur un half edge est simple, mais construire l'information c'est pas évident.

Les seules publications exhaustives que je connais sont payantes...

**yan** · 09/12/2008, 14h55

Envoyé par epsilon68

on a un MODEL dans Qt pour deja abstraire les données,
donc le code pour modifier ta structure métier n'est donc pas melangé au TreeItemWidget* (details implementation)

TreeItemWidget??
on parle pas de la même chose alors.
Ma solution se base sur QTreeView et une redéfinition de ton propre model.

que tu castes dans un objet qui te facilite l'accès (comme rapidement decrit dans mon precedent post) tu évites tout ce travail.

ce dont je parle reviens à peu prés au même et cela sans modifier le code métier. Au lieu de caster, j'utilise le polymorphisme.

tu te rends compte de l'effort pour maintenir l'arbre métier plus l'arbre IHM (TreeNode)?et quand tu fais la modif dans l'un ? tu le repercutes comment ? et surtout avec quelle facilité?

Si l'ihm ne reste qu'une vue de ton arbre, tu n'as pas de doublon et ils sont donc synchronisé.

Je met au propre ce que j'ai fait et je le poste. Cela sera beaucoup plus simple. A mon avis on parle de deux choses différentes.

**yan** · 09/12/2008, 14h57

Envoyé par HanLee

Lire des informations sur un half edge est simple, mais construire l'information c'est pas évident.

Les seules publications exhaustives que je connais sont payantes...

GTS est sur le même principe mais c'est du C. Tu trouvera peut être des chose intéressante :
http://gts.sourceforge.net/biblio.html

Il n'y as pas de publication lié à CGAL?

**epsilon68** · 09/12/2008, 15h05

Envoyé par Mongaulois

TreeItemWidget??
on parle pas de la même chose alors.
Ma solution se base sur QTreeView et une redéfinition de ton propre model.

Je me referais au fait que Qt faisait deja l'abstraction avec l'IHM, pas comme en VB ou meme en .NET ou on est obligé de synchroniser a la main l'arbre avec des TreeItemWidget *** j'ai juste inventé ce mot

je vois ce que tu veux faire, enfin je pense. Tu veux refaire une structure dont les noeuds contiennent les noeud du model métier. Confirmes moi mais je pense.

et la je dis que tu fais erreur parce qu'il faudra les synchroniser apres, et ... les maintenir.

**yan** · 09/12/2008, 15h18

Envoyé par epsilon68

je vois ce que tu veux faire, enfin je pense. Tu veux refaire une structure dont les noeuds contiennent les noeud du model métier. Confirmes moi mais je pense.

Ce sont plutôt des interfaces qui traduisent les informations de la class du code métier en ce que l'on veut afficher.

Envoyé par epsilon68

et la je dis que tu fais erreur parce qu'il faudra les synchroniser apres, et ... les maintenir.

...Sur le principe, si tu détruit un élément, ça doit le détruire dans le code métier. Après, c'est juste une traduction des informations vers l'ihm.
J'ai du mal à comprendre ce que tu reproche. Comment ferais tu?

**yan** · 09/12/2008, 15h46

Envoyé par Mongaulois

J'ai du mal à comprendre ce que tu reproche. Comment ferais tu?

T'as peut être raison... je commence à tout mélanger.
Du coup je ne voie comment tu ferais...

**epsilon68** · 09/12/2008, 15h51

bein faire une structure a part, il faut gerer le fait de la synchroniser si tu detruit (ou change ou deplace) un element de ton arbre metier (à repercuter dans ton arbre IHM) et vice-versa.

de plus tu consommes de la memoire inutilement (un autre debat peut-etre)

donc pour synchroniser les 2 arbres, il faut donc surement mettre en place le systeme signal-slot non? donc deriver tes objets metiers de QObject (de la memoire en plus encore) ou utiliser boost::signal mais ca consomme aussi de la memoire pour chaque signal.

a la fin, tu as un systeme super lourd, pour avoir finalement dupliqué tes informations

ce que tu as juste besoin finalement est une petite classe utilitaire (pas de new, pas d'heritage etc) qui essaie de reconnaitre les objects et te donner le fils à telle position et le nom de cet objet
comme celle que j'ai ecrite avant:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
 
class BetterAccess
{
  BetterAccess( void * rawptr ) {  init }
 
  // plein de dynamic cast
  bool isTriangle(); // dedans un dynamic cast
  bool isHalfSpace(); // dedans un dynamic cast
 
  Triangle* triangle() // null si c'est pas un triangle.
 
  QString name() ; // aussi des if en fonction de l'objet comme ci-dessous
 
  void* getChild(int it) {
    if( isTriangle() ) {
       Triangle * mytriangle = triangle();
       return mytriangle->getHalfSpace(i) etc etc etc
    }
    else if( etc etc
  }
}

**yan** · 09/12/2008, 16h15

ce que tu as juste besoin finalement est une petite classe utilitaire (pas de new, pas d'heritage etc) qui essaie de reconnaitre les objects et te donner le fils à telle position et le nom de cet objet
comme celle que j'ai ecrite avant:

On peut faire un dynamic_cast sur du void *?
Comment tu associe ton QModelIndex avec une class?
Par exemple je click sur un élément de l'arbre de trois niveau. Comment je peut accéder facilement à l'information?

T'as raison pour la duplication de l'arbre,c'est plus ou moins ce qui se passe. mais je ne voie pas comment t'as méthode ressoud le problème

Voici de la doc sur la création d'un model:
http://qt.developpez.com/doc/4.4/mod...eating-models/

**epsilon68** · 09/12/2008, 17h01

pourquoi le dynamic_cast ne marcherait pas?

QModelIndex contient un void* pointer ou un int,
donc tu peux associer un pointer vers ton objet ou un id qui te permettra de le retrouver.

quand tu click sur un noeud, tu auras le pointer (internal pointer) donc avec la class (BetterAcces) tu pourras faire des if (isTriangle, isHalfEdge etc) et avoir le bon pointer vers ton objet.

merci pour dire que j'avais raison, ca fait chaud au coeur

ma methode evite simplement la duplication, puisque l'arbre metier est derriere. J'ai juste fait un proxy vers les vrais objets.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
 
void* internalptr = mymodelindex.internalPointer();
BetterAccess proxy (internalptr);
 
if (proxy.isTriangle()) {
  // faire des choses avec le triangles etc
}
else if ( ... ) {
}

**yan** · 09/12/2008, 17h20

Envoyé par epsilon68

pourquoi le dynamic_cast ne marcherait pas?

a ma connaissance, ça marche pas. void* n'est pas typé.

Envoyé par epsilon68

ma méthode evite simplement la duplication, puisque l'arbre métier est derrière. J'ai juste fait un proxy vers les vrais objets.

comment tu créé ton arbre affiché???
comment tu donne le pointeur à QModelIndex????

**epsilon68** · 09/12/2008, 17h38

Envoyé par Mongaulois

a ma connaissance, ça marche pas. void* n'est pas typé.

<WRONG>a ma connaissance ca marche</WRONG>
EDIT: ha non t'as raison, alors on peut utiliser le typeid non? et puis faire un static_cast

Envoyé par Mongaulois

comment tu créé ton arbre affiché???
comment tu donne le pointeur à QModelIndex????

hum je crois que tu n'as pas essayé de faire un model pour un tree, ai-je raison?

la personne à l'origine de ce post a donné sa structure de donnée au début,
et c'est un arbre. c'est facile de parcourir cet arbre, c'est facile de donner des pointers, c'est facile de recuperer les enfants du noeud puisqu'on a toujours le pointer dans le QModelIndex.

Modele-Vue-Controleur sur une structure déjà existante sans être intrusif

Qt

Discussions similaires

Partager

Partager