0

I'm trying to understand what should the relationships between the Model and the Data be.

enter image description here

For my current situation i have a QTcpServer which keeps a list of active sockets.

class TftpServer : public QTcpServer
{
    Q_OBJECT
public:
    TftpServer(QObject *parent = 0)
        :QTcpServer(parent) {}
    QList<QTcpSocket *> m_activeSockets;

The Data that the Model should represent to the View is QList<QTcpSocket *> m_activeSockets;

I feel like the right way to do it is to prevent the duplication of data at any cost for that can lead to inconsistency. Meaning that at all times View should represent the real state Data.

I have tried some approaches, didn't succeeded in any because i have limited time i can spend testing each approach.

Approaches:

1.

TftpServer::m_activeSockets private, Model accesses it through getters and setters.

  • Flaw: How to call methods from the TftpServer::m_activeSockets within the Model?

2.

Model friend class of TftpServer. Directly accesses TftpServer::m_activeSockets.

  • Failed to implement.

3.

TftpServer::m_activeSockets public. Model has a public reference

QList<QTcpSocket *> & m_activeSockets; to TftpServer::m_activeSockets.

  • Flaw: Sensitive data publicly available

I would like to find out an optimal solution (feel free to suggest) is considered optimal.

And hear if their are pros of not insisting on a single Data source (in which case the model would just have a copy of TftpServer::m_activeSockets as its parameter and sync with it on changes).

TheMeaningfulEngineer
  • 15,679
  • 27
  • 85
  • 143
  • What do you (your model) need to know from `QList`? Size? What else? – vahancho Oct 31 '13 at 11:06
  • @vahancho It will have to access items from the list (`QTcpSocket *`) and their methods. Example, if someone clicks on that item in View he should get the `QTcpSocket::peerName()` printed out somewhere in the GUI. – TheMeaningfulEngineer Oct 31 '13 at 11:11
  • Well, if you don't want to expose sensitive data (point 3. in your list) than just implement wrapper functions in `TftpServer` class, such as `QString TftpServer::peerName(int)` etc. In that case your model will not deal with QTcpSocket objects at all. – vahancho Oct 31 '13 at 11:16

1 Answers1

1

You're abusing Qt's model-view architecture - there's no need to pass actual sockets around. What you want is to model a list of connections, so just implement that. Connections have some parameters - those can be mapped to a model's columns, or as child rows with each connection being a parent item in a tree, depending on what's more convenient. The data a model should provide must make sense in terms of visualization. A QTcpSocket is nothing that can be visualized unless you'll be making your own custom views or delegates. Things that can be visualized are numbers, strings, etc.

What you're trying to do is to re-use QTcpSocket as only a structure with some accessor methods used to return the hostname, port and the like. You won't save any time by abusing it that way.

Kuba hasn't forgotten Monica
  • 95,931
  • 16
  • 151
  • 313