Ich bin ziemlicher Neuling (oder vielleicht Oldie) in der GUI-Entwicklung. Wenn Sie sich jetzt einarbeiten, scheint es eine riesige Menge verschiedener Frameworks zu geben, die verwendet werden können. Derzeit habe ich eine Java-Anwendung erstellt, die alle Arten von Datei- und Anwendungsmetadaten in eine PostgreSQL-Datenbank kratzt. Dieser Teil ist jetzt ziemlich fertig und die Daten (etwa 20000 Zeilen) sitzen in der Serverdatenbank und warten auf weitere Verwendung. Ich gehe davon aus, dass es irgendwann Hunderttausende von Zeilen in der Datenbank in einer Handvoll Tabellen geben könnte, vielleicht Millionen oder maximal zwei.
Ein Weg wäre mit Java Swing/FX weitergegangen, aber das Frontend sollte wirklich betriebssystemunabhängig und leicht zugänglich sein, was auf webbasierte Lösungen hindeutet. Scheint, dass Applets ziemlich altes Zeug sind und auch JSF mittlerweile viele brauchbare Konkurrenten hat. Die Anforderungen an die GUI sind:
Der erste Gedanke war, dies rein auf dem Server zu bauen; Erstellen aller Baumkarten usw. basierend auf Benutzeranforderungen. Bei mehreren Benutzern würde dies jedoch wahrscheinlich eine erhebliche Last auf der Serverseite erzeugen. Daher dachte ich, es gäbe nur eine minimale Menge an serverseitiger Codelogik, nur um die Datenbankabfragen zu sichern/isolieren, das Haupt-HTML/CSS-Zeug zu bilden und dann Javascript-Logik einzubetten, um die Grafiken zu zeichnen, Benutzereingaben usw. auf der Clientseite zu interpretieren ? Derzeit ist ein Rätsel, wie diese beiden Welten miteinander kommunizieren würden, ich meine, wie der Javascript-Teil die Informationen von der Serverseite anfordert? Erfordert es Websockets oder könnte ein Teil der serverseitigen Anwendungslogik wie eine REST/API-Schnittstelle zum Javascript-Code fungieren? Vielleicht haben Sie einfach eine Jersey/Swing-REST-Middleware Java "etwas" zwischen der Datenbank und der Webseite, die JSON-Daten für die Javascript-Logik bereitstellt. Spiele jetzt mit Hibernate, bin mir aber nicht sicher, ob es in dieses Szenario passen würde ...
Habe Code in Java, C, Python, JS und einigen alten anderen Sprachen + wenig Node.js, PHP und Perl geschrieben. Ich bevorzuge Java und JS, aber wenn es einen guten Grund gibt, etwas anderes zu verwenden, sollte es kein Problem sein. Verwendet derzeit Netbeans (gelegentlich Eclipse) und habe einige der Web-, JavaFX-, HTML5-, JSF- und Maven-Beispielprojekte untersucht, die es hat. Habe auch versucht, Spring-, Hibernate-, Vaadin-, Wicket-, JSF- und Whatnot-Frameworks zu recherchieren. Jeder sagt, wie einfach und überlegen sie sind, aber je mehr ich diese lese/teste, desto mehr scheint es, dass sie nicht immer so hilfreich sind, indem sie hier und da alle Arten von zusätzlichem Code erstellen. Also bin ich nach tagelanger Recherche immer noch sehr verloren mit all diesen Möglichkeiten und bevor ich mich für immer in diesem Dschungel verirre, Ich dachte, dass vielleicht irgendein Guru hier aufzeigen könnte, welchen Weg dieses n00b nehmen sollte? Ich versuche nur, die Situation zu vermeiden, in der die Hälfte der Dinge erledigt sind und dann das Framework geändert werden muss, weil das Fehlen einer Funktion oder Wartung überwältigend wird.
Die Java-Applet- Route ist fast tot. Alle Hersteller von Webbrowsern stellen die Unterstützung für Java Applet und ähnliche Plugin-Ausführungsumgebungen wie Flash und Silverlight wegen horrender Sicherheitsprobleme ein.
Ebenso ist die Applet-Technologie innerhalb von Java jetzt veraltet und wird wahrscheinlich irgendwann auslaufen.
Wenn Sie bereits Fortschritte beim Erstellen einer Swing/JavaFX-App machen, gibt es keinen Grund, diese nicht auszuliefern. Eine solche App ist sicherlich plattformübergreifend. Da die Java-Modularisierung in Java 9/10/11 durchgeführt wird, können Sie Tools wie jlink verwenden, um einen benutzerdefinierten Build einer JVM zu erstellen, die mit Ihrer App als einzelne ausführbare Datei gebündelt wird.
Wenn Sie sich für eine Web-App entscheiden und bereits über Java-Kenntnisse verfügen, ist Vaadin die offensichtliche Wahl. Vaadin wird in Java ausgeführt, wobei der Status Ihrer App serverseitig in der JVM gespeichert wird. Sie schreiben sowohl Ihre Geschäftslogik als auch Ihren Code für die Benutzeroberfläche in reinem Java. Das Vaadin-Framework installiert eine JavaScript-Bibliothek auf dem Client, wodurch eine dynamisch erstellte Webstandard-Benutzeroberfläche remote auf der Client-Seite gerendert wird.
Die Kommunikation zwischen Client und Server wird automatisch unter Verwendung der Java-Servlet-Technologie, HTTP, HTTP/2 und WebSocket abgewickelt, abhängig von der Leistungsfähigkeit Ihres Webbrowsers, Webservers und Netzwerkfähigkeiten.
Was Abschnitte Ihrer UI-Layouts betrifft, die Benutzerinteraktionen koordinieren und darauf reagieren, das ist der eigentliche Zweck von Vaadin. Der Benutzer klickt auf eine Schaltfläche oder gibt etwas in ein Feld ein. Vaadin überträgt dieses Benutzerereignis an die serverseitige Java-App, wo Ihr Code reagiert und den Status anderer Widgets aktualisiert. Vaadin übermittelt den neuen Zustand dieser anderen Widgets automatisch zurück an den Webbrowser, wo ihre visuelle Anzeige aktualisiert wird.
Was ein Baum-Widget betrifft, bietet Vaadin 8 bereits zwei, ein Treeund ein GridTree.
Was Ihren Java-basierten Graph-Visualizer betrifft, so ist das ein Problem. Bei Vaadin gibt es clientseitig kein Java. Auf der Clientseite werden nur Webstandardtechnologien wie JavaScript, CSS, DOM, AJAX usw. verwendet. Wenn Ihre GraphStream-Bibliothek kopflos ausgeführt werden kann, sollten Sie in der Lage sein, auf der Serverseite mit einem fertigen Bild zu rendern, das an den Webbrowser gesendet wird Zur Ausstellung.
Wenn Sie Interaktivität benötigen, müssen Sie ein JavaScript-Tool finden, das GraphStream entspricht. Ein solches Tool kann als Vaadin-Widget verpackt werden, auf das serverseitig in Java zugegriffen werden kann. In Vaadin 8 erfolgt dieses Wrapping über GWT, Google Web Toolkit. In Vaadin 10 und höher, bekannt als Vaadin Flow , wird ein solches Wrapping durch die Einführung der Webkomponenten -Technologie anstelle von GWT viel einfacher .
Sie haben Hibernate erwähnt , sind aber für Ihre Frage irrelevant. Dieses Projekt dient hauptsächlich der Automatisierung einiger Interaktionen mit einer Datenbank. Hat nichts direkt mit der Benutzeroberfläche oder der größeren App zu tun. Einige untergeordnete Unterprojekte wie die Implementierung der Bean-Validierung dienen einem Zweck zwischen der Benutzeroberfläche und der Datenbank.
Ich versuche nur, die Situation zu vermeiden, in der die Hälfte der Dinge erledigt sind und dann das Framework geändert werden muss, weil das Fehlen einer Funktion oder Wartung überwältigend wird.
Bei jeder Wahl der Technologie sollten Sie sich darauf konzentrieren, einen Wegwerf-Proof-of-Concept zu erstellen, bevor Sie mit der eigentlichen Implementierung beginnen. Erstellen Sie eine gefälschte App, die alle in Ihrer App geplanten Bereiche teilweise berührt. Probieren Sie jede Technologie aus, um sicherzustellen, dass sie Ihren Anforderungen entspricht. Sobald dies bewiesen ist, verwerfen Sie diese gefälschte App und beginnen Sie neu mit der Gewissheit, dass Sie Ihre Mission erfüllen können.
Danke @Basil für deine umfassende Antwort. Habe genau das getan, was du gesagt hast, indem du verschiedene Ansätze mit einer kleinen Menge an Testdaten ausprobiert hast. Die erste Reise war PHP, das ich kurz darauf verworfen habe, weil sich PHP etwas klobig anfühlt, die Sicherheit ein wenig fragwürdig ist und die zukünftige Wartung mit wachsender Site-Komplexität mühsam werden kann. Ich spiele jetzt schon seit einiger Zeit mit Vaadin und es fühlt sich ziemlich gut an. Der Community-Support könnte besser sein und ist mit seiner Hierarchie, internen Funktionalität und all der neuen schicken Java-Notation, die 1.8 auf den Tisch gebracht hat (!), immer noch ein bisschen verloren :s
Ich balanciere jedoch immer noch zwischen Web-GUI und Desktop-App. Das Erstellen einer Web-App vom Typ IDE scheint viel komplizierter zu sein als eine ähnliche klassische Desktop-App. Swing/JavaFX ist daher immer noch als Fallback-Option auf dem Tisch, wenn das Erstellen der Web-GUI zu kompliziert wird.
Basil Bourque
BrenBarn