Understanding the need for Proxy Models

[RaisinBread22]

I read this Qt documentation on Proxy Models, but one thing was unclear. The documentation explains why sorting isn't an internal function of views, or is an internal function of models(thus justifying the need for proxy models) by stating that:
Although it seems appropriate to perform sorting and filtering operations as internal functions of views, this approach does not allow multiple views to share the results of such potentially costly operations. The alternative approach, involving sorting within the model itself, leads to the similar problem where each view has to display items of data that are organized according to the most recent processing operation.

I don't understand the second sentence that states that sorting in the model leads to a "similar problem where each view has to display items of data that are organized according to the most recent processing operation." I don't see why you couldn't have multiple models of the same data, one for each set of views that need to display the same data, the same way, at the same time. Could someone please clarify? I want to fully understand why I'm using proxy models, instead of just blindly using them. Cheers!

[Chris Kawa]

I don't see why you couldn't have multiple models of the same data, one for each set of views that need to display the same data, the same way, at the same time

You could, you should even, and those are exactly the proxy models ;)

The sentence you asked for just says that if sorting was the model's role and there were no proxies you would either be locked to the current sorting order of the model in all views or had to re-sort the model every time you draw the view to match its current need.

Proxies solve the problem exactly like you stated - you group the views by matching sorting criterion and have a single sorting proxy for each group, thus you only do the sorting minimum times required.

[RaisinBread22]

@Chris-Kawa Thanks for the answer! Why don't developers just use that functionality though models and make copies of the model as needed, instead of creating the separate concept of a "proxy model"? The only thing I can think of is that dealing with so many duplicate models might get messy, so the proxy model concept simplifies things, since there's just one "parent" model for the data and multiple proxies for different ways to represent it.

[SGaist]

Hi,

Because:

• Not all models need that kind of functionality so why bloat the base class for that ?
• How would you have different view use different sorting on top of the same model ?

Proxy models are not just for sorting or filtering, you can alter other aspects of the base model for a specific view without any impact on the other views.

[Chris Kawa]

@RaisinBread22 Basically you've got 4 layers:

0. data source: the actual non-Qt data, be it some database, network storage, your own structure or whatever
1. data access model : class implementing QAbstractItemModel e.g. QStandardItemModel or QSqlQueryModel
2. filtering and sorting: class implementing QAbstractProxyModel e.g QIdentityProxyModel or QSortFilterProxyModel
3. view: ui classes implementing QAbstractItemView e.g. QListView or QTreeView

With that you can build hierarchies like this:

                           sort/filter  -  view
                          /
data src  -  data access - sort/filter  -  view
                          \
                           sort/filter  -  view
                                         \
                                           view

If I understand you correctly you're asking about doing something like this (without the proxies):

             data access/sort/filter  -  view
           /
data src  -  data access/sort/filter  -  view
           \
             data access/sort/filter  -  view
                                       \
                                         view

And you can do that if you want, but that means you'd need to manually synchronize all the models, which will get messy if you combine it with the sorting/filtering code.
Proxy models are convenience classes that help you separate these tasks better, as the synchronization is automatic because there's only one data access model underneath.

Also consider models that initialize some sort of resource to access the underlying data (e.g. establish database connection). It could be expensive to copy them around.