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
https://lists.sourceforge.net/lists/listinfo/dpp-devel
