Qt Forum

    • Login
    • Search
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Groups
    • Search
    • Unsolved

    Way Forward for Model/View Design

    General and Desktop
    3
    6
    2523
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • S
      salukibob last edited by

      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

      1 Reply Last reply Reply Quote 0
      • Z
        ZapB last edited by

        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.

        Nokia Certified Qt Specialist
        Interested in hearing about Qt related work

        1 Reply Last reply Reply Quote 0
        • S
          salukibob last edited by

          Ok great, thanks for your advice.

          1 Reply Last reply Reply Quote 0
          • Z
            ZapB last edited by

            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.

            Nokia Certified Qt Specialist
            Interested in hearing about Qt related work

            1 Reply Last reply Reply Quote 0
            • G
              goetz last edited by

              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.

              http://www.catb.org/~esr/faqs/smart-questions.html

              1 Reply Last reply Reply Quote 0
              • Z
                ZapB last edited by

                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.

                Nokia Certified Qt Specialist
                Interested in hearing about Qt related work

                1 Reply Last reply Reply Quote 0
                • First post
                  Last post