identifying signal senders

JonB

@mzimmers Of course, whatever you need to identify it when the response is received.

SGaist

@mzimmers hi, QNetworkReply being a QObject, you could set the signal sender as dynamic property on it. You can then retrieve it when processing the result.

mzimmers

@SGaist right, but it's the same problem -- what do I do with it? How do I go from knowing the sender to invoking a method in the sender class?

jeremy_k

Return the QNetworkReply from MessageMgr::sendGet(), connect the appropriate model slot to QNetworkReply::finished(), and eliminate the intermediary handling of the reply.

Another alternative is QNetworkRequest::setOriginatingObject() and QNetworkReply::originatingObject().

JonB

@mzimmers said in identifying signal senders:

@SGaist right, but it's the same problem -- what do I do with it? How do I go from knowing the sender to invoking a method in the sender class?

Again, I don't understand. I wrote earlier for this suggestion:

Subclassing QNetworkRequest could allow you add a QAbstractItemModel * to directly identify the data model.

So you would have a pointer to the model as a QAbstractItemModel *. On which you can call (QAbstractItemModel) methods directly. Or if your models share some other common interface you could derive them from YourModelBase and pass that as parameter to be able to call its methods. Or you could use qobject_cast<SpecificModelType *> to test their type and call specific model methods.

Or the approaches @jeremy_k mentions. Using QNetworkRequest::setOriginatingObject(someModel) saves subclassing if you don't want to do that, but it's the same approach. His direct connection of finished signal could be used if you do not actually want/need the manager to see/handle the replies.

One way or another you can either have the models send an identifier for themselves to the manager, which then routes replies to the model from that, or you can have the manager return the QNetworkReply * from QNetworkAccessManager::get() to the model and that puts e.g. a slot on QNetworkReply::finished() to its own code.

jeremy_k

@JonB said in identifying signal senders:

His direct connection of finished signal could be used ~~if you do not actually want/need the manager to see/handle the replies.~~

The struck-out portion is inaccurate. The manager can view the reply status via any of the const methods, or read content via QIODevice::peek() without interfering with later connections to the finished or readyRead signals.

JonB

@jeremy_k
Yes, but that's not what's meant. It's a question of whether the OP wants the replies routed through the manager, possibly to choose whether to send on to the models or to ignore/not do so, or whether the model receives the finished regardless and acts on it. I said "could" be used if OP does not want manager to see/handle the replies, not that it would preclude the manager seeing the responses as you wrote. As you said, not attaching the finished() signal to the model to "eliminate the intermediary handling of the reply" means that it will be attached and handled by the manager as "intermediary". Depends what the OP wants,

jeremy_k

@JonB said in identifying signal senders:

@jeremy_k
Yes, but that's not what's meant. It's a question of whether the OP wants the replies routed through the manager, possibly to choose whether to send on to the models or to ignore/not do so, or whether the model receives the finished regardless and acts on it. I said "could" be used if OP does not want manager to see/handle the replies, not that it would preclude the manager seeing the responses as you wrote. As you said, not attaching the finished() signal to the model to "eliminate the intermediary handling of the reply" means that it will be handled by the manager as "intermediary".

Fair enough. I had interpreted "see/handle" as non-exclusive.
To me, a manager that inhibits what the model sees from a successful request is acting as part of the model. HTTP and QNetworkReply has error codes to indicate lack of success.

TomZ

Feels like the issue has little to do with the network request.

The issue is that the manager doesn't keep state.

So, if model X makes a request to the manager which is then forwarded to get an async reply. What you want to do is to ignore the fact on how its implemented and simply do what all async APIs do. Create a new QObject that emits a signal when its got a data update.

So what you see, as an example API, networkmanger::get() do, they return an object with a bunch of signals.

What you want to do is make you message-manager do the same. This means it needs to keep state. Which means it needs to route messages only back to the object it actually owns. An equivalent to the NetworkReply, maybe called SignalManagerReply...

The fact that the message-manager itself uses the network manager privately is a nice parallel you can probably use to mirror the workflows.

Edit; oh, and want to add that your initial statement of a 'model' asking he signal-manager something is breaking the model-view-controller design. You need a controller to handle an async API like the signalmanager would have (as a result of it using networkmanager).

Such a controller-style class is where the SignalManagerReply is used.

mzimmers

@TomZ I ended up taking Jeremy's suggestion, and it works beautifully. Keeps the message manager self contained and no need for state awareness.