On 30.08.2014 12:30, Matthias Bohnstedt wrote:
Hallo,
wie Herr Prechelt schon schrieb bin ich gerade dabei meine
Masterarbeit vorzubereiten. Die erste Idee Richtung GUI-Testframework
für Saros/I macht wirklich nicht so viel Sinn, wenn die UI noch im
Wandel ist.
Das UI von Saros/E ist auch ab und zu im Wandel, und trotzdem haben wir
GUI Tests ....
Ich habe verstanden, dass Teile (wie viele genau?) der GUI von SAROS/E
mit der SWT-Browser Komponente realisiert wurden. Und, dass sich die
Frage stellt ob es ein Äquivalent zu dieser Komponente auch in IntelJ
gibt, um die UI dort ähnlich zu realsieren. Das Ganze mit dem Ziel die
Gemeinsamkeiten zu vergrößern (bzw. genauer die Plattformabhänigkeit
der UI zu minimieren).
Es sind bis jetzt genau NULL Teile im Saros UI mit dieser
Technik/Technologie erstellt worden.
Beim von Kahlert beschriebenen Workflow, ist mir nicht klar was
"Facade" ist -- einfach eine Klasse/Bibo? Ich denke es würde mir sehr
helfen den Workflow als Code zu sehen um überhaupt einschätzen zu
können wie sich das auf IntelliJ übertragen lässt. Wo sollte ich da am
besten anfangen?
Was die "IntelliJ GUI-Komponente mit bidirektionale Kommunikation und
Callback" angeht, IntelJ benutzt soweit ich es auf den ersten Blick
verstanden habe für die Gesamte GUI Java SWING. Insofern sollte das
doch generell machbar sein, oder?
Machbar ist eigentlich immer fast alles. Die Frage ist nur: wie hoch ist
der Aufwand. Soweit ich das gesehen habe, gibt es zumindestens keine
equivalente Browser Klasse in AWT/Swing die in der Standard Java
Distribution enthalten ist.
Und in der IntelliJ API gibt es auch nichts.
Da ich noch nicht sehr tief in der Materie Stecke bin ich für jeden
Hinweis oder Einstiegspunkt dankbar.
Grüße
Matthias Bohnstedt
PS: dpp-devel = Englisch
Gruß,
Stefan
Am 28. August 2014 15:49 schrieb Kahlert, Björn
<bjoern.kahl...@fu-berlin.de <mailto:bjoern.kahl...@fu-berlin.de>>:
/siehe unten/
On 28.08.2014, at 13:23, Stefan Rossbach <srossb...@arcor.de
<mailto:srossb...@arcor.de>> wrote:
Das ganze Technik hat auch einen Namen:
http://de.wikipedia.org/wiki/Ajax_%28Programmierung%29
Wenn man die Java-Wrapper-Komponente als Server sieht, könnte man
das so bezeichnen.
Ich sehe das einfach nur als typische GUI-Komponente, die
Funktionsaufrufe (möglicherweise umgebaut) transparent an einen
gewrappten Browser übergibt.
Mit rendern meinte ich auch genau was du beschreibst. Die Website
bestimmt den Inhalt. Es sollte klar sein, dass das technische
rendern (Daten in den Grafikkartenspeicher schreiben) wohl immer
lokal ist :P
Stellt sich halt nur das Problem: Ich finde gerade:
1. keine Chromium Engine für Java
SWT greift auf einen installierten Browser zu. An diese Stelle
besteht erst einmal keine Notwendigkeit einer mitgelieferten Engine.
Auf Linux scheint das allerdings zu Problemen führen zu können:
http://stackoverflow.com/questions/5817263/how-to-get-eclipse-swt-browser-component-running-on-ubuntu-11-04-natty-narwhal
2. wäre das eine ziemlich große Bibliothek (denke mal > 10 MB)
Mein Browser-Wrapper, der eine Menge SWT-Funktionalität nutzt, ist
~250KB groß.
Aber wie gesagt: Es ist ein Wrapper. Keine Browser-Engine. So eine
mitzuliefern würden Abhängigkeiten mit der Host-Umwelt verringern
aber auch mit einem Aufwand verbunden sein, den ich aktuell nicht
überblicke.
3. es muss alles lokal laufen ... externe Browser und/oder
externe Server zu benutzen
ist nicht gerade sehr elegant ... und 4xx/5xx "Webseiten" sind
wirklich "komische" GUI Elemente :P
Darin sehe ich keinen Nachteil. Die Idee ist ja,
HTML+CSS+JavaScript zu verwenden, um schnell an individuelle und
plattformübergreifende Darstellungen zu gelangen.
Je individueller Komponente benötigt man lediglich eine HTML-Seite
und deren inkludierte Ressourcen, die man selbstverständlich mit
in das Plugin packt.
On 28.08.2014 13:06, Kahlert, Björn wrote:
Die SWT-Browser-Komponente verwendet den System-Browser (IE
unter Windows, Safari unter Mac OS, ...) um darin eine beliebige
Website zu öffnen.
Ich handhabe das so, dass eben diese Website eine html-Seite
ist, die Interaktivität mittels JavaScript realisiert und eine
API (genauer: eine Facade) bereitstellt, mit der dann die
Java-Welt kommuniziert.
Das Rendering übernimmt also kein Webdienst o.ä. sondern der
lokale in einer SWT-Komponente eingebettete System-Browser.
Workflow:
1. Single-Page-Website aufsetzen
2. Website implementieren (d.h. Funktionen bereitstellen, z.B.
Darstellung einer Liste von Elementen)
3. Facade in einer globalen Variable bereitstellen (also sollte
dann sowas wie "window.facade.addItem(item)" möglich sein)
4. Eigene SWT-Komponente schreiben (also von Composite erben)
5. Browser in Komponente einbetten (mit FillLayout) und
Single-Page-Website mittels browser.open(...) öffnen
6. JavaScript-Facade also Member-Funktionen bereitstellen (z.B.
addItem(Item item))
7. Member-Funktion die JavaScript-Facaden-Funktion aufrufen
lassen, z.B. browser.execute("window.facade.addItem('" + item +
"');")
8. ggf. Rückgabe parsen und als typisiertes Objekt zurückgeben
On 28 Aug 2014, at 12:35, Stefan Rossbach <srossb...@arcor.de
<mailto:srossb...@arcor.de>> wrote:
Hallo,
also quasi sowas hier: http://www.awesomium.com/ ?
Wenn ich das jetzt richtig verstanden habe, ist der Webserver
zuständig für das "Rendern" des GUI.
Da Saros aber auch in Intranets (z.B Firmen) eingesetzt werden
soll, müsste dann der Webserver lokal irgendwie mitlaufen.
Ein anderer Ansatz wäre es, dass komplette GUI zu skripten (bei
dem Freiraum, den Eclipse da zuläßt, weiss ich aber nicht, ob
das überhaupt Sinnvoll wäre).
Siehe auch:
http://www.darkageofcamelot.com/content/xml-user-interface (XML
only)
http://www.wowwiki.com/World_of_Warcraft_API (LUA/XML)
http://www.lotrointerface.com/wiki/LotRO_API_Reference (LUA)
http://wiki.riftui.com/Main_Page (LUA)
http://camelotunchained.com/en/making-a-game-out-of-the-web/
(HTML, JavaScript, CSS ... also dein Ansatz)
....
Viele Wege führen nach Rom, welche der bequemste ist
(vielleicht ist es einfach auch nur C&P und replace) muss halt
analysiert werden.
Gruß,
Stefan
On 28.08.2014 12:10, Kahlert, Björn wrote:
Hallo,
noch eine Ergänzung zur Technik:
In Eclipse verwende ich die SWT Komponente "Browser".
Diese Komponente öffnet eine selbst zu entwickelnde einseitige
Website.
Browser erlaubt JavaScript-Aufrufe und unterstützt Rückgaben.
So genannte BrowserFunctions können aktiv von JavaScript-Seite
aufgerufen werden (z.B. im Fälle eines Ereignisses auf
HTML-Seite).
Durch Delegation kann eine individuelle SWT-Komponente
entwickelt werden, die die Natur der Webanwendung vollständig
verbirgt.
Je mehr Logik in der Webanwendung steckt, desto weniger
Code-Duplikation ist vonnöten.
Man hat nur beschränkt Kontrolle über den verwendeten Browser,
d.h. die Webanwendung selbst muss Cross-Browser-kompatibel sein.
Die enorme Optimierung aktueller Major-Browser wirkt sich auf
die eigene Anwendung positiv aus. In meiner QDA-Anwendung wird
eine > 10.000px breite Zeitleiste mit mehreren hundert
Icon-großen Bildern dargestellt ... flüssig ... und in SWT
undenkbar.
Diese knappe Beschreibung soll nicht nur die Möglichkeiten
verdeutlichen, sondern auch als Anforderungsbeschreibung
dienen. Es wäre sicherzustellen, dass IntelliJ ebenfalls eine
GUI-Komponente besitzt, die bidirektionale Kommunikation und
Callback-Funktionen bereit hält.
Björn
On 28 Aug 2014, at 09:33, "Lutz Prechelt"
<prech...@inf.fu-berlin.de
<mailto:prech...@inf.fu-berlin.de>> wrote:
Lieber Franz, lieber Holger, lieber Herr Rossbach,
Björn Kahlert macht in seiner Promotionsforschung qualitative
Datenanalyse (QDA).
Da es für seine Datenarten nichts passendes gibt, hat er sich
selbst
eine umfangreiche QDA-Anwendung gebaut.
Und da er ein Eclipse-Crack ist (er hat erhebliche Teile des
Saros-GUI
implementiert), hat er Eclipse RCP dafür benutzt.
Gestern hat er mir erzählt, dass viele der Widgets in seiner
Anwendung gar nicht mit SWT gebaut sind, sondern immer wieder
auf der gleichen HTML-Komponente basieren, die er sich gebaut
hat, und in Wirklichkeit hauptsächlich aus HTML und etwas
Javascript
bestehen.
Trotz des erheblichen Aufwands, den er in den Bau der
Basiskomponente
gesteckt hat, findet er, dass er in der Summe damit viel Arbeit
gespart hat.
Das hat in mir folgenden Gedanken erzeugt:
Wenn er das schon aus purer Bequemlichkeit so macht,
wie hilfreich muss es dann erst sein, wenn man damit die
Gemeinsamkeiten von Saros-E und Saros-I vergrößern kann,
weil viel weniger Teile derer GUI tatsächlich plattformspezifisch
sind?
Zumindest die Gleich-Förmigkeit der beiden GUIs sollte sich
doch wohl so viel einfacher herstellen und bewahren lassen.
Und für die Testautomatisierung könnte das auch ein Segen sein.
Ich überschaue die Implikationen leider überhaupt nicht und bitte
deshalb um Kommentare zu dieser Idee (die zugegeben gern ein paar
Monate früher hätte auftauchen dürfen, ich weiß).
Wir haben aktuell zwei Aspiranten auf eine Masterarbeit
(Cikryt und Bohnstedt), die beide bislang tendenziell
Richtung Testen/Testframework unterwegs sind, was nicht sinnvoll
ist. Man könnte einen davon Richtung HTML-Basierung umsteuern.
Lutz
------------------------------------------------------------------------------
Slashdot TV.
Video for Nerds. Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
DPP-Devel mailing list
DPP-Devel@lists.sourceforge.net
<mailto:DPP-Devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/dpp-devel
------------------------------------------------------------------------------
Slashdot TV.
Video for Nerds. Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
DPP-Devel mailing list
DPP-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dpp-devel
------------------------------------------------------------------------------
Slashdot TV.
Video for Nerds. Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
DPP-Devel mailing list
DPP-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dpp-devel
