Discussion :

[Aurelakan]

Bonjour,

J'apprends actuellement PySide et le concept MVC (enfin MVD) et j'avais une question pour représenter des données, organisées en tables (liste de listes), en arbre. J'ai donc sous-classé sans souci grâce à des tutos un QAbstractTableModel afin de représenter et éditer mes données via une Tableview. Je souhaiterais également pouvoir représenter lesdites données sous forme d'arbre. Suites à des recherches, je suis tombé sur les proxy model mais je ne trouve pas de tutos clairs qui expliquent notamment comment surcharger les méthodes de QSortFilterProxyModel pour obtenir un arbre (si je ne me trompe pas, c'est la classe qu'il me faut). Je souhaite pouvoir regrouper les données par parent et les ordonner (les parents ne sont pas définis dans le QAbstractTableModel).
Est-ce que je dois définir une seconde classe qui définit les nœuds de l'arbre avant de faire un proxy Model (mais dans ce cas comment les relier au QAbstractTableModel ?) ou puis-je tout faire dans la classe dérivée du proxy ? Si je dois dériver d'une classe de proxy, quelles méthodes je dois surcharger pour représenter un arbre à partir du QAbstractTableModel (notamment si j'ai bien compris maptoSource et mapfromSource) ?


Merci d'avance pour vos réponses.

Aurelakan.

[tyrtamos]

Bonjour,

Je n'ai qu'un petit morceau de réponse. A mon avis, le proxy QSortFilterProxyModel est fait pour s'interposer entre le modèle et l'objet graphique. Je l'utilise avec un QTableView pour consulter des tables d'une base de données, mais le "vrai" modèle reste dans ce cas QSqlRelationalTableModel qui fait la relation avec les données. Ce proxy me sert à ajouter des fonctions de tri/filtrage/recherche qui n'existent pas dans le modèle normal (tri selon le dictionnaire français, recherche de mots similaires avec ratio de proximité, etc....).

La logique pour cette interposition est la suivante:

- on a un modèle "model" qui est branché sur les données
- on crée un proxy
- on définit ce modèle comme source du proxy avec quelque chose comme: proxy.setSourceModel(model)
- et on "accroche" le proxy à l'objet graphique avec par exemple vtable.setModel(proxy)

A mon avis, si pour un QTreeView le modèle "QAbstractTableModel" est déjà trop typé "table", il faut revenir à son ancêtre "QAbstractItemModel". Avec les 2 mots "QTreeView" et "QAbstractItemModel" dans google, on trouve quelques pages qui peuvent être source d'inspiration (ex: http://www.hardcoded.net/articles/us...tractitemmodel).

[Aurelakan]

Merci beaucoup pour votre réponse rapide.

Donc la solution serait de dériver de QAbstractItemModel et de n'avoir qu'un seul modèle pour gérer les 2 vues ? Je vois bien pour .parent (la QTableview doit l'ignorer je pense et seul le QTreeview s'en préoccupe), mais pour columnCount par exemple, dans le cas de la QTableview, la méthode retourne le nombre de colonnes à afficher alors que pour le QTreeview elle doit retourner 1 . Il y a un peut-être un moyen de gérer ça mais je n'ai pas encore trouvé...

Merci de votre aide.