SDA SE Wiki

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

User Tools

Site Tools


Differences

This shows you the differences between two versions of the page.

Link to this comparison view

research:jtransformer:contentprovidermetaphor [2018/05/09 01:59] (current)
Line 1: Line 1:
 +**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 [[http://​help.eclipse.org/​help21/​topic/​org.eclipse.platform.doc.isv/​guide/​jface_viewers.htm|docu]].\\ ​
 +
 +Ein [[contentprovider|contentprovider]] wird von einem [[viewermetaphor|Viewer]] benötigt um aus einem [[inputmetaphor|Input]] die zugehörigen [[domainobjectmetaphor|Elemente]] zu extrahieren. Klingt platt, isses auch. \\ \\ 
 +Weitere Einzelheuten gibts unter [[viewermetaphor|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|tablemodels]] und [[treemodels|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|tablemodel]]-Kostüm zwängen lassen, dann bau ich eben einen Adapter dazwischen und lass ihn das [[tablemodel|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|treemodel]],​ oder [[resultset|resultset]] als [[tablemodel|tablemodel]] verpacken) Voilà, ein [[contentprovider|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