Vor Multi-Calls schützen

[Eisflamme]

Hi Mechanics,

also ich nutze QTableView, QTreeView, QListView und eigene Views mit eigenen Models (z.B. Text mit bestimmter Syntax), je nach Anwendung. Und dataChanged ist in der Tat nicht das Problem, aber auch keine Allheil-Änderungs-Signal. Ich interagiere ja wie gesagt auf einem Haufen Daten. Der kann aber tabellarisch oder als Text interpretiert werden. Und für tablebasierte Views habe ich natürlich auch ein Table-Model und für textbasierte Views ein Text-Model (das ist in diesem Fall Eigenkreation).

Die eigentlichen Daten sind aber eine eigene Entität, die ich hier eben in meinem "Supermodel" halte. Table und Text sind eben lediglich Interpretationen/Darstellungsformen dieser Daten. Daher bedarf es natürlich ein Update anderer Models, wenn sich Daten in einem Model geändert haben. Und das läuft darüber, dass erst das SuperModel benachrichtigt wird und das die anderen Models benachrichtigt. Wenn ich SuperModel aber auf dataChanged vom Model verbinde, habe ich bereits wieder mein Problem:

Model1 wird geändert, signal Model1::dataChanged -> slot Supermodel::onModelDataChanged -> Model1::setData, Model2::setData -> signal dataChanged -> slot Supermodel::onModelDataChanged

Also benötige ich wieder irgendeinen Mechanismus, um das zu verhindern ("Event Handler Design" a la ShadeOfMine, also zwei verschiedene signals, ist dabei eben EINE Möglichkeit; unschön jedoch, weil dataChanged dann ein schlechter Name ist, aus dem nicht hervorgeht, für wen sich Daten geändert haben).

[hf2]

Eisflamme schrieb:

Also benötige ich wieder irgendeinen Mechanismus, um das zu verhindern ("Event Handler Design" a la ShadeOfMine, also zwei verschiedene signals, ist dabei eben EINE Möglichkeit; unschön jedoch, weil dataChanged dann ein schlechter Name ist, aus dem nicht hervorgeht, für wen sich Daten geändert haben).

Dann nenn die halt anders? dataChanged und dataSynced zb? verstehe jetzt dein problem nicht so ganz

[Eisflamme]

dataChanged ist QT-Vorgabe für die QT-Models...

Und dieser Mechanismus löst auch nicht alle Probleme, denn View-Aktualisierung läuft über das Model, also:

View1 geändert, Model1->setValue(x), Model1 emittiert signal Model::valueChanged, worauf die Views listenen... so auch View1

Klar, jetzt kann View1 eben temporär das Signal oder seinen Slot disconnecten. Dann stellt sich aber die Frage, wofür wir überhaupt unterschiedliche Signals nutzen, wenn die Views ja dann doch wieder aufpassen müssen, dass sie nicht mehrfach aktualisiert werden.

Wie löst ein "vernünftiges" Eventhandler-Design das? Sehe ich nicht. Man braucht ohnehin einen weiteren Mechanismus.

[Mechanics]

Eisflamme schrieb:

Model1 wird geändert, signal Model1::dataChanged -> slot Supermodel::onModelDataChanged -> Model1::setData, Model2::setData -> signal dataChanged -> slot Supermodel::onModelDataChanged

Das gefällt mir spontan nicht... Mit dataChanged würde ich Änderungen nach oben weiterreichen, nicht nach unten.

Ich führ noch eine GUI Ebene ein:

Widget changed -> Model1::setData -> SuperModel::setData -> Signal dataChanged:

-> Model1::onDataChanged -> Widget Slot onDataChanged löst KEIN setData mehr aus. Dürfte doch hinkommen?

[Eisflamme]

Meinst du mit "oben" das UI? Denn falls nicht: dataChanged aktualisiert automatisch die Views (oder Delegates meinetwegen nur, aber die Trennung finde ich blöd), darauf habe ich also keinen Einfluss.

In deinem Ansatz kennt das Model also jeweils sein Supermodel?

Was mir daran nicht gefällt: Die Models sollen theoretisch auch ohne Supermodel arbeiten können. Hatte ich nicht erwähnt, aber es ist quasi ne Art von Zusammensetzung. Die Models können in Interaktion miteinander wirken, müssen die aber nicht.

Daher finde ich es schöner, wenn Models signalisieren, wenn was passiert ist, statt Direktaufrufe zu machen.

Aber andere Frage: mein SuperModel ist kein QT-Model, sondern hausgemacht. Das hat also kein dataChanged; in deiner Aufrufhierarchie sehe ich jetzt nicht, wie Views geupdated werden.

[hf2]

Eisflamme schrieb:

Was mir daran nicht gefällt: Die Models sollen theoretisch auch ohne Supermodel arbeiten können. Hatte ich nicht erwähnt, aber es ist quasi ne Art von Zusammensetzung. Die Models können in Interaktion miteinander wirken, müssen die aber nicht.

Irgendwie widersprichst du dir da:

Eisflamme schrieb:

Supermodel enthält die eigentlichen Daten. In QT braucht man für einen View stets (meistens) ein "Model" (Model ist aber eher ein Adapter als ein Model im MVC-Sinne). D.h. die Models bereiten die Daten vom Supermodel in einer bestimmten Form auf, um die Anzeige /Handhabung über Views zu ermöglichen.

Eisflamme schrieb:

Alle operieren jedoch auf den eigentlich gleichen Daten, die sich in Supermodel wiederfinden.

Was jetzt, wenn das Supermodel die "eigentlichen" Daten enthält und die Models die Daten des Supermodells nur aufbereiten wie sollen die dann ohne einander arbeiten können?

Eisflamme schrieb:

dataChanged ist QT-Vorgabe für die QT-Models...

Und dieser Mechanismus löst auch nicht alle Probleme, denn View-Aktualisierung läuft über das Model, also:

Kann sein, aber das ist ja rein Qt-spezifisch und du hast ja gemeint:

Eisflamme schrieb:

Also wie gesagt... auch wenn hier vielfach anders erwähnt, mein Problem ist nicht QT-basiert

Was spricht denn gegen die Variante mit dem Flag? Einfach und schnell, was willst du mehr?

Aber ich glaub eher dass dein Design nicht ganz durchdacht ist (siehe oben).

[Eisflamme]

Hi,

stimmt schon, ist wieder nicht maximal genau. Eigentlich sieht es so aus:

* class RealData
* class SuperModel
* class Model1
* class Model2

Model1 und Model2 agieren direkt auf RealData. SuperModel dient eigentlich mehr oder minder nur als Notifier für die anderen Models. Ich hab in meiner Darstellung zur Vereinfachung jetzt RealData und SuperModel verbunden, so ist es eben nicht, sollte jedoch auch keine allzu großen Unterschiede machen.

Aber ich glaub eher dass dein Design nicht ganz durchdacht ist (siehe oben).

Es ist ja bereits umgesetzt und hat sehr viele Vorteile ggü. vielen anderen Designideen, die ich auch durchdacht habe. Mit allen Details in die Diskussion zu starten führt halt meistens zu nichts. Ich bin auch immer noch der Meinung, dass diese ganzen Extradetails für den Großteil der Diskussion nicht so wichtig sind und würde es gerne abstrakter besprechen, aber da ergibt sich leider auch keine Diskussion. Immer schwierig, wie weit man geht.

Was spricht denn gegen die Variante mit dem Flag? Einfach und schnell, was willst du mehr?

Genau das würde ich ja auch gerne diskutieren,

Flags immer und überall zu haben hat natürlich diverse Nachteile. Jeder View, jedes Model, jeder Controller muss die ständig vorhalten, es könnten leicht Bugs, man bläht damit das Interface auf und ich habe das bisher nicht breit und umfangreich so umgesetzt gesehen. Zudem wirkt es unelegant ständig bei jedem neuen View und Model solche Flags einzusetzen, es verschändelt den Code ja leider auch.

[Columbo]

SuperModel dient eigentlich mehr oder minder nur als Notifier für die anderen Models.

Sehr interessant! Arbeitest du bei Victorias Secret?

[hf2]

Eisflamme schrieb:

stimmt schon, ist wieder nicht maximal genau. Eigentlich sieht es so aus:

Model1 und Model2 agieren direkt auf RealData. SuperModel dient eigentlich mehr oder minder nur als Notifier für die anderen Models. Ich hab in meiner Darstellung zur Vereinfachung jetzt RealData und SuperModel verbunden, so ist es eben nicht, sollte jedoch auch keine allzu großen Unterschiede machen.

Eine Sache ist immer noch unklar, haben die Modells Kopien der Daten (in anderer Form) als das Supermodel? Oder sind die Daten wirklich nur einmalig hinterlegt?

Eisflamme schrieb:

Genau das würde ich ja auch gerne diskutieren,

Flags immer und überall zu haben hat natürlich diverse Nachteile. Jeder View, jedes Model, jeder Controller muss die ständig vorhalten, es könnten leicht Bugs, man bläht damit das Interface auf und ich habe das bisher nicht breit und umfangreich so umgesetzt gesehen. Zudem wirkt es unelegant ständig bei jedem neuen View und Model solche Flags einzusetzen, es verschändelt den Code ja leider auch.

Ja aber das ist halt der standard Qt-Weg. Beliebiges Beispiel aus einem Tutorial:

void Counter::setValue(int value)
{
    if (value != m_value) {
        m_value = value;
        emit valueChanged(value);
    }
}

Und ob du jetzt value != m_value vergleichst oder ein flag benutzt weil ein vergleich für deine Daten zu teuer ist, ist doch Jacke wie Hose?

[Mechanics]

Eisflamme schrieb:

Meinst du mit "oben" das UI?

Ja.

Eisflamme schrieb:

In deinem Ansatz kennt das Model also jeweils sein Supermodel?

Ja. So habe ich deine Beschreibung auch verstanden, siehe auch Antwort von hf2. Finde ich auch ok so. Das über Signale zu entkoppeln... Hmm, kann man vielleicht machen, ich will nicht unbedingt behaupten, dass das schlecht wäre. Gefallen tuts mir spontan aber auch nicht Ich denke, so wie ich das beschrieben habe, müsste es funktionieren und wäre einfacher. Aber wenn du das unbedingt entkoppeln willst, führ doch ein zweites Signal ein, dataModified oder so.

Eisflamme schrieb:

Es ist ja bereits umgesetzt und hat sehr viele Vorteile ggü. vielen anderen Designideen, die ich auch durchdacht habe. Mit allen Details in die Diskussion zu starten führt halt meistens zu nichts. Ich bin auch immer noch der Meinung, dass diese ganzen Extradetails für den Großteil der Diskussion nicht so wichtig sind und würde es gerne abstrakter besprechen, aber da ergibt sich leider auch keine Diskussion. Immer schwierig, wie weit man geht.

Es kann tatsächlich ziemlich ausarten, wenn man mit Qt etwas wirklich komplexes bauen will. Ich habe damit auch schon einige Probleme. Man hat vielleicht eine Idee und fängt mit einem sauberen Design an. Jahre später hat man tausend andere Anforderungen und jeder will irgendwie mitreden... Ich musste teilweise schon stundenlang rumsuchen, bis ich überhaupt kapiert habe, warum etwas nicht funktioniert. Ist jetzt nicht unbedingt ein Qt Problem, ich kenne keine besseren Frameworks (WPF ist vielleicht mächtiger aber ich musste damit nie so komplexe GUIs bauen wie mit Qt, kann jetzt schlecht abschätzen, ob es evtl. einfacher gewesen wäre). Ist einfach schwierig, alle möglichen Anforderungen unter ein Konzept zu bringen. Ich hab mittlerweile teilweise schon einige Hilfskonstrukte und Hacks drin.

Arcoth schrieb:

SuperModel dient eigentlich mehr oder minder nur als Notifier für die anderen Models.

Sehr interessant! Arbeitest du bei Victorias Secret?

Ich hab auch paar Seiten gebraucht, bis ich mich dran gewöhnt habe, dass er von anderen Supermodels redet ^^

[HarteWare]

Arcoth schrieb:

SuperModel dient eigentlich mehr oder minder nur als Notifier für die anderen Models.

Sehr interessant! Arbeitest du bei Victorias Secret?

lmao

[Eisflamme]

Hey, ich bin bei Victoria's Street sehr erfolgreich, aber lacht nur.

hf2:
Die Daten sind in den Models in anderer Form hinterlegt, genau. QT interessiert sich bei einer Tabelle nach den Werten, wie sie in einer Tabelle stehen. In Textform gibt es ebenfalls eine bestimmte Aufbereitung und sie sind demnach so hinterlegt. RealData hingegen hat eine kompakte binäre Form der Daten.

Die Daten sind also doppelt und dreifach gespeichert, korrekt. (Das zu verhindern würde die Performance unzumutbar beeinträchtigen)

Und ob du jetzt value != m_value vergleichst oder ein flag benutzt weil ein vergleich für deine Daten zu teuer ist, ist doch Jacke wie Hose?

Wenn ich entsprechende Event-Handler verwende, benötige ich die Abfrage jedoch gar nicht. Wären Flags oder changed != m_changed unvermeidbar, wäre die Sache klar.

Die meisten QT-Tutorials verwenden in meinen Augen ziemlich schlechte Designs, die bei Einsatz in größeren Projekten viele, viele Nachteile aufzeigen, ist für mich also jetzt erstmal kein wirkliches Argument (außer, du kannst ein bestimmtes Tutorial verlinken, in dem der Autor gut argumentiert und auch andere Ansätze ausprobiert hat).

Mechanics:
Ja, war mein Fehler, ich habe es in der Tat schlecht beschrieben.

Es gibt eben Fälle, in denen ich eine Model-View-Kombination für sich alleine genutzt wird. Dann hätte ich ein Supermodel, bei dem sich keine anderen Models angemeldet haben und somit die Benachrichtigung sinnlos wäre. Erscheint mir nicht schön.

Aber wenn du das unbedingt entkoppeln willst, führ doch ein zweites Signal ein, dataModified oder so.

Da siehst du das Problem: dataChanged und dataModified... ziemlich unschön, oder? Zudem muss ich es wie gesagt kombinieren mit einer Abfrage, ob was geändert wurde bzw. in Kauf nehmen, dass ich ein doppeltes Update habe:

View1 wird durch Benutzereingabe geändert -> Model1::setData -> dataChanged und dataModified müssen jetzt alarmiert werden, denn: sowohl andre Views als auch Supermodel müssen ja Update erfahren.

[Mechanics]

Eisflamme schrieb:

Da siehst du das Problem: dataChanged und dataModified... ziemlich unschön, oder?

Ich bin da pragmatisch und sehe kein Problem. Du hast die Anforderunng, dass du einmal bei Änderungen Notifications versenden willst, und einmal nicht. Da gibt es die paar Möglichkeiten, die wohl schon alle in dem Thread besprochen wurden, was anderes fällt mir jetzt auch nicht ein. Du hast also die Wahl, zwei Signale einzuführen oder ein Flag oder einen Guard zu verwenden. Du kannst dich im Endeffekt so oder so entscheiden. Mir persönlich würden zwei Signale denke ich besser gefallen. Damit ist schon in der Schnittstelle klar definiert, dass es die zwei Möglichkeiten gibt, die gehören dazu. Flags oder Guard schaut auf den ersten Blick nach einem Workaround aus. Den kann man irgendwo vergessen oder übersehen, ist ja nicht sofort klar, dass man das braucht. Und du wirst dann evtl. Probleme mit Queued Connections (meiner Erfahrung nach kommt man bei komplexen GUIs ohne kaum aus) und mehreren Threads bekommen (unwahrscheinlich im Model/View Konzept, aber wer weiß).

[hf2]

Eisflamme schrieb:

Wenn ich entsprechende Event-Handler verwende, benötige ich die Abfrage jedoch gar nicht. Wären Flags oder changed != m_changed unvermeidbar, wäre die Sache klar.

Du könntest die ja noch in einer parent klasse verstecken, so zb. (ist boost, mag qt nicht):

#include <iostream>
#include <string>
#include <boost\signals2\signal.hpp>
using namespace boost::signals2;

template <typename Data>
struct GuardedData {

	Data data;
	bool syncing = false;

	virtual void setData(Data data) = 0;

	void setDataGuarded(Data data) {

		if (!syncing) {
			syncing = true;
			setData(data);
			syncing = false;
		}
	}
};

struct DataModel : GuardedData<int> {

	int value;
	signal<void(int)> dataChanged;

	void setData(int newValue) {
		value = newValue;
		dataChanged(newValue);
	}
};

struct DataStringModel : GuardedData<int> {

	std::string valueFormated;
	signal<void(int)> dataChanged;

	void setData(int newValue) {
		valueFormated = "str(" + std::to_string(newValue) + ")";
		dataChanged(newValue);
	}
};

int main() {

	DataModel dm;
	DataStringModel dsm;

	dm.dataChanged.connect([&dsm](int i) { dsm.setDataGuarded(i); });
	dsm.dataChanged.connect([&dm](int i) { dm.setDataGuarded(i); });

	dm.setData(3);
	std::cout << "dm: " << dm.value << std::endl;
	std::cout << "dsm: " << dsm.valueFormated << std::endl;

	dsm.setData(5);
	std::cout << "dm: " << dm.value << std::endl;
	std::cout << "dsm: " << dsm.valueFormated << std::endl;
}

Dabei halten sich DataModel und DataStringModel gegenseitig aktuell ohne endlos-schleife.

Slots sind sauber, signals sind sauber. Alles was du machen musst ist deine jeweilige klasse von GuardedData<T> abzuleiten- oder ?

[Mechanics]

setDataGuarded und setData ist im Endeffekt dasselbe wie mehrere Signals anzubieten? Eine Variante, die benachrichtigt, und eine, die es evtl. nicht tut? Ich seh grad keinen grundlegenden Unterschied.

[hf2]

Mechanics schrieb:

setDataGuarded und setData ist im Endeffekt dasselbe wie mehrere Signals anzubieten? Eine Variante, die benachrichtigt, und eine, die es evtl. nicht tut? Ich seh grad keinen grundlegenden Unterschied.

Der unterschied ist, dass es nur einen dataChanged event gibt auf den man sich abonieren muss. Mit mehreren Signals kannst du das problem natürlich auch lösen, aber wenn du jeden data change mitbekommen willst musst du halt auch immer viel mehr events registrieren.

Mit der methode bleiben die models "klein" (nur ein signal) und der Aufwand sich bei einem einzuklinken ebenfalls

[Mechanics]

Aber es sind immer noch zwei Funktionen in der API. Dann wärs wahrscheinlich besser, wenn setData grundsätzlich guarded wäre. Vielleicht besser übers Template Pattern lösen?

Bzw., hast du ja eh schon. Dann würde ich setData private virtual machen und nach außen nur setDataGuarded anbieten. Die kann man dann umbenennen, dann heißt die public Methode setData und die interne setDataInternal.

[hf2]

kann man wahrscheinlich machen aber ich finds nicht schlimm 2 Funktionen im API zu haben. Letzendlich sind das 2 Funktionalitäten, da kann man auch 2 Funktionen für anbieten.

Ich denke das hauptproblem war dass man mit mehreren signalen höllisch aufpassen muss dass immer alle data changed signale connected werden damit man keine Änderungen verpasst, und das Problem ist damit gelöst.

[Eisflamme]

Mechanics schrieb:

Eisflamme schrieb:

Da siehst du das Problem: dataChanged und dataModified... ziemlich unschön, oder?

Ich bin da pragmatisch und sehe kein Problem.

Also mir geht's gerade halt ums Naming. Ich finde die Variante mit mehreren Signals jetzt prinzipiell auch gut, aber dataChanged und dataModified... den Code lese ich eine Woche später und muss erstmal rausfinden, was was ist.

Aber angenommen, ich benenne das irgendwie anders. Wie würdest du diese zwei Signals gestalten?

Ein Signal könnte z.B. ausgelöst werden, wenn eine Änderung über SuperModel mitgeteilt wird, die andere bei einem Change über das UI, wäre dann:

- changedByModel
- changedByUI

Wenn ein Change übers UI geschieht, müssen andere Views ja aber auch alarmiert werden. Also muss sich ein View auf beide registrieren...

Alternativ überlegt man stattdessen, dass man sich die Frage stellt, wer alarmiert werden möchte. Entweder nur das SuperModel, um andere Models zu benachrichtigen, oder nur die Views, wenn eine Änderung vom SuperModel kommuniziert wird:

- changedForUI
- changedForModels

Dafür müssen wir dann zwei mal emittieren. Wenn vom UI eine Änderung kommt, emittiert das Model changedForUI und changedForModels. Wenn vom Supermodel eine Änderung kommt, emittiert das Model nur changedForUI.

Trotzdem brauchen Model und Views jetzt noch Flags, um zu testen, ob sie das Signal eigentlich ursprünglich ausgelöst haben. Eigentlich bringt das Signal-Design so also gar nichts?!

Nagut, oder wenn ich es entkoppeln möchte und Model eben SuperModel kennen können soll, ginge natürlich auch:

// interface
class SuperModelBase
{
public:
    void setData(...);
};

class Model
{
public:
    void setData(...)
    {
        if(!dataInChange)
        {
            dataInChange = true;

            if(superModel)
                superModel->setData(...);

            this->data = ...;

            dataInChange = false;
        }
    }

    void setSuperModel(SuperModelBase* superModel)
    {
        this->superModel = superModel;

        connect(superModel, &SuperModel::modelChanged, this, &Model::SetValueByModel);
    }

private:
    SuperModelBase* superModel;
};

Dann müssen Signals und Slots in Base natürlich auch bekannt sein... viel gewinnen wir durch so ein Interface nicht.

Und überhaupt... so viel Boilerplate-Code das muss doch eleganter gehen.

Edit2:
Na ja, aber wenn wir konsequent überall solche Flags einsetzen, dann reicht es ein einziges Signal zu haben... alles andere nützt ja auch nichts.

[Mechanics]

Ich hatte mir das glaub ursprünglich so gedacht, dass setData beides auslöst, dataChanged und dataModified. dataChanged wäre für die GUI, dataModified für die "interne" Kommunikation. Supermodel würde auf dataModified horchen und kein dataChanged auslösen, da klar ist, dass die Änderung eh schon von oben reingekommen ist. Allerdings willst du damit ja auch dein anderes Model benachrichtigen, und das soll auch ein Signal für die GUI auslösen, also kommst so wohl auch nicht weiter.

Ja, dann musst wohl irgendeine Art Flag einsetzen. Aber überleg dir mal, ob die Bindung von Model und Supermodel über Signale tatsächlich eine gute Idee ist. Ich finde, das führt hier eben zu Problemen. Kann sein, dass später noch mehr Probleme mit dem Konzept auftauchen.