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:trash:viewermetaphor [2018/05/09 01:59] (current)
Line 1: Line 1:
 +
 +===== NOCH NICHT FERTIG! ​ =====
 +
 +
 +----
 +
 +Zunächst einmal unbedingt das hier lesen:\\ \\ [[http://​help.eclipse.org/​help21/​topic/​org.eclipse.platform.doc.isv/​guide/​jface_viewers.htm|http://​help.eclipse.org/​help21/​topic/​org.eclipse.platform.doc.isv/​guide/​jface_viewers.htm]]\\ \\ 
 +Danach sollte schon einiges klarer sein. 
 +
 +Ich habe via google einen französichen [[powerpoint|powerpoint]] Vortrag gefunden, der beinhaltete u.a. diese nette skizze:
 +
 +
 +
 +In diesem Beispiel sind sowohl [[inputmetaphor|Input]] als auch [[domainobjectmetaphor|Domain Objects]] vom Typ File. Ein solcher Viewer könnte beispielsweise benutzt werden um Verzeichnisbäume anzuzeigen. Die einzelnen Rollen wären wie folgt verteilt:
 +
 +
 +  *der [[contentprovidermetaphor|Content Provider]] übergibt dem Viewer zu gegebenem [[inputmetaphor|Input]] (z.B. einem Verzeichnis) ​
 + alle darin enthaltenen [[domainobjectmetaphor|Elemente]] (z.B. andere Verzeichnisse oder Dateien). ​
 +  *der [[labelprovidermetaphor|Label Provider]] wird vom Viewer benötigt, um zu den einzelnen Elementen eine Beschrifftung (d.h. sinvollerweise den Dateinamen) und/oder ein entsprechendes Icon (z.B. abhängig vom Mime-Type) zu erhalten, die er dann in das SWT Widget stecken kann.
 +
 +Daraus folgt schonmal:
 +
 +
 +  *Eine Viewer Implementation ist - anders als beim Model/View Pattern - nicht auf ein bestimmtes Model Interface angewiesen.
 +  *==> Datenstrukturen brauchen kein besonderes Interface zu implementieren
 +  *Um das "Wie komme ich an die infos?"​ kümmern sich [[contentprovidermetaphor|Content Provider]] und [[labelprovidermetaphor|Label Provider]]Das ist noch nichts besonderes (soweit ich das sehe), sondern nur eine Verschiebung der Komplexitäten,​ verglichen mit 
 +gebräuchlichen MVC Situationen.**Besser als das "​normale"​ MVC-Pattern?​**//​Meine Empfehlung an alle, die sich jetzt (wie ich teilweise auch) fragen, was daran toller sein soll als wie gehabt ein Model vor allem als Wrapper um bestehende Datenstrukturen anzusehen: Nicht besser, anders! Es mag Vor- und/oder Nachteile geben, aber darum geht es ja noch gar nicht.//
 +Unterschiede gibt es nämlich schon: ​
 +  *Bei MVC liegt bereits auf der Interface Ebene (bzw. zur //​Kompilierzeit//​)fest,​ ob ein Objekt als Model in Frage kommt.
 +  *Einem Viewer kann man zunächst einmal alles mögliche als [[inputmetaphor|Input]] unterjubeln. Ob der dann etwas damit anfangen kann, entscheidet sich zur //​Laufzeit//​Will sagen wenn [[contentprovidermetaphor|Content Provider]] und [[labelprovidermetaphor|Label Provider]] etwas mit dem Zeugs anfangen können: Gut. Sonst: So mittel. Im Zweifelsfall kann immer noch eine Leere Tabelle angezeigt werden. ;-)\\ 
 +So richtig entfalten kann sich die mächtigkeit des ganzen Konzepts allerdings erst in Verbindung mit den an jeder Ecke verwendeten [[adaptermetaphor|Adaptern]].
 +
 +
 +
 +
 +
 +
 +
 +
 +
 +
 +
 +
 +
 +Details folgen.
 +
 +
 +=== Attachments ===
 +  * {{viewermetaphor.test_html_356652be.png?​32|test_html_356652be.png}} test_html_356652be.png
  
research/jtransformer/trash/viewermetaphor.txt · Last modified: 2018/05/09 01:59 (external edit)

SEWiki, © 2019