Way Forward for Model/View Design
-
Hello,
I'm writing a fairly straightforward desktop application to download and display financial stock quote data. The layout will have a QTreeView on the left displaying a list of stock quotes, and a QMdiArea on the right. When a user double clicks on any one particular item in the tree view, a new MdiChild window is created and displayed. Each MdiChild will consist of a two-page tabbed view, containing both a table list view of the data for the individual stock, and a graphic view of the data. I will be using QT4, and exercising its Model/View approach.
The data for each stock will be a table with 5 columns (date, open price, close price, high and low). This data will be sourced from a SqlLite database file.
My question is... In the situation above, is it appropriate to use an individual model to represent the data for each stock, i.e. a QAbstractTableModel (subclassed), and so each time a new MdiChild is created, a new QAbstractTableModel (or similar) is created for that individual stock data? Or, would it be more sensible to use a global application model that would allow access to all the data for all stocks (only loading those displayed)?
I can see merits to both approaches, but wonder what would be the more normal way to do this?
Thanks for any advice,
Regards
Rob Smith -
It is entirely up to you. Both approaches are valid. You can either have one big hierarchical model, with lazy population. You can then set the data on the table views and charts using setRootIndex().
Or alternatively one list model (or a hierarchical model if you want to group the listings somehow) plus a set of instances of a table model for the individual data visualisations.
List and table models are easier to deal with but you have to write two models. Hierarchical models are slightly more complex but you'll only need one of them.
-
Out of curiosity what are you planning on using to chart the financial data graphically and what features do you need from it? I ask as I am developing a charting component for Qt and I am planning to add financial time-series plots to it at some point so some real world usage patterns would be good to know.
-
I personally would go for the one model per stock approach, as it's much easier to implement. One single, unified model would only be sufficient if the data is so closely related, that it can only be stored in a single data structure.
As some brainstorming: Make a QAbstractTableModel subclass and give it a property identifying the stock. Then put all the "logic" to retrieve the data into the model.
-
Thinking about this some more, I agree with Volker. It will be easier to maintain and you can more easily swap out either of the models in the future if you need to. You also avoid headaches with lazy fetching of data and can release memory more easily when you close a view onto a particular stock.