Workspace-Viewer: Unterschied zwischen den Versionen
Camhy (Diskussion | Beiträge) |
Osiris (Diskussion | Beiträge) |
||
(25 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt) | |||
Zeile 1: | Zeile 1: | ||
Der Workspace Viewer für den MLTutor sollte als Projekt im Rahmen der LV Applikationssoftware für Fortgeschrittene entwickelt werden. Diese Seite beinhalten meine ersten Entwicklungsgedanken und einiges an Kommunikation mit den Kollegen. |
|||
Dieses Projekt wurde jedoch bald eingestellt und David programmierte den Workspace Viewer. |
|||
--[[User:Osiris|Osiris]] 14:02, 10 June 2006 (CEST) |
|||
==Grundlagen== |
==Grundlagen== |
||
Zeile 12: | Zeile 19: | ||
Ich ([[User:Osiris|Osiris]]) möchte verstärkt XP-Techniken einsetzten: |
Ich ([[User:Osiris|Osiris]]) möchte verstärkt XP-Techniken einsetzten: |
||
* Incremental Design |
* Incremental Design |
||
* Unit Tests wo möglich/wichtig<br> |
* Unit Tests wo möglich/wichtig <br> und zwar mit TDD (Test Driven Design) und nicht im Nachhinein |
||
und zwar mit TDD (Test Driven Design) und nicht im Nachhinein |
|||
Zeile 23: | Zeile 29: | ||
* Anzeigen einer Übersicht aller im Workspace momentan vorhandenen Variablen |
* Anzeigen einer Übersicht aller im Workspace momentan vorhandenen Variablen |
||
* Anzeigen der Details von Variablen, ändern des Inhalts? |
* Anzeigen der Details von Variablen, ändern des Inhalts? |
||
* Export und Import von Variablen (*.mat Files) |
* Export und Import von Variablen (*.mat Files)? |
||
Weitere Anforderungen: |
Weitere Anforderungen: |
||
* Flexibilität in Hinblick auf eventuelle Änderungen der XML-Files (Matlab Versionsumstellung) |
* Flexibilität in Hinblick auf eventuelle Änderungen der XML-Files (Matlab Versionsumstellung) |
||
* Datentransfer zwischen Server und Client möglichst gering halten |
|||
* Viewer soll auch in einer Eclipse RCP-Anwendung eingesetzt werden können |
|||
==Design== |
|||
===Packages=== |
|||
(Noch keine endgültigen Namen, nur für eine grobe Aufteilung) |
|||
* <tt>matlabworkspaceviewer.'''filehandling'''</tt> <br> Zuständig für das Auslesen und Schreiben der XML-Files |
|||
* <tt>matlabworkspaceviewer.'''viewer'''</tt> <br> Der eigentliche Viewer |
|||
* <tt>matlabworkspaceviewer.'''updater'''</tt> <br> Schnittstelle zwischen dem Viewer und dem "restlichen ML-Tutor" |
|||
* <tt>matlabworkspaceviewer.'''vareditor'''</tt> <br> Editor für die Variablen (eventuell) |
|||
: <span style="color:#00AA88">Nur eine kleine Anmerkung: Es ist bei den Eclipse Plugins üblich den Domainnamen verkehrt in den Plugin- bzw. Packagenamen mitzuführen also z.B. könnte das Plugin <tt>at.tugraz.itp.matlabworkspaceviewer</tt> heißen und die Packages dann auch dementsprechend. --[[User:Camhy|Camhy]] 13:02, 23 Oct 2005 (CEST)</span> |
|||
:: Wie sich die Packages in die Hierachie eingliedern müssen wir sowieso noch schauen. Ich hab diesbezüglich sowieso noch ein paar Fragen, die automatisch beantwortet werden, wenn ich den Projektaufbau sehe. |
|||
===Handling der XML-Files=== |
|||
(Noch keine endgültigen Namen, nur für eine grobe Aufteilung) |
|||
====Klassen==== |
|||
Für diese Anwendung bietet sich ein Sax-Parser an. Für das Auslesen eines XML-Files müssen sicher folgende Klassen geschrieben werden: |
|||
* <tt>'''FileReader'''</tt> |
|||
* <tt>'''FileWriter'''</tt> |
|||
* <tt>'''ContentHandler'''</tt> |
|||
* <tt>'''ErrorHandler'''</tt> |
|||
Eventuell dazu noch ein Interface |
|||
Zu importierende Klassen: |
|||
import javax.xml.parsers.SAXParserFactory; |
|||
import javax.xml.parsers.SAXParser; |
|||
import javax.xml.parsers.ParserConfigurationException; |
|||
import org.xml.sax.XMLReader; |
|||
import org.xml.sax.ErrorHandler; |
|||
import org.xml.sax.SAXException; |
|||
import org.xml.sax.SAXParseException; |
|||
import org.xml.sax.helpers.DefaultHandler; |
|||
import org.xml.sax.Attributes; |
|||
====File einlesen==== |
|||
Prinzipieller Ablauf für das Lesen eines Files: |
|||
SAXParserFactory factory = SAXParserFactory.newInstance(); |
|||
SAXParser saxParser = factory.newSAXParser(); |
|||
XMLReader xmlReader = saxParser.getXMLReader(); |
|||
content_handler = new ContentHandler(); |
|||
xmlReader.setContentHandler(content_handler); |
|||
XMLErrorHandler error_handler = new ErrorHandler(); |
|||
xmlReader.setErrorHandler(error_handler); |
|||
xmlReader.parse(filename); |
|||
====File schreiben==== |
|||
Ganz gewöhnlich Strings zusammenstoppeln und in ein File schreiben. |
|||
Zeile 33: | Zeile 93: | ||
# Einlernen in Eclipse und Pluginentwicklung für Eclipse |
# Einlernen in Eclipse und Pluginentwicklung für Eclipse |
||
# Definition der Schnittstellen |
# Definition der Schnittstellen |
||
# Grobplanung |
# Grobplanung |
||
# Entwicklung der Klassen zum Auslesen des XML-Files |
# Entwicklung der Klassen zum Auslesen des XML-Files |
||
# Entwicklung der Oberfläche |
# Entwicklung der Oberfläche |
||
## Zuerst einfache Darstellung eines Files |
## Zuerst einfache Darstellung eines Files |
||
## Dann Einbindung mit der entgültigen Funktionalität |
## Dann Einbindung mit der entgültigen (Anzeige-)Funktionalität |
||
## Eventuell Editor für die Variablen |
|||
== |
==Fragen== |
||
(Antworten der anderen Mitarbeiter in <span style="color:#00AA88">Farbe</span>) |
(Antworten der anderen Mitarbeiter in <span style="color:#00AA88">Farbe</span>) |
||
===Offene=== |
|||
* Wie sehen die Schnittstellen zum ML-Tutor aus (genaue Definition) |
* Wie sehen die Schnittstellen zum ML-Tutor aus (genaue Definition) |
||
: <span style="color:#00AA88">Vorläufig (bis die Schnittstellen stehen): Der erstellte View wird in der MLTutor Perspektive dargestellt. Er sollte irgendeine Funktion beinhalten, die eine Variable mit dem Inhalt der Variablen als Parameter übernimmt und dann den View updated. Wenn Variablen im View editiert werden, sollte eine Funktion der restlichen Plugins aufgerufen werden, die die geänderten Variablen wieder an Matlab zurückgibt. Dh. der Workspace Viewer sollte eine XML-Ausgabe produzieren, die der Definition entspricht und von Matlab wieder eingelesen werden kann und diese einer Funktion der restlichen Plugins übergeben |
|||
<span style="color:#00AA88"> |
|||
Vorläufig (bis die Schnittstellen stehen): Der erstellte View wird in der MLTutor Perspektive dargestellt. Er sollte irgendeine Funktion beinhalten, die eine Variable mit dem Inhalt der Variablen als Parameter übernimmt und dann den View updated. Wenn Variablen im View editiert werden, sollte eine Funktion der restlichen Plugins aufgerufen werden, die die geänderten Variablen wieder an Matlab zurückgibt. Dh. der Workspace Viewer sollte eine XML-Ausgabe produzieren, die der Definition entspricht und von Matlab wieder eingelesen werden kann und diese einer Funktion der restlichen Plugins übergeben |
|||
</span> |
</span> |
||
* Soll eine DTD zur Validierung geschrieben werden? <br> Damit könnten fehlerhaft erstellte/übertragene Files "abgefangen" werden. |
|||
: <span style="color:#00AA88">Es gibt eigentlich ein fertiges Schema (wahrscheinlich sogar leichter zu validieren, als eine DTD, da man genauere Einschränkungen machen kann) für jede Art XML-File, die im Programm vorkommt. Beim konkreten ist aber noch einiges nachzubessern, um der aktuellen Version gerecht zu werden. Kannst aber auch gern eine DTD schreiben, wenn das für dich besser ist, wär aber natürlich eine doppelte Arbeit, da das Schema schon fast fertig ist.</span> |
|||
: <span style="color:#00AA88">Meiner Meinung nach interessanter Ansatz ist auf [http://www.xmlmodeling.com/hyperModel/index.html http://www.xmlmodeling.com/hyperModel/index.html] zu finden. Hab teilweise mit ArgoUML modelliert und anschließend in ein Schema gewandelt. Das Plugin hat bei mir jedoch nicht unter Eclipse 3.1 funktioniert. Weiß nicht, ob sie es schon upgedated haben. (Nachtrag: Läuft schon..) Wär cool wenn der Schema Test dann miteingebaut werden könnte. Dann könnte man das was von Matlab kommt immer auf Sinnhaftigkeit überprüfen. Ist zwar keine Benutzereingabe, wo das mehr Sinn macht, aber man könnte es as so etwas ähnliches wie einen unittest für die Matlab-Skripte sehen, wenn man z.B. alle Variablenarten durchspielt. Übertragungsfehler könnte man damit natürlich auch ausschließen, wobei diese wahrscheinlich eh schon vom XML-Parser bemerkt werden..</span> |
|||
: <span style="color:#00AA88">Natürlich wäre es auch schön das Schema auf genauere regular Expression - Überprüfungen zu erweitern. [http://www.informit.com/articles/article.asp?p=31285&seqNum=1 http://www.informit.com/articles/article.asp?p=31285&seqNum=1]</span> |
|||
: <span style="color:#00AA88">Solche Dinge sind daweil nur rudimentär eingebaut. |
|||
</span> |
|||
:: Auf DTD bin ich nur gekommen, da ich bisher mit dem SAX-Parser immer mit DTDs validiert hab. Wenn das auch mit einem Schema geht wär's natürlich besser, nachdem es dieses schon gibt. Ich würde nur ungern auf eine Validierung komplett verzichten. |
|||
:: --[[User:Osiris|Osiris]] 17:35, 22 Oct 2005 (CEST) |
|||
:::<span style="color:#00AA88">VIEL besserer Link für unsere Zwecke: [http://www.eclipse.org/xsd/ http://www.eclipse.org/xsd/] --[[User:Camhy|Camhy]] 18:31, 22 Oct 2005 (CEST) |
|||
</span> |
|||
::::Das ist aber nur für das Handling von Schematas, oder überseh ich da was? --[[User:Osiris|Osiris]] 17:44, 23 Oct 2005 (CEST) |
|||
:::::<span style="color:#00AA88">Direkter Link auf Xerces - wird von der obigen Seite verwiesen. [http://xml.apache.org/xerces2-j/ http://xml.apache.org/xerces2-j/]. emf/xsd Projekt kann durch dessen Verwendung im [http://eclipse.org/webtools/index.html WTP] insofern sehr hilfreich sein, da damit das Schema auch direkt in Eclipse bearbeitet werden kann. Wollte aber eigentlich eh direkt auf WTP und Xerces verweisen, tut mir leid. Apropos: Aus [http://sourceforge.net/projects/xmen X-Men] hab ich einigen Source gezogen, um die Editoren für die anderen Files zu erstellen. Zur Nutzung muss aber org.apache.xerces als Plugin installiert sein, was glaube ich aber sowieso bei der WTP dabei ist. --[[User:Camhy|Camhy]] 14:09, 24 Oct 2005 (CEST) </span> |
|||
* Ist das Matlab-eigene Fileformat (*.mat Files) zum Exportieren von Variablen frei? (höchstwahrscheinlich blöde Frage, aber es könnt ja sein) |
|||
: <span style="color:#00AA88">Ich denke schon.. Nachbasteln darf man es meiner Ansicht nach sowieso immer </span> |
|||
===Beantwortete=== |
|||
* Funktionsweise der Datenübertragung / des Updatens |
* Funktionsweise der Datenübertragung / des Updatens |
||
: <span style="color:#00AA88">Nur kurz einmal: Im Endeffekt wird bei der ersten Ausführung eines Matlab Programms eine Pipe zu Matlab geöffnet, die solange offen bleiben soll, bis entweder der Benutzer durch einen Matlab Befehl das Programm schließt, oder die Anwendung beendet wird. Es können beliebige Matlab Befehle durch die Pipe geschickt werden und der Output wird jeweils ausgelesen. Es gibt eine Matlab-Funktion, die mit einem Variablennamen aufgerufen wird und diese Variable dann als XML-Text ausgibt. Dh. man müsste eine Matlab-Funktion zur Verfügung stellen, die alle vorhandenen Variablen anzeigt und diese dann nacheinander als XML-Text ausgibt. Dieser Output müsste dann vom Workspace-Viewer gelesen und in einem Eclipse View dargestellt werden. Wie das mit dem Update des Views ausschaut, müsste man sich noch überlegen. Vielleicht wäre ein vom Benutzer ausgelöstes Refresh gar nicht so schlecht. |
|||
<span style="color:#00AA88"> |
|||
Nur kurz einmal: Im Endeffekt wird bei der ersten Ausführung eines Matlab Programms eine Pipe zu Matlab geöffnet, die solange offen bleiben soll, bis entweder der Benutzer durch einen Matlab Befehl das Programm schließt, oder die Anwendung beendet wird. Es können beliebige Matlab Befehle durch die Pipe geschickt werden und der Output wird jeweils ausgelesen. Es gibt eine Matlab-Funktion, die mit einem Variablennamen aufgerufen wird und diese Variable dann als XML-Text ausgibt. Dh. man müsste eine Matlab-Funktion zur Verfügung stellen, die alle vorhandenen Variablen anzeigt und diese dann nacheinander als XML-Text ausgibt. Dieser Output müsste dann vom Workspace-Viewer gelesen und in einem Eclipse View dargestellt werden. Wie das mit dem Update des Views ausschaut, müsste man sich noch überlegen. Vielleicht wäre ein vom Benutzer ausgelöstes Refresh gar nicht so schlecht. |
|||
</span> |
</span> |
||
:<span style="color:#00AA88">Aber: Als erster Schritt wäre es wahrscheinlich einmal einfacher zum Testen einen Eclipse-Editor zu schreiben, der auf eine bestimmte Dateiendung reagiert und das ausgewählte File einmal darstellt. Dieses dann mit der Pipe-Funktionalität zu versehen und in einen View umzubasteln, in dem mehrere Variablen angezeigt werden, wäre dann wahrscheinlich kein allzu großes Problem mehr. |
|||
<span style="color:#00AA88"> |
|||
Aber: Als erster Schritt wäre es wahrscheinlich einmal einfacher zum Testen einen Eclipse-Editor zu schreiben, der auf eine bestimmte Dateiendung reagiert und das ausgewählte File einmal darstellt. Dieses dann mit der Pipe-Funktionalität zu versehen und in einen View umzubasteln, in dem mehrere Variablen angezeigt werden, wäre dann wahrscheinlich kein allzu großes Problem mehr. |
|||
</span> |
</span> |
||
So eine Aufteilung finde ich auch auf jeden Fall sinnvoll. |
:: So eine Aufteilung finde ich auch auf jeden Fall sinnvoll. |
||
--[[User:Osiris|Osiris]] 19:22, 21 Oct 2005 (CEST) |
::--[[User:Osiris|Osiris]] 19:22, 21 Oct 2005 (CEST) |
||
* Unit Tests erwünscht/erbeten/notwendig/üblich oder eher nicht (schwierig bei der Oberfläche) |
* Unit Tests erwünscht/erbeten/notwendig/üblich oder eher nicht (schwierig bei der Oberfläche) |
||
: <span style="color:#00AA88">Schwer zu sagen, üblich sind sie leider nicht, da es so lange dauert sie zu schreiben. Es gibt ca. zu einem drittel der Funktionen unittests od. unittest-ähnliche Konstrukte. In diesem Fall würde es wahrscheinlich reichen, wenn man alle Variablenarten durchspielt und dann händisch die Anzeige der Variablen überprüft. |
|||
<span style="color:#00AA88"> |
|||
Schwer zu sagen, üblich sind sie leider nicht, da es so lange dauert sie zu schreiben. Es gibt ca. zu einem drittel der Funktionen unittests od. unittest-ähnliche Konstrukte. In diesem Fall würde es wahrscheinlich reichen, wenn man alle Variablenarten durchspielt und dann händisch die Anzeige der Variablen überprüft. |
|||
</span> |
</span> |
||
Ich würd' sie aber nicht schlecht finden. Was den Zeitaufwand betrifft, würd ich das nicht so sagen (zitiere meine Freundin: "'''TDD ist nicht langwierig!!!'''". Natürlich ist mehr Code zu schreiben, wenn man Code und Tests zugleich entwickelt, aber dafür fällt die komplette Testphase weg und lange Fehlersuchen gibt's auch nicht. (lang kommt es einem nur vor, wenn man die Tests nachher schreibt, aber das ist ja kein TDD) |
:: Ich würd' sie aber nicht schlecht finden. Was den Zeitaufwand betrifft, würd ich das nicht so sagen (zitiere meine Freundin: "'''TDD ist nicht langwierig!!!'''". Natürlich ist mehr Code zu schreiben, wenn man Code und Tests zugleich entwickelt, aber dafür fällt die komplette Testphase weg und lange Fehlersuchen gibt's auch nicht. (lang kommt es einem nur vor, wenn man die Tests nachher schreibt, aber das ist ja kein TDD) |
||
Blöd ist nur, dass sich GUIs schwer testen lassen (da gibt's aber auch was). Aber z.B. das komplette XML-File Auslesen und das Datenhandling ließen sich wunderbar überprüfen. |
:: Blöd ist nur, dass sich GUIs schwer testen lassen (da gibt's aber auch was). Aber z.B. das komplette XML-File Auslesen und das Datenhandling ließen sich wunderbar überprüfen. |
||
Die Vorteile von TDD würden bei uns voll zum Tragen kommen, insbesondere ist es sehr brauchbar, dass der Code automatisch dokumentiert und abgesichert wäre (und zukünftige Erweiterungen eventuell durch andere Programmierer sind ja nicht so unwahrscheinlich). |
:: Die Vorteile von TDD würden bei uns voll zum Tragen kommen, insbesondere ist es sehr brauchbar, dass der Code automatisch dokumentiert und abgesichert wäre (und zukünftige Erweiterungen eventuell durch andere Programmierer sind ja nicht so unwahrscheinlich). |
||
Außerdem werd' ich ja auch in Eclipse entwickeln, und das mach Entwickeln mit Unit Tests ja noch einfacher als es ohnehin schon ist. |
:: Außerdem werd' ich ja auch in Eclipse entwickeln, und das mach Entwickeln mit Unit Tests ja noch einfacher als es ohnehin schon ist. |
||
Also wenn nicht unbedingt unheimlich schnell etwas Code brauchst, würd ich gerne TDD anwenden, wo es direkt möglich ist. Wenn dies jedoch nicht erwünscht wäre, dann eben nicht, ich hab mich da nicht so drauf versteift. |
:: Also wenn nicht unbedingt unheimlich schnell etwas Code brauchst, würd ich gerne TDD anwenden, wo es direkt möglich ist. Wenn dies jedoch nicht erwünscht wäre, dann eben nicht, ich hab mich da nicht so drauf versteift. |
||
--[[User:Osiris|Osiris]] 19:11, 21 Oct 2005 (CEST) |
:: --[[User:Osiris|Osiris]] 19:11, 21 Oct 2005 (CEST) |
||
::: <span style="color:#00AA88">Natürlich wär das super, gib dir in allem völlig recht. Bei mir hat einfach die Zeit/Motivation oft nicht ausgereicht, um das auf diese Art anzugehen. Wäre spitze, wenn du das so schreiben könntest. Wenn du das was über GUI-Tests herausfindest, wärs natürlich auch super.. |
|||
<span style="color:#00AA88"> |
|||
Natürlich wär das super, gib dir in allem völlig recht. Bei mir hat einfach die Zeit/Motivation oft nicht ausgereicht, um das auf diese Art anzugehen. Wäre spitze, wenn du das so schreiben könntest. Wenn du das was über GUI-Tests herausfindest, wärs natürlich auch super.. |
|||
</span> |
</span> |
||
Mir fällt gerade ein, dass die genaue Update-Strategie und das Erhalten der Variablen dem Viewer ja eigentlich egal sind. Er sollte meiner Meinung nach lediglich die Funktionalitäten zur Verfügung stellen um Variablen hinzuzufügen, alles neu aufzubauen, alles zu löschen, ... |
:: Mir fällt gerade ein, dass die genaue Update-Strategie und das Erhalten der Variablen dem Viewer ja eigentlich egal sind. Er sollte meiner Meinung nach lediglich die Funktionalitäten zur Verfügung stellen um Variablen hinzuzufügen, alles neu aufzubauen, alles zu löschen, ... |
||
Was dargestellt werden soll, wird durch den ML-Tutor oder ein eigenes Updater-Modul bestimmt. Letzteres hätte den Vorteil, dass man über ein geschickt gemachtes Interface auch andere Module als den Workspace-Viewer damit ansprechen könnte. (Das ist jetzt aber kein Versuch das Updaten nicht machen zu müssen ;-) |
:: Was dargestellt werden soll, wird durch den ML-Tutor oder ein eigenes Updater-Modul bestimmt. Letzteres hätte den Vorteil, dass man über ein geschickt gemachtes Interface auch andere Module als den Workspace-Viewer damit ansprechen könnte. (Das ist jetzt aber kein Versuch das Updaten nicht machen zu müssen ;-) |
||
--[[User:Osiris|Osiris]] 19:34, 21 Oct 2005 (CEST) |
:: --[[User:Osiris|Osiris]] 19:34, 21 Oct 2005 (CEST) |
||
<span style="color:#00AA88"> |
::: <span style="color:#00AA88">Versteh ich nicht ganz.. Meinst du das updaten der aktuell vorhandenen Variablen? |
||
Versteh ich nicht ganz.. Meinst du das updaten der aktuell vorhandenen Variablen? |
|||
</span> |
</span> |
||
:::: Ja. |
|||
* Soll eine DTD zur Validierung geschrieben werden?<br> |
|||
:::: Wie ich deiner Beschreibung der Schnittstelle (s.o.) entnehmen kann, haben wir diesbezüglich das selbe Bild vor Augen. Mir ist es nur darum gegangen, dass sich der Viewer nicht darum kümmern soll wie er die darzustellenden Variablen aus Matlab bekommt. |
|||
Damit könnten fehlerhaft erstellte/übertragene Files "abgefangen" werden. |
|||
:::: Mit einem Update-Modul meine ich ein eigenes Modul welches nur für das Updaten zuständig ist. Damit könnte man ein flexibleres (und überhaupt schöneres) Design erreichen. |
|||
<span style="color:#00AA88"> |
|||
* <span style="color:#00AA88"> Wie füge ich denn Benutzernamen und Zeit so schön ins Wiki ein? |
|||
Es gibt eigentlich ein fertiges Schema (wahrscheinlich sogar leichter zu validieren, als eine DTD, da man genauere Einschränkungen machen kann) für jede Art XML-File, die im Programm vorkommt. Beim konkreten ist aber noch einiges nachzubessern, um der aktuellen Version gerecht zu werden. Kannst aber auch gern eine DTD schreiben, wenn das für dich besser ist, wär aber natürlich eine doppelte Arbeit, da das Schema schon fast fertig ist. |
|||
Meiner Meinung nach interessanter Ansatz ist auf [http://www.xmlmodeling.com/hyperModel/index.html http://www.xmlmodeling.com/hyperModel/index.html] zu finden. Hab teilweise mit ArgoUML modelliert und anschließend in ein Schema gewandelt. Das Plugin hat bei mir jedoch nicht unter Eclipse 3.1 funktioniert. Weiß nicht, ob sie es schon upgedated haben. (Nachtrag: Läuft schon..) Wär cool wenn der Schema Test dann miteingebaut werden könnte. Dann könnte man das was von Matlab kommt immer auf Sinnhaftigkeit überprüfen. Ist zwar keine Benutzereingabe, wo das mehr Sinn macht, aber man könnte es as so etwas ähnliches wie einen unittest für die Matlab-Skripte sehen, wenn man z.B. alle Variablenarten durchspielt. Übertragungsfehler könnte man damit natürlich auch ausschließen, wobei diese wahrscheinlich eh schon vom XML-Parser bemerkt werden.. |
|||
Natürlich wäre es auch schön das Schema auf genauere regular Expression - Überprüfungen zu erweitern. [http://www.informit.com/articles/article.asp?p=31285&seqNum=1 http://www.informit.com/articles/article.asp?p=31285&seqNum=1] |
|||
Solche Dinge sind daweil nur rudimentär eingebaut. |
|||
</span> |
</span> |
||
: Mit <tt><nowiki>~~~~</nowiki></tt> kommen Benutzername und Zeit, mit <tt><nowiki>~~~</nowiki></tt> nur der Benutzername rein. |
|||
: Ich verwend im Wiki-Editorfenster immer den zweiten Button von rechts, der macht immer noch zwei <tt>--</tt> vorne dazu. |
|||
:: <span style="color:#00AA88">Hihi, hätt ich sehen müssen, schreib die Texte immer mit externem Editor <br> --[[User:Camhy|Camhy]] 18:31, 22 Oct 2005 (CEST)</span> |
|||
* Gibt's im ML-Tutor irgendwelche gröberen Abweichungen von den im Eclipse üblichen Sachen (Build-Prozess, ...)? <br>Ich glaub die Frage ersetzt viele andere :-) |
|||
* <span style="color:#00AA88"> Wie füge ich denn Benutzernamen und Zeit so schön ins Wiki ein? |
|||
: <span style="color:#00AA88"> Nein, eigentlich gar keine. Das einzige was man vielleicht im Hinterkopf haben sollte, ist, dass es im Endeffekt möglich sein sollte, diesen auch in einer Eclipse RCP-Anwendung einzusetzen (Viewer für die Beispiele). Man kann jedoch fast jedes Plugin im Endeffekt dazu "überreden", auch dort zu funktionieren. Ist aber glaube ich einfacher, zuerst nicht so viel darauf zu achten. [http://www.eclipse.org/articles/Article-RCP-1/tutorial1.html Eclipse RCP Tutorial] --[[User:Camhy|Camhy]] 13:02, 23 Oct 2005 (CEST) |
|||
</span> |
</span> |
||
==Benötigte Ressourcen== |
==Benötigte Ressourcen== |
||
* Die Schemata |
|||
* Zugang zum Subversion-Repository (primär um den Aufbau zu sehen, entwickeln kann ich einige Zeit auch lokal --[[User:Osiris|Osiris]] 18:01, 23 Oct 2005 (CEST)) |
|||
==Interessante Links== |
==Interessante Links== |
||
Zeile 106: | Zeile 191: | ||
[http://eclipse.org/articles/Article-VE-Custom-Widget/customwidget.html http://eclipse.org/articles/Article-VE-Custom-Widget/customwidget.html] Habs bis jetzt noch nicht geschafft, dieses Tutorial auszuprobieren. Würde eigentlich gerne alle meine GUI-Komponenten so schreiben <br> |
[http://eclipse.org/articles/Article-VE-Custom-Widget/customwidget.html http://eclipse.org/articles/Article-VE-Custom-Widget/customwidget.html] Habs bis jetzt noch nicht geschafft, dieses Tutorial auszuprobieren. Würde eigentlich gerne alle meine GUI-Komponenten so schreiben <br> |
||
[http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/pde-ui-home/working/EclipseForms/EclipseForms.html Eclipse Forms] Weiß nicht, ob es überhaupt Sinn macht in diesem Fall einen Forms-basierten Editor-Viewer zu bauen <br> |
[http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/pde-ui-home/working/EclipseForms/EclipseForms.html Eclipse Forms] Weiß nicht, ob es überhaupt Sinn macht in diesem Fall einen Forms-basierten Editor-Viewer zu bauen <br> |
||
[http://www.informit.com/articles/article.asp?p=31285&seqNum=1 http://www.informit.com/articles/article.asp?p=31285&seqNum=1] Regular Expressions in XML-Schema |
[http://www.informit.com/articles/article.asp?p=31285&seqNum=1 http://www.informit.com/articles/article.asp?p=31285&seqNum=1] Regular Expressions in XML-Schema <br> |
||
[http://www.eclipse.org/xsd/ XML Schema Klassen in Eclipse] <br> |
|||
[http://www.xmlmodeling.com/hyperModel/index.html http://www.xmlmodeling.com/hyperModel/index.html Hypermodel] <br> |
|||
[http://www.xmlmodeling.com/hyperModel/index.html Hypermodel] <br> |
|||
[http://www.eclipse.org/articles/Article-RCP-1/tutorial1.html Eclipse RCP Tutorial] |
|||
Grundlegendes zur Programmierung: <br> |
|||
[http://help.eclipse.org/help30/index.jsp?topic=/org.eclipse.platform.doc.isv/reference/misc/naming.html Naming Conventions] <br> |
|||
[http://java.sun.com/docs/codeconv/ Code Conventions for the Java Programming Language] |
Aktuelle Version vom 10. Juni 2006, 12:02 Uhr
Der Workspace Viewer für den MLTutor sollte als Projekt im Rahmen der LV Applikationssoftware für Fortgeschrittene entwickelt werden. Diese Seite beinhalten meine ersten Entwicklungsgedanken und einiges an Kommunikation mit den Kollegen.
Dieses Projekt wurde jedoch bald eingestellt und David programmierte den Workspace Viewer.
--Osiris 14:02, 10 June 2006 (CEST)
Inhaltsverzeichnis
Grundlagen
Eclipse
Datenaustausch
Bei der ersten Ausführung eines Matlab Programms wird eine Pipe zu Matlab geöffnet, die solange offen bleiben soll, bis entweder der Benutzer durch einen Matlab Befehl das Programm schließt, oder die Anwendung beendet wird. Es können beliebige Matlab Befehle durch die Pipe geschickt werden und der Output wird jeweils ausgelesen. Es gibt eine Matlab-Funktion, die mit einem Variablennamen aufgerufen wird und diese Variable dann als XML-Text ausgibt.
Softwareentwicklungsprozess
Ich (Osiris) möchte verstärkt XP-Techniken einsetzten:
- Incremental Design
- Unit Tests wo möglich/wichtig
und zwar mit TDD (Test Driven Design) und nicht im Nachhinein
Ziel
Ein an den Workspace-Viewer von Matlab angelehnter Viewer als Eclipse-Plugin.
Folgende Funktionalitäten sollen zur Verfügung gestellt werden:
- Anzeigen einer Übersicht aller im Workspace momentan vorhandenen Variablen
- Anzeigen der Details von Variablen, ändern des Inhalts?
- Export und Import von Variablen (*.mat Files)?
Weitere Anforderungen:
- Flexibilität in Hinblick auf eventuelle Änderungen der XML-Files (Matlab Versionsumstellung)
- Datentransfer zwischen Server und Client möglichst gering halten
- Viewer soll auch in einer Eclipse RCP-Anwendung eingesetzt werden können
Design
Packages
(Noch keine endgültigen Namen, nur für eine grobe Aufteilung)
- matlabworkspaceviewer.filehandling
Zuständig für das Auslesen und Schreiben der XML-Files - matlabworkspaceviewer.viewer
Der eigentliche Viewer - matlabworkspaceviewer.updater
Schnittstelle zwischen dem Viewer und dem "restlichen ML-Tutor" - matlabworkspaceviewer.vareditor
Editor für die Variablen (eventuell)
- Nur eine kleine Anmerkung: Es ist bei den Eclipse Plugins üblich den Domainnamen verkehrt in den Plugin- bzw. Packagenamen mitzuführen also z.B. könnte das Plugin at.tugraz.itp.matlabworkspaceviewer heißen und die Packages dann auch dementsprechend. --Camhy 13:02, 23 Oct 2005 (CEST)
- Wie sich die Packages in die Hierachie eingliedern müssen wir sowieso noch schauen. Ich hab diesbezüglich sowieso noch ein paar Fragen, die automatisch beantwortet werden, wenn ich den Projektaufbau sehe.
Handling der XML-Files
(Noch keine endgültigen Namen, nur für eine grobe Aufteilung)
Klassen
Für diese Anwendung bietet sich ein Sax-Parser an. Für das Auslesen eines XML-Files müssen sicher folgende Klassen geschrieben werden:
- FileReader
- FileWriter
- ContentHandler
- ErrorHandler
Eventuell dazu noch ein Interface
Zu importierende Klassen:
import javax.xml.parsers.SAXParserFactory; import javax.xml.parsers.SAXParser; import javax.xml.parsers.ParserConfigurationException; import org.xml.sax.XMLReader; import org.xml.sax.ErrorHandler; import org.xml.sax.SAXException; import org.xml.sax.SAXParseException; import org.xml.sax.helpers.DefaultHandler; import org.xml.sax.Attributes;
File einlesen
Prinzipieller Ablauf für das Lesen eines Files:
SAXParserFactory factory = SAXParserFactory.newInstance(); SAXParser saxParser = factory.newSAXParser(); XMLReader xmlReader = saxParser.getXMLReader(); content_handler = new ContentHandler(); xmlReader.setContentHandler(content_handler); XMLErrorHandler error_handler = new ErrorHandler(); xmlReader.setErrorHandler(error_handler); xmlReader.parse(filename);
File schreiben
Ganz gewöhnlich Strings zusammenstoppeln und in ein File schreiben.
Weiteres Vorgehen
- Einlernen in Eclipse und Pluginentwicklung für Eclipse
- Definition der Schnittstellen
- Grobplanung
- Entwicklung der Klassen zum Auslesen des XML-Files
- Entwicklung der Oberfläche
- Zuerst einfache Darstellung eines Files
- Dann Einbindung mit der entgültigen (Anzeige-)Funktionalität
- Eventuell Editor für die Variablen
Fragen
(Antworten der anderen Mitarbeiter in Farbe)
Offene
- Wie sehen die Schnittstellen zum ML-Tutor aus (genaue Definition)
- Vorläufig (bis die Schnittstellen stehen): Der erstellte View wird in der MLTutor Perspektive dargestellt. Er sollte irgendeine Funktion beinhalten, die eine Variable mit dem Inhalt der Variablen als Parameter übernimmt und dann den View updated. Wenn Variablen im View editiert werden, sollte eine Funktion der restlichen Plugins aufgerufen werden, die die geänderten Variablen wieder an Matlab zurückgibt. Dh. der Workspace Viewer sollte eine XML-Ausgabe produzieren, die der Definition entspricht und von Matlab wieder eingelesen werden kann und diese einer Funktion der restlichen Plugins übergeben
- Soll eine DTD zur Validierung geschrieben werden?
Damit könnten fehlerhaft erstellte/übertragene Files "abgefangen" werden.
- Es gibt eigentlich ein fertiges Schema (wahrscheinlich sogar leichter zu validieren, als eine DTD, da man genauere Einschränkungen machen kann) für jede Art XML-File, die im Programm vorkommt. Beim konkreten ist aber noch einiges nachzubessern, um der aktuellen Version gerecht zu werden. Kannst aber auch gern eine DTD schreiben, wenn das für dich besser ist, wär aber natürlich eine doppelte Arbeit, da das Schema schon fast fertig ist.
- Meiner Meinung nach interessanter Ansatz ist auf http://www.xmlmodeling.com/hyperModel/index.html zu finden. Hab teilweise mit ArgoUML modelliert und anschließend in ein Schema gewandelt. Das Plugin hat bei mir jedoch nicht unter Eclipse 3.1 funktioniert. Weiß nicht, ob sie es schon upgedated haben. (Nachtrag: Läuft schon..) Wär cool wenn der Schema Test dann miteingebaut werden könnte. Dann könnte man das was von Matlab kommt immer auf Sinnhaftigkeit überprüfen. Ist zwar keine Benutzereingabe, wo das mehr Sinn macht, aber man könnte es as so etwas ähnliches wie einen unittest für die Matlab-Skripte sehen, wenn man z.B. alle Variablenarten durchspielt. Übertragungsfehler könnte man damit natürlich auch ausschließen, wobei diese wahrscheinlich eh schon vom XML-Parser bemerkt werden..
- Natürlich wäre es auch schön das Schema auf genauere regular Expression - Überprüfungen zu erweitern. http://www.informit.com/articles/article.asp?p=31285&seqNum=1
- Solche Dinge sind daweil nur rudimentär eingebaut.
- Auf DTD bin ich nur gekommen, da ich bisher mit dem SAX-Parser immer mit DTDs validiert hab. Wenn das auch mit einem Schema geht wär's natürlich besser, nachdem es dieses schon gibt. Ich würde nur ungern auf eine Validierung komplett verzichten.
- --Osiris 17:35, 22 Oct 2005 (CEST)
- VIEL besserer Link für unsere Zwecke: http://www.eclipse.org/xsd/ --Camhy 18:31, 22 Oct 2005 (CEST)
- Das ist aber nur für das Handling von Schematas, oder überseh ich da was? --Osiris 17:44, 23 Oct 2005 (CEST)
- Direkter Link auf Xerces - wird von der obigen Seite verwiesen. http://xml.apache.org/xerces2-j/. emf/xsd Projekt kann durch dessen Verwendung im WTP insofern sehr hilfreich sein, da damit das Schema auch direkt in Eclipse bearbeitet werden kann. Wollte aber eigentlich eh direkt auf WTP und Xerces verweisen, tut mir leid. Apropos: Aus X-Men hab ich einigen Source gezogen, um die Editoren für die anderen Files zu erstellen. Zur Nutzung muss aber org.apache.xerces als Plugin installiert sein, was glaube ich aber sowieso bei der WTP dabei ist. --Camhy 14:09, 24 Oct 2005 (CEST)
- Das ist aber nur für das Handling von Schematas, oder überseh ich da was? --Osiris 17:44, 23 Oct 2005 (CEST)
- Ist das Matlab-eigene Fileformat (*.mat Files) zum Exportieren von Variablen frei? (höchstwahrscheinlich blöde Frage, aber es könnt ja sein)
- Ich denke schon.. Nachbasteln darf man es meiner Ansicht nach sowieso immer
Beantwortete
- Funktionsweise der Datenübertragung / des Updatens
- Nur kurz einmal: Im Endeffekt wird bei der ersten Ausführung eines Matlab Programms eine Pipe zu Matlab geöffnet, die solange offen bleiben soll, bis entweder der Benutzer durch einen Matlab Befehl das Programm schließt, oder die Anwendung beendet wird. Es können beliebige Matlab Befehle durch die Pipe geschickt werden und der Output wird jeweils ausgelesen. Es gibt eine Matlab-Funktion, die mit einem Variablennamen aufgerufen wird und diese Variable dann als XML-Text ausgibt. Dh. man müsste eine Matlab-Funktion zur Verfügung stellen, die alle vorhandenen Variablen anzeigt und diese dann nacheinander als XML-Text ausgibt. Dieser Output müsste dann vom Workspace-Viewer gelesen und in einem Eclipse View dargestellt werden. Wie das mit dem Update des Views ausschaut, müsste man sich noch überlegen. Vielleicht wäre ein vom Benutzer ausgelöstes Refresh gar nicht so schlecht.
- Aber: Als erster Schritt wäre es wahrscheinlich einmal einfacher zum Testen einen Eclipse-Editor zu schreiben, der auf eine bestimmte Dateiendung reagiert und das ausgewählte File einmal darstellt. Dieses dann mit der Pipe-Funktionalität zu versehen und in einen View umzubasteln, in dem mehrere Variablen angezeigt werden, wäre dann wahrscheinlich kein allzu großes Problem mehr.
- So eine Aufteilung finde ich auch auf jeden Fall sinnvoll.
- --Osiris 19:22, 21 Oct 2005 (CEST)
- Unit Tests erwünscht/erbeten/notwendig/üblich oder eher nicht (schwierig bei der Oberfläche)
- Schwer zu sagen, üblich sind sie leider nicht, da es so lange dauert sie zu schreiben. Es gibt ca. zu einem drittel der Funktionen unittests od. unittest-ähnliche Konstrukte. In diesem Fall würde es wahrscheinlich reichen, wenn man alle Variablenarten durchspielt und dann händisch die Anzeige der Variablen überprüft.
- Ich würd' sie aber nicht schlecht finden. Was den Zeitaufwand betrifft, würd ich das nicht so sagen (zitiere meine Freundin: "TDD ist nicht langwierig!!!". Natürlich ist mehr Code zu schreiben, wenn man Code und Tests zugleich entwickelt, aber dafür fällt die komplette Testphase weg und lange Fehlersuchen gibt's auch nicht. (lang kommt es einem nur vor, wenn man die Tests nachher schreibt, aber das ist ja kein TDD)
- Blöd ist nur, dass sich GUIs schwer testen lassen (da gibt's aber auch was). Aber z.B. das komplette XML-File Auslesen und das Datenhandling ließen sich wunderbar überprüfen.
- Die Vorteile von TDD würden bei uns voll zum Tragen kommen, insbesondere ist es sehr brauchbar, dass der Code automatisch dokumentiert und abgesichert wäre (und zukünftige Erweiterungen eventuell durch andere Programmierer sind ja nicht so unwahrscheinlich).
- Außerdem werd' ich ja auch in Eclipse entwickeln, und das mach Entwickeln mit Unit Tests ja noch einfacher als es ohnehin schon ist.
- Also wenn nicht unbedingt unheimlich schnell etwas Code brauchst, würd ich gerne TDD anwenden, wo es direkt möglich ist. Wenn dies jedoch nicht erwünscht wäre, dann eben nicht, ich hab mich da nicht so drauf versteift.
- --Osiris 19:11, 21 Oct 2005 (CEST)
- Natürlich wär das super, gib dir in allem völlig recht. Bei mir hat einfach die Zeit/Motivation oft nicht ausgereicht, um das auf diese Art anzugehen. Wäre spitze, wenn du das so schreiben könntest. Wenn du das was über GUI-Tests herausfindest, wärs natürlich auch super..
- Mir fällt gerade ein, dass die genaue Update-Strategie und das Erhalten der Variablen dem Viewer ja eigentlich egal sind. Er sollte meiner Meinung nach lediglich die Funktionalitäten zur Verfügung stellen um Variablen hinzuzufügen, alles neu aufzubauen, alles zu löschen, ...
- Was dargestellt werden soll, wird durch den ML-Tutor oder ein eigenes Updater-Modul bestimmt. Letzteres hätte den Vorteil, dass man über ein geschickt gemachtes Interface auch andere Module als den Workspace-Viewer damit ansprechen könnte. (Das ist jetzt aber kein Versuch das Updaten nicht machen zu müssen ;-)
- --Osiris 19:34, 21 Oct 2005 (CEST)
- Versteh ich nicht ganz.. Meinst du das updaten der aktuell vorhandenen Variablen?
- Ja.
- Wie ich deiner Beschreibung der Schnittstelle (s.o.) entnehmen kann, haben wir diesbezüglich das selbe Bild vor Augen. Mir ist es nur darum gegangen, dass sich der Viewer nicht darum kümmern soll wie er die darzustellenden Variablen aus Matlab bekommt.
- Mit einem Update-Modul meine ich ein eigenes Modul welches nur für das Updaten zuständig ist. Damit könnte man ein flexibleres (und überhaupt schöneres) Design erreichen.
- Wie füge ich denn Benutzernamen und Zeit so schön ins Wiki ein?
- Mit ~~~~ kommen Benutzername und Zeit, mit ~~~ nur der Benutzername rein.
- Ich verwend im Wiki-Editorfenster immer den zweiten Button von rechts, der macht immer noch zwei -- vorne dazu.
- Hihi, hätt ich sehen müssen, schreib die Texte immer mit externem Editor
--Camhy 18:31, 22 Oct 2005 (CEST)
- Hihi, hätt ich sehen müssen, schreib die Texte immer mit externem Editor
- Gibt's im ML-Tutor irgendwelche gröberen Abweichungen von den im Eclipse üblichen Sachen (Build-Prozess, ...)?
Ich glaub die Frage ersetzt viele andere :-)
- Nein, eigentlich gar keine. Das einzige was man vielleicht im Hinterkopf haben sollte, ist, dass es im Endeffekt möglich sein sollte, diesen auch in einer Eclipse RCP-Anwendung einzusetzen (Viewer für die Beispiele). Man kann jedoch fast jedes Plugin im Endeffekt dazu "überreden", auch dort zu funktionieren. Ist aber glaube ich einfacher, zuerst nicht so viel darauf zu achten. Eclipse RCP Tutorial --Camhy 13:02, 23 Oct 2005 (CEST)
Benötigte Ressourcen
- Die Schemata
- Zugang zum Subversion-Repository (primär um den Aufbau zu sehen, entwickeln kann ich einige Zeit auch lokal --Osiris 18:01, 23 Oct 2005 (CEST))
Interessante Links
XML-Forms-Generator Noch nicht ausprobiert, hört sich ganz interessant an, vielleicht ein bisserl OT. Interessant wäre ein Eclipse Forms basierer Editor, der diese Beschreibungen lesen kann.
http://eclipse.org/articles/Article-VE-Custom-Widget/customwidget.html Habs bis jetzt noch nicht geschafft, dieses Tutorial auszuprobieren. Würde eigentlich gerne alle meine GUI-Komponenten so schreiben
Eclipse Forms Weiß nicht, ob es überhaupt Sinn macht in diesem Fall einen Forms-basierten Editor-Viewer zu bauen
http://www.informit.com/articles/article.asp?p=31285&seqNum=1 Regular Expressions in XML-Schema
XML Schema Klassen in Eclipse
Hypermodel
Eclipse RCP Tutorial
Grundlegendes zur Programmierung:
Naming Conventions
Code Conventions for the Java Programming Language