Composition vs Aggregation when working with models
-
I think you are mixing two things:
The alternative/aggregation approach describes a relational data(base) model with an identity key.
A tree model is the generic way to visualize such models, preferably hiding the (random) identity keys from the user.
Of course you can fiddle around with sort/filter proxy models or list models. That will in the end be complicated and come with limitations.
I can't advise about how to do the wrong thing right.
What I can advise though is to figure out what you found difficult with tree models and tree views. Work on that, ask questions here and overcome your reluctance. IIRC we were taught at university how to do the right things right ;-) -
Would I still be able to have separate University, Course and Module objects in my tree model, and display in views other than tree view (e.g. listview, gridview, etc). I suppose part of my reluctance comes from the fact that our hierarchy only has 3 levels, and each level is of a fixed type.
-
You could make that a nice inheritance exercise, if you want:
- Create an abstract
TreeItemclass with a type as an enum and a protected constructor. - Make
University, Course, Moduleinherit from it. - By checking the type, you know which class to cast the a
TreeIteminto. That way you have separate objects.
Of course you can have three list views next to each other. By clicking on a university, you refresh the view for courses and so on.
What I find hacky about this, is to handle entity relations on a UI level.
If you ever wanna display the same data e.g. in a mobile app written in QML, you have to re-implement the same logic in two pieces of UI software. That's asking for trouble. Entity relations should be handled on model level therefore. Then the same data can be consistently displayed (and if you implement it: also modified) in aQTreeViewof a widgets desktop application as well as with aTreeViewQML type. - Create an abstract
-
Thank you, I'll definitely explore what you've suggested. I think I'll start with TreeItem and work my way up from there.
Out of interest, what are your thoughts on achieving the nested data by giving each University object an instance of a CourseListModel, and each Course object an instance of ModuleListModel? We could then retrieve the required model instance via a custom role in data() and set it on the desired view. This to me seems like a simpler method, while also giving us flexibility for future expansion. What are your thoughts?
-
I am not sure if I understand that correctly. You want to build a list model basically for each node of the tree?
Sure, it can be done.
My immediate thought is: I complicated way to avoid a tree view. But maybe that's because I don't fully understand your use case. -
Thanks for the suggestion. I've found tree models difficult to work with in the past so am somewhat reluctant to use them here. Any thoughts on the second approach I suggested?
-
How so?
Traversing a tree to get a Module in our non-GUI related code is more difficult than just doing universities[0].courses[0].module[0]. I have wondered though whether I could keep my data separate from QModelIndex, where a simplified "TreeItem" contains only the minimum data needed to locate the required object elsewhere. Or does that seem hacky to you?
-
How so?
Traversing a tree to get a Module in our non-GUI related code is more difficult than just doing universities[0].courses[0].module[0]. I have wondered though whether I could keep my data separate from QModelIndex, where a simplified "TreeItem" contains only the minimum data needed to locate the required object elsewhere. Or does that seem hacky to you?
@ECEC said in Composition vs Aggregation when working with models:
Traversing a tree to get a Module in our non-GUI related code is more difficult than just doing universities[0].courses[0].module[0].
Well, why? To use a tree model you need to be able to "quickly" locate a given item. The way you describe your data you ought be able to do this. If not then why not, and it might be indicative of why you are having problems with a tree.
It ought not really matter whether you build your data structures around native Qt tree items or whether you pick your own data structure so long as you can map access between yours and Qt models, which you should be able to do.
I could keep my data separate from QModelIndex, where a simplified "TreeItem" contains only the minimum data needed to locate the required object elsewhere
Yes you can do that. It should not matter so long as there is a "natural" (i.e. quick) mapping both ways between your data structures and Qt's model requirements.
-
I think I've been really overthinking things and worrying about abusing the Qt model architecture.
As we have a predictable structure, where each level of the tree has a known type, I suppose I wouldn't even need to subclass University, Course and Module from a generic TreeItem. I could simply store the pointer in internalPointer and then static_cast back to the required type depending on what level we are at. -
I think I've been really overthinking things and worrying about abusing the Qt model architecture.
As we have a predictable structure, where each level of the tree has a known type, I suppose I wouldn't even need to subclass University, Course and Module from a generic TreeItem. I could simply store the pointer in internalPointer and then static_cast back to the required type depending on what level we are at.@ECEC said in Composition vs Aggregation when working with models:
I suppose I wouldn't even need to subclass University, Course and Module from a generic TreeItem. I could simply store the pointer in internalPointer and then static_cast back to the required type depending on what level we are at.
Exactly, if that is what suits best.
