Leveraging Qt models for nested data structures

Here is a simplified version of what I'm trying to achieve. For every Store that is added, one or more Departments can be added. For every Department that is added, one or more Employees can be added. Selecting a row in a list will update the lists to the right of it. E.g, selecting Sesame Street will update the Departments list to show all the Departments that belong to that Store. Selecting Clothing will update the Employees list to show all the Employees that belong to that Department. This relationship is also demonstrated below (note that these will actually be classes, and capable of emitting signals when their data is changed internally, for example, from external sources): struct Employee { std::string id; std::string name; double hourly_rate; }; struct Department { std::string id; std::string name; int personCount; bool status; Employee* onShift; std::vector employees; }; struct Store { std::string id; std::string name; std::string address; std::vector departments; }; On another tab, we have an aggregate list of all Departments across Stores, presenting live data, with a drop down list to select an on shift leader from the pool of Employees that belong to that Department. As far as Qt models are concerned, I imagine there a several ways to approach this. I prefer to think of Qt models as only an interface between a view and data, rather than themselves being responsible for, or having ownership of said data. I propose handing ownership of our data to a Manager class which also contains any subclassed models we create. For the configuration page, we have three QAbstractListModel subclasses for Stores, Departments and Employees. For the Departments and Employees models, we can pass a list pointer and call begin/endResetModel as needed to update the lists when items are selected. For the All Departments page, we have an aggregateDepartments model also subclassed from QAbstractListModel. This would contain a list of pointers for all Departments across Stores. The On Shift Leader dropdown is a bit more tricky as we can't use a single model. I'm wondering in this case whether it would make more sense for Department to have its own instance of the Employee list which it can return to the QML delegate... As you can see, we now have numerous models for what is a fairly basic data hierarchy. Synchronisation between models could become an issue, so the underlying data should only be modified via the Manager class, which can then orchestrate updating of the models. Have I described a worthy approach to the problem or have I created a convoluted mess? I can't really think of a better way

Feb 3, 2025 - 05:06

Leveraging Qt models for nested data structures

Here is a simplified version of what I'm trying to achieve. For every Store that is added, one or more Departments can be added. For every Department that is added, one or more Employees can be added. Selecting a row in a list will update the lists to the right of it. E.g, selecting Sesame Street will update the Departments list to show all the Departments that belong to that Store. Selecting Clothing will update the Employees list to show all the Employees that belong to that Department.

This relationship is also demonstrated below (note that these will actually be classes, and capable of emitting signals when their data is changed internally, for example, from external sources):

struct Employee {
  std::string id;
  std::string name;
  double hourly_rate;
};

struct Department {
  std::string id;
  std::string name;
  int personCount;
  bool status;
  Employee* onShift;
  std::vector employees;
};

struct Store {
  std::string id;
  std::string name;
  std::string address;
  std::vector departments;
};

On another tab, we have an aggregate list of all Departments across Stores, presenting live data, with a drop down list to select an on shift leader from the pool of Employees that belong to that Department.

As far as Qt models are concerned, I imagine there a several ways to approach this. I prefer to think of Qt models as only an interface between a view and data, rather than themselves being responsible for, or having ownership of said data.

I propose handing ownership of our data to a Manager class which also contains any subclassed models we create. For the configuration page, we have three QAbstractListModel subclasses for Stores, Departments and Employees. For the Departments and Employees models, we can pass a list pointer and call begin/endResetModel as needed to update the lists when items are selected.

For the All Departments page, we have an aggregateDepartments model also subclassed from QAbstractListModel. This would contain a list of pointers for all Departments across Stores. The On Shift Leader dropdown is a bit more tricky as we can't use a single model. I'm wondering in this case whether it would make more sense for Department to have its own instance of the Employee list which it can return to the QML delegate...

As you can see, we now have numerous models for what is a fairly basic data hierarchy. Synchronisation between models could become an issue, so the underlying data should only be modified via the Manager class, which can then orchestrate updating of the models.

Have I described a worthy approach to the problem or have I created a convoluted mess? I can't really think of a better way