SDA SE Wiki

Software Engineering for Smart Data Analytics & Smart Data Analytics for Software Engineering

User Tools

Site Tools


ACHTUNG! Das hie sind keine entgültig gesicherten Erkenntnisse
Wenn jemand bestätigen kann, das diese Aussagen richtig sind, kann er die Warnung bitte entfernen.


Was interessiert mich mein Geschwätz von Gestern :-) (s.u.) Die Lösung lag natürlich vor meinen Augen mitten in der Eclipse docu.

Ein contentprovider wird von einem Viewer benötigt um aus einem Input die zugehörigen Elemente zu extrahieren. Klingt platt, isses auch.

Weitere Einzelheuten gibts unter viewermetaphor.


Die folgenden beiden Beiträge können vermutlich gelöscht werden?



(Daniel:) Meine vorläufiges Verständnis sieht so aus: Viewer zeigen etwas an. Modelle modellieren einen Sachverhalt. Wenn jetzt ein Viewer ein Model anzeigen soll, muss ich entweder dem Viewer beibringen, welche Informationen er sich aus dem Model zu holen hat, oder dem Model beibringen, welche Informationen er dem Viewer bereitstellen soll. In beiden Fällen macht eine Klasse etwas, was nicht ihre eigentliche Aufgabe ist. Erschwerend kommt hinzu, dass vielleicht ein Modell in mehreren Views oder ein View mehrere Modelle darstellen soll. Da also eine Aufgabe zu erledigen ist, für die eigentlich keine Klasse zuständig ist, erfindet man einen neue Klasse, die diese Aufgabe übernimmt. Das sind die Contentprovider. Die Aufgabe könnte man vielleicht mit Zusammenstellung und Aufbereitung der Informationen aus einem Model zur Anzeige beschreiben. Klingt das plausibel? Weiß jemand, ob das wirklich so ist?



(Lukas:) Je mehr ich darüber nachdenke, desto merkwürdiger kommt mir das vor. Ok, die Idee liegt auf der Hand: Das Model brauch nichts anderes mehr zu machen als Daten zu modelieren, bzw. dem Drang, das Model View spezifisch zu designen, wird entgegengewirkt. Schönes Beispiel hierfür wären tablemodels und treemodels in JFC/Swing.
Trotzdem werd ich den Eindruck nicht los, daß hier einfach nur Komplexität hin- und hergeschoben, bzw. umbenannt wird: Wenn die von mir verwendeten Datenstrukturen sich nicht zu Darstellungszwecken ins tablemodel-Kostüm zwängen lassen, dann bau ich eben einen Adapter dazwischen und lass ihn das tablemodel Interface implementieren. Ich habe so ein Model - möglicherweise nicht ganz korrekt - immer als etwas angesehen, daß weiß wie es an bestimmte Daten rankommt, auch wenn diese in nicht-View-spezifischen Strukturen vorliegen. (z.B. Verzeichnisbaum als treemodel, oder resultset als tablemodel verpacken) Voilà, ein contentprovider. Nur ein neuer Name für einen alten Hut?
Naja… muß man sich vermutlich einfach ein bißchen reinfinden. Ich hab jedenfalls noch etwas Probleme damit zu entscheiden, wo welcher Code hingehört.

research/jtransformer/contentprovidermetaphor.txt · Last modified: 2018/05/09 01:59 (external edit)

SEWiki, © 2019