Einstieg in Model-View-Konzept



  • Kennt jemand einen leichteren Weg ins Model-View-Konzept als den, "diesen ellenlangen Artikel":http://doc.qt.nokia.com/4.7-snapshot/model-view-programming.html durchzuarbeiten? Der ist ja sooo demotivierend, vermutlich war der Autor selbst über seine Aufgabe deprimiert. Ein anwendungsbezogener Einstieg wäre meines Erachtens besser, also z.B. den Leser die Erfahrung nachvollziehen zu lassen, wie man mit einem "normalen" QListWidget an Grenzen stößt.



  • Also, ich weiß net ob's kürzer ist, aber ich hab mit dem Buch "GUI programming with Qt4" angefangen, und fand das ganz gut. Da ist auch M-V ganz gut erklärt, ist aber schon ne weile her....



  • Gerolf, bei der Gelegenheit: "GUI programming with Qt4" - kannst du das empfehlen? Ich habe bislang nur ziemlich schlechte Kritiken zu Qt-Büchern gelesen und deshalb bislang auf jeglichen Kauf verzichtet.



  • Hi Wolf,

    ich muss sagen, ich finde die Bücher sehr gut. Ich hab damals mit der version für 3.x Qt gelernt, und fand es sehr gut. Die Version für 4.x (C++ GUI Programming with Qt 4, first edition) habe ich dann als es rauskam auch nochmal durchgearbeitet und ich finde das Buch sehr gut und verständlich.

    By the way:

    "Advanced Qt Programming" lese ich gerade, und bis jetzt gefällt mir das auch ganz gut.

    Was ich als Nachschlagewerk und zum spezifischen Problem anschauen auch ganz guit finde ist:

    "Practical Qt":http://qt.nokia.com/developer/books/7 von Matthias Kalle Dalheimer

    Bis jetzt habe ich bei Qt Büchern immer die Originalversion genommen (englisch) und die sind meines erachtens gut --> Ja ich würde sie empfehlen :-)



  • Problem bei der M-V-Programmierung mit Qt ist, dass es definitiv kompliziert ist :-/

    Ich habe den o.g. Artikel noch nicht gelesen, der scheint aber wirklich alles abzuhandeln. Geht's Dir um einen bestimmen Aspekt? Meistens hakt es nämlich an der Programmierung des ersten eigenen Modells (QAbstractItemModel-abgeleitete Klasse). Bei den Delegates kommt man meistens mit etwas try-and-error und spicken bei den Trolls weiter, beim Model hilft das leider nichts.



  • Ich finde, eingangs fehlt es an einem Motivierungsabsatz: die Stelle, die mich ganz gierig macht, den Artikel zu verschlingen. Stünde dort ein dem Anschein nach leichtgewichtiges Beispiel, das es dann letztlich doch in sich hat, so dass man nachweislich mit einfacheren Mitteln scheitert, dann wäre das vermutlich hoch-motivierend.

    Und ich nehme an, es ist nicht so kompliziert zu verwenden, eher kompliziert alles zu verstehen. Also sollte ich vielleicht eher nach einem einfachen how-to suchen (oder eins schreiben? würdest du helfen?)



  • Hast du dir mal die examples angesehen? Die sind glaub ich auch ganz gut.

    Der witz is ja, du kannst mit einem einfachen Table model (read-only) anfangen, und das stück für stück ausbauen (daten editieren, zeilen hinzufügen/löschen, Spalten hinzufügen / löschen, ...).

    Die meisten Probleme, die ich bisher bei Leuten gesehen haben, ist beim editieren / verändern der Daten:

    Es wird vergessen beginXXX endXXX oder emit dataChanged(a,b) aufzurufen.

    Und kompliziert wird es bei editierbaren Tree Models und proxys :-)

    Aber wir können schon einhow-to schreiben, kp.



  • Drag'n'Drop macht sehr viel spass :-) Ich sag' nur dangling pointers, persistent indexes etc.pp. Ein gutes deutsches HowTo wäre aber sicher nicht verkehrt. Und. ggf. mal mit einem Listen-Modell anfangen und erst später auf ein Tree-Modell erweitern.



  • Ein de-tutorial fänd ich gut - übersetzen ins Englische könnten wirs, wenns fertig ist. Wäre z.B. folgendes ein guter Kandidat: einen Logdatei-Viewer zu implementieren, der mit der Darstellung einer bereits existierenden Datei zunächst gut zu Rande kommt, auf Grund der Forderung nach Aktualisierung und Filtermöglichkeiten aber später an seine Grenzen stößt (betrachtet es als einen Schuss ins Blaue...) - könnte das funktionieren? (als Aufhänger für ein How-To mein ich?)



  • Wenn du jetztdas ganze nicht als datei nimmst, sondern als fenster für logs die mit qDebug kommen, wär's fast schöner, weil es dann gleich dynamisch werden kann :-)

    Aber prinzipiell ist das ein ganz guter anfang.



  • Beide Varianten sollten vorkommen. Das Tutorial könnte mit einer einspaltigen Liste beginnen, die einfach nur aus einer Log-Datei geladen wird. Und dann kommen Wünsche dazu:

    • Spalten (damit Wechsel auf Tabelle)
    • Sortierbarkeit
    • Filterbarkeit und...

    Bums!

    • Alternative Quelle(n)

    ich glaube so eine Anleitung würde ein Neuling durchlesen wollen, die super-einfach anfängt und Stück für Stück ans Eingemachte geht. Ist ja auch realistisch: kennen wir sie nicht alle die Forderungen nach einem ganz einfachen Einbau, bloß eine Liste, die - sobald der Benutzer dann davor sitzt und "Blut leckt" - wachsen und gedeihen ;) ?



  • Die idee ist gut, ich denke, man sollte das irgendwie als verketten artikel bauen (Teil 1 - Teil X).

    Nachdem du nach einer einführung gefraght hast:

    Sollen wir dir Aufgaben stellen und du löst sie fg?



  • Wäre eigentlich das Vernünftigste. Ich meine, zu Qt hab ich wirklich noch nicht ein so inniges Verhältnis, kenne aber bereits einige Frameworks. Vielleicht die besten Voraussetzungen für ein realitätsnahes Umsteiger-Tutorial. Auch die Gliederung halte ich für gut: so um die max. 10 Seiten im Wiki, die können ja ruhig zum Ende hin etwas zulegen an Größe (und Speed, damit's nicht langweilt).

    Meine Lust darauf wächst ;) leider meine Zeit nicht, aber mal sehen...



  • Tja, die Sache mit der Zeit immer... kenne ich nur zu gut.

    Was mir noch fehlt, ist eine gute Idee für das Modell. Muss ja auch auf allen drei Plattformen (Linux, Win, Mac) laufen.



  • Sach einfach Bescheid, das bekommen wir schon hin.



  • Man könnte eine XML-Datei (oder S-Ausdrücke, oder .. ) in einem Baum darstellen. Muss ja nicht für Baum/Liste/Tabelle das gleiche Beispiel sein.



  • Ein XML-Modell habe ich sogar schon halb fertig, die gibt's aber meines Wissens nach auch schon fix & fertig im Netz. Eine QObject-Hierarchie wird in den Einstiegskursen (KDAB & ICS) auch immer gerne genommen.



  • Ich halte Liste bzw. Tabelle für ausreichend, schließlich soll man das Model/View-Konzept anhand seines Nutzens für ein konkreten Beispiels verstehen. Welches von beiden geeigneter ist, kann ich im Moment nicht sagen. Da ich für den naivsten Ansatz eine einfache Liste "QListWidget":http://doc.trolltech.com/latest/qlistwidget.html verwenden würde, könnte die Hinleitung zum ListenModel leichter fallen. Aber vielleicht geht man auch erst zu "QTableWidget":http://doc.trolltech.com/latest/qtablewidget.html über, weil man die sortierbare Spaltendarstellung zuerst als nötig empfindet, dann wären die Hauptstationen des Fahrplans diese:

    • QListWidget
    • QTableWidget (vielleicht als "Exkurs")
    • QTableView-basierte Lösung

    ...^^ das könnte das erste Körnchen fürs Wiki sein, denke ich.



  • Klingt wie eine Gute idee, aber willst du wirklich mit den QXxxWidgets anfangen? Oder lieber gleich mit den QXxxViews?



  • Darum geht es doch gerade ;)
    zu sehen, ob und wann es mit der "Tiefkühlware" kneift



  • [quote author="Gerolf" date="1294303547"]Klingt wie eine Gute idee, aber willst du wirklich mit den QXxxWidgets anfangen? Oder lieber gleich mit den QXxxViews?[/quote]

    Zu den Widgets gibt's ja nicht viel zu schreiben, bzw. wäre das ein eigenes Tutorial. Was ich so mitbekomme, gibt's mit den Dingern auch weniger Probleme (= Fragen). Außerdem ist da das MVC ja "versteckt" :-)

    Die QxxViews kann man größtenteils auch so ganz gut verwenden. Probleme gibt's eigentlich immer beim Implementieren des ersten eigenen Models.



  • Deswegen würde ich auch mit einem MV - Konzept anfangen.

    Meiner meinung nach macht das auch mehr Sinn. Ich arbeite jetzt aj auch schon ein paar Jahre lang mit Qt, und Anfangs (Qt 3) gabs MV ja noch net. Mit 4.x haben wir das alles umgestellt, weils am Ende einfacher und flexibler ist.

    Nur wie soll man in so einem Tutorial das einfach Zeigen? Evtl durch große Datenmengen und Speicherverbrauch? Oder ein internes Datenmodell das mittels eines QXxxModel einfach angeflanscht werden kann?



  • Für ein Tutorial würde ich mit einem komplett neuen Model beginnen (also nur von QAbstractItemModel abgeleitet). Alles andere macht es nur wieder noch komplizierter und zeigt auch wieder nicht die Methoden auf, die man implementieren muss.

    Also kurz abgerissen mal ein Vorschlag für eine Gliederung (ohne Garantie auf Vollständigkeit, angelehnt an die Qt Tutorials):

    • Teil 1 - Read only Model
      ** index()
      ** parent()
      ** rowCount(), columnCount()
      ** data()
      ** hasChildren()
    • Teil 2 - Read-Write Model
      ** flags()
      ** setData()
      ** Signale dazu
    • Teil 3 - Einfügen/Löschen von Zeilen/Spalten
      ** insertRows(), insertColumns()
      ** removeRows(), removeColumns()
    • Teil 4 - Lazy loading
      ** canFetchMore()
      ** fetchMore()
    • Teil 5 - Drag'n'Drop
      ** mimeData()
      ** supportedDropActions()
      ** mimeTypes()
      ** dropMimeData()

    Siehe auch

    "QAbstractItemModel":http://doc.qt.nokia.com/latest/qabstractitemmodel.html
    "Model/View Programming":http://doc.qt.nokia.com/stable/model-view-programming.html

    EDIT:
    Jetzt auch im Group-Wiki: "Stoffsammlung MVC-Tutorial":http://developer.qt.nokia.com/groups/qt_german/wiki/Stoffsammlung_MVC-Tutorial
    Bitte dort weiterentwicklen



  • Find ich als Gliederung schon sehr gut, ich würde aber noch einen Tree mit einbauen (so als Teil 3.a) und vorher das ganze als Tabelle aufbauen (ich denke ist der mehr genutze fall als der baum).

    Sollen wir in dem Zusammenhang noch auf Delegate und oder proxys eingehen?



  • Tabelle würde ich von Anfang an mit einbauen. Damit ist das Model dann für alle drei View-Typen (List, Table, Tree) verwendbar. Die "echte" Tree-Variente müsste man dann noch mit reinflicken.



  • Evtl. kann man auch ein model n views mit einbauen, so zum zeigen (z.B. Liste und Tabelle).

    Oder z.B. gegen ende ein hauptmodell (tree) das als Tree angezeigt wird.
    Eine ListView die die erste Ebene anzeigt und auswählt, welche childs in einer tabelle angezeigt werden sollen...



  • Ich möchte euch nicht stoppen, aber...
    ...ich hätte gern einen bedarfsgetriebenen Ansatz.

    Damit will ich sagen, dass wenn der Bedarf nicht erkannt wird, auch die Technik zu seiner Befriedigung langweilig bleiben wird. Ihr wart doch auch in der Schule oder? Wie wurde da gelehrt? Haben die Schüler auch gestöhnt: Wozu brauchen wir das denn später mal?

    Merkt ihr worauf ich hinaus will?



  • Ich habe bisher alles davon in meinem Projekt benötigt :-) :-)

    Die Frage ist was ist der Bedarf für ein eigenes Model, d.h. warum schreibt man ein komplett eigenes Model und passt nicht ein bestehendes an?



  • Ja, klar. Aber das weiß ein Neueinsteiger ja noch nicht, und er fragt sich ggf. wozu diese "neuen" Konzepte. Und wir sollten das für ihn erfahrbar machen - meine ich.



  • Ein existierendes anpassen hats nur, wenn in dem projekt schon welche da sind.

    Aber dann sollten wir erst mal überlegen, was der grund für QTableView & model im gegensatz zu QTableWidget ist.

    1.) Daten können in eigenen strukturen gehalten werden --> wieder verwendung der Daten schicht (wenn's sowas gibt)
    2.) Zugriff auf die Daten ist einfacher (nicht immer TableWidget--> find --> get --> etc.)
    3.) Erweiterbarkeit (neue features, neue zeilen/spalten, ...)
    ... (spontan fällt mir gerade nix ein)



  • Für mich persönlich fallen die QxxxWidgets nicht unter den Punkt Model-View-Controller, das sind bequeme Klassen, die alles in einer Black-Box kapseln. Das ist prima für bestimmte Anwendungsfälle, hat aber wie gesagt für mich nichts mit MVC zu tun (wie's intern implementiert ist, tut da ja nichts zur Sache) - man hat (bis auf den Delegate) keinen Einfluss auf das Model und die View.

    Wenn wir über Model-View-Controller reden, fängt das bei mir mit einem eigenen Model an. Ggf. erweitert man eine View (habe ich auch schon gemacht, weil die Default-Implementierung für uns nicht passt). Je nach Anwendungsfall hat man noch 'nen Delegate für's optische.

    Die Frage ist auch, wo legt man das Einstiegslevel fest. Soll die Zielgruppe schon wissen, was MVC ist und wir vermitteln nur, wie man es mit Qt macht, oder müssen wir noch eine allgemeine Einführung dazu geben?

    Vor einer klaren Abgrenzung wann man QxxView + eigenes Model verwenden soll und wann QxxWidget würde ich abraten. In der IT hängt da zu vieles vom "kommt darauf an" ab. Man kann natürlich Vor- und Nachteile angeben, Anwendungsbeispiele, etc. Die Entscheidung kann einem aber niemand abnehmen. In unserer Anwendung verwenden wir beides, je nachdem was gerade gemacht werden muss, und wie es einfacher zu lösen ist.

    In diesem Zusammenhang wäre dann vielleicht ein eigenes Tutorial "Die QtxxWidget-Klassen erweitern" angebracht?



  • Das wäre ja schon fast ein kapitel für ein buch inzwischen :-)



  • Zum Einstiegslevel: Nicht bei Adam und Eva anfangen. MVC kann man ja mal mit drei Sätzen anreißen, aber Zielgruppe sollten Programmierer sein, nicht die Berufsschulklasse im 1. Lehrjahr.



  • Evtl kann man mal das design pattern dahinter erläutern, wäre ein einstieg, oder?



  • Ich will mal ganz und gar ehrlich sein. Das Pattern-Buch habe ich gelesen, das ist lang her. Als Katalog nützt es nicht wirklich zum Verständnis von Patterns im Allgemeinen. Später habe ich ein HeadFirst-Buch in die Hand bekommen, das Patterns (hauptsächlich mit Java-Bezug) erklärt. Mit dem bin ich zwar nicht durch (und zugegeben: es ist etwas flacher), aber durch diese Lektüre habe ich viel mehr behalten. Wirklich ein Lich ist mir dann mit dem "Büchlein von Helmut Leitner":http://www.mustertheorie.de/ aufgegangen, allerdings ist dieses dann wieder grundlegender.

    Was MVC betrifft, bin ich - praktisch gesehen - wohl eher ein Neuling oder vielleicht ein unbewusster Anwender (ja ihr könnt mich gern jetzt auspfeifen). Aber ich habe es ehrlich mehrmals versucht, den Stoff zu raffen. Ist dann ein bisschen wie höhere Mathematik für mich: hochtrabende bis verstiegene Terminologie und kaum eine helfende Hand die einem daraus entgegenragt...

    Deshalb würde ich auch einen Weg durch - simulierte - Erfahrung bevorzugen und von MVC überhaupt nur soviel hinein nehmen, dass es zum richtigen Anwenden von MV(D) mit Qt genügt. Theoretisch vollständig durchdringen kann man es ja später immer noch (und wird es bei ernsthafter Beschäftigung damit schließlich auch wollen).

    O, nun ist es doch wieder eine ganz lange Antwort geworden - und bevor ich mich nun an ein Thema heranwage, in dem ich sicherlich ganz schön ins Schwitzen (und Schwimmen) kommen werde, mach ich jetzt besser mal was anderes (das ich auch schon in Aussicht gestellt habe und noch schuldig bin: die "Vorzüge der Ausnahmebehandlung":http://developer.qt.nokia.com/groups/qt_german/wiki/Wo_Ausnahmebehandlung_echt_hilft erklären, zumindest eine Notiz hinterlassen)

    [edit] sehe gerade: MV-Stoffsammlung ist auch schon dort, gut! :)



  • [quote author="Panke" date="1294338902"]Zum Einstiegslevel: Nicht bei Adam und Eva anfangen. MVC kann man ja mal mit drei Sätzen anreißen, aber Zielgruppe sollten Programmierer sein, nicht die Berufsschulklasse im 1. Lehrjahr.[/quote] Dann versuch du mir mal diese Adam-und-Eva-Sache kurz und bündig zu verklickern. Eigentlich sah ich mich bislang nicht beratungsresistent ;) - nein wirklich, ganz ernthaft...



  • [quote author="Wolf P." date="1294348164"][quote author="Panke" date="1294338902"]Zum Einstiegslevel: Nicht bei Adam und Eva anfangen. MVC kann man ja mal mit drei Sätzen anreißen, aber Zielgruppe sollten Programmierer sein, nicht die Berufsschulklasse im 1. Lehrjahr.[/quote] Dann versuch du mir mal diese Adam-und-Eva-Sache kurz und bündig zu verklickern. Eigentlich sah ich mich bislang nicht beratungsresistent ;) - nein wirklich, ganz ernthaft...

    [/quote]

    Den Eindruck habe ich auch gar nicht. Mein Beitrag bezog sich auf Volkers Frage.

    bq. Die Frage ist auch, wo legt man das Einstiegslevel fest. Soll die Zielgruppe schon wissen, was MVC ist und wir vermitteln nur, wie man es mit Qt macht, oder müssen wir noch eine allgemeine Einführung dazu geben?

    Natürlich muss man einleitend ein paar Worte über MVC geben, wenn man ein Model-View-Framework beschreibt. Aber die Details, Diskussion der Vor- und Nachteile, Alternativen etc. sprengen meiner Meinung nach den Rahmen.

    Das heißt natürlich nicht, dass man eine schlechtere Alternative (QxxWidget) zuerst präsentieren kann, um das Problem zu veranschaulichen, dass das Framework lösen soll.



  • [quote author="Panke" date="1294350629"] Das heißt natürlich nicht, dass man eine schlechtere Alternative (QxxWidget) zuerst präsentieren kann, um das Problem zu veranschaulichen, dass das Framework lösen soll. [/quote] Genau darauf wollte ich hinaus!
    Ich glaube, dass ein An-die-Grenze-des-Machbaren-Stoßen wirklich stark motivieren kann.



  • Das Problem ist, wenn ich es will, kann ich mit QXxxWidget verdammt weit kommen, nur wird es irgendwann immer schwerer. Wenn ich aber leicht anfange damit, kann ich immer wa shinzubauen. Iregndwann komme ich aber an die Grenze, wo es mit dem MV(D) Ansatz (von Anfang an benutzt) deutlich eleganter und günstiger wird.

    Ich würde die Widgets gfleich weglassen in dem Tutorial. Ein Model ist im prinzip ganz einfach (ReadOnly, tabelle), wenn die Daten einmal gelesen werden und dann nur präsentiert.



  • Dann wäre es wohl gut, wir gingen dazu über, das von nun an als zwei Dinge zu betrachten.
    Was meint ihr?

    Das MV(D) sollte dann vielleicht besser ein anderer vorantreiben, bei mir käme es ins stocken, wobei ich es definitiv begleiten werde, Review, Diskussion, Verbesserungen usw.

    Das andere - das "Kaputt-Verbessern":http://de.wikipedia.org/wiki/Kaputt einer Widget-Lösung - würde ich dann übernehmen.


Log in to reply
 

Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.