QTableModel contenant des objets de différents types

Bonjour,

Je me tourne vers vous pour vous demander conseil. Disons que j'ai plus ou moins une solution fonctionnelle, mais je veux votre avis. Il n'y a pas vraiment de question que je vais poser, mais une étude de cas que je vais vous exposer et j’espère avoir vos commentaires.

Problématique :
Je dispose de données hétérogènes. Ces données possèdent certains attributs en commun, mais, selon leurs types, peuvent avoir des attributs différents.

L'idée est de pouvoir afficher les attributs en commun dans une qtableview, et que une fois l'utilisateur sélectionne une ligne, l'interface offre les widgets nécessaires à l'affichage des attributs spécifiques.

Ci-joins deux maquettes qui montreront je l’espère un peu plus le rendu souhaité.

Solution réalisé :

• Une classe abstraite contient les attributs communs (hérite de QObject).

• Les classes filles de cette classe héritent de la classe abstraite, et ajoute leurs attributs spécifiques.

• J'hérite de QAbstractTableModel, crée une QList de pointeurs sur la classe abstraite, et définit la méthode data pour qu'elle ne retourne que les attributs en commun.

• Un QTableView se charge d'afficher ce modèle personnalisé.

Maintenant je pense faire un QStackedWidget, contenant les différentes UI des différents types. La classe abstraite possède une méthode getType redéfinie par les classes filles pour retourner le type de l'objet. Le slot on_tableView_clicked se charge de pointer vers le bon widget du QStackedWidget et rempli les différents champs à partir d'un qobject_cast() fait sur l'objet sélectionné.

Questions en vrac :

1. Que pensez-vous de cette façon de faire?
2. La classe QDataWidgetMapper serait-elle utile pour remplir les différents champs spécifique ?

Merci pour votre aide.

Bonjour,

J'ai eu un peu de mal à comprendre, mais la solution ne me semble pas mal.
Vous pouvez faire une zone (un conteneur) en dessous (comme actuellement) qui suivant la sélection courante affichera les contrôles nécessaire. Après, ce qui serait cool, c'est que pour chaque type d'objets, celui-ci décrive les widgets dont il a besoin.

Bonjour LittleWhite,

Si vous voulez, le problème est que je ne suis pas trop satisfait de cette approche, vu que je casse un peu le principe Modèle/Vue.

L'idée que je voulais à la base c'est avoir un conteneur comme vous dites, faire conteneur.setModel(monModele), ensuite connecter le selectionModele du tableView avec le conteneur, et puis basta. Le conteneur se charge d'afficher les widgets nécessaire et de les mapper aux données.

Ça serait vraiment la solution la plus élégante à mon sens.

La solution que je vous ai présenté plus haut est peut être la plus facile à mettre en place, mais je trouve cela moche, vu que :

1. Le conteneur va demander au Modèle de lui retourner un pointeur sur l'objet sélectionné
2. Faire objet.getType() pour savoir de quel type il est
3. Faire un qobject_cast(), vu que objet est un pointeur vers la classe abstraite.
4. Remplir les différents widgets de la vue.
5. Si l'utilisateur change l'un des champs il faudra que je mette à jours l'objet à partir de son pointeur directement à partir de la vue (et court-circuiter le modèle...).

J’espère que vous avez compris le problème.


C'est pourquoi il faudrait que j'arrive à trouver une manière de faire une StackedView hériter de QStackedWidget, cette classe possèderait une sorte de QDataWidgetMapper ou équivalent qui se chargerait du mapping.
Je pourrais ainsi faire :

Code:

---

1 2 3 4 5 6 7 8 9 10

MainWindow::MainWindow(QWidget *parent) : QMainWindow(parent), ui(new Ui::MainWindow) { MonModele model = new MonModele(this); //MonModele hérite de QAbstractTableModel ui->tableView->setModel(model ); //tableView de type QTableView ui->stackedView->setModel(model); //stackedView de type StackedView (hérite de QStackedWidget ou équivalent) connect(ui->tableView->selectionModel(), SIGNAL(currentRowChanged(QModelIndex,QModelIndex)), ui->stackedView, SLOT(setCurrentModelIndex(QModelIndex))); }

---

[EDIT] Vous pouvez aussi me proposer d'autres idées. Je suis ouvert à toutes vos propositions/suggestions et réceptif à toutes vos critiques :)

Bonjour,

Je mets le sujet en résolu. Je penses avoir trouvé une solution bien plus élégante.
Cela consiste en une adaptation de l'article Qt Quarterly : "Automatic Dialogs".

++