Webstart / Webclient

[Markus Glitzner]

Hallo!

Ich habe bis heute nicht verstanden was der Unterschied zwischen „mit“ und „ohne“ Webstart ist. Ich kenne nur eine Möglichgkeit Nuclos zu starten und zwar über den Webbrowser bzw. die webstart.jnlp Url an die javaws.exe zu übergeben, was ja das selbe ist.

Kann mich da bitte jemand aufklären!

Gruß
Hugo

[Ramin Goettlich]

Wie kommen Sie denn darauf? Es gibt nur den „mit“ Webstart-Weg.

Genau genommen könnte man natürlich die Client-Dateien auf einen Client kopieren und direkt dort ausführen – aber warum sollte man sowas tun.

[Markus Glitzner]

Z.B. 1. Kommentar von Thomas Parsch in NUCLOS-2143

oder hier schon etwas älter NUCLOS-1273, einfach nach Webstart suchen

Jedenfalls wird immer wieder mal Webstart so erwähnt, als wie wenn es noch eine andere Möglichkeit gäbe, Nuclos zu starten und ich mich dann immer frage, ob ich da etwas übesehe oder einfach nur falsch verstehe.

[Ramin Goettlich]

Ah, in den Fällen ist gemeint: Direkt aus der Entwicklungsumgebung heraus.

[Markus Glitzner]

verstehe, jetzt ergibt es auch für mich Sinn 😉

Gibt es eigentlich zum WebClient schon nähere Infos, ich finde darüber nichts.
z.B. Ab welcher Nuclos Version wird es verfügbar sein und welche Einschränkungen gegenüber dem Webstart wird es (zu Beginn) geben.

[Ramin Goettlich]

Der Webclient (Version „0.01Alpha“) wird bereits in Nuclos 4 mit ausgeliefert werden und nach Installation (ebenso wie der RESTful Service) automatisch jeder Installation zur Verfügung stehen.

Eine echte Version 1.0 entspricht gleichzeitig Nuclos 5. Zeitpunkt noch unbekannt, wir rechnen mit irgendwas zwischen 6 und 12 Monaten. Also 2.Quartal 2014, Teile sind auch schon früher nutzbar.

Die Version 0.01Alpha 😉 – heutiger Entwicklungsstand – unterstützt bereits: Authentifizierung, Menüdarstellung, Volltextsuche, Ergebnisliste, Detailansicht (CRUD), Subforms. Funktional, aber optisch noch lange nicht in der Endausbaustufe.

Die Version 1.0 soll dann die volle Funktionalität aus Sicht des Endanwenders abbilden (d.h. ohne die Konfigurationswerkzeuge und möglicherweise auch ohne die Administrationswerkzeuge). Dabei bilden wir den Swing Client nicht einfach eins zu eins ab, sondern bringen eine Menge neuer Konzepte, Ansätze und Ideen ein und lösen manche Dinge anders. Das Thema Layouts müssen wir zwangsweise ganz anders lösen. Auch Groovy werden wir durch etwas ersetzen (müssen), das auch im Webclient interpretiert werden kann. Die Gedanken dazu laufen momentan in Richtung Formeleditor oder etwas vergleichbares. Ansonsten gilt aber immer die Prämisse: Es wird auf der bestehenden Konfiguration aufgesetzt, Nuclets funktionieren also einfach weiter.

Nach und nach werden wir diesen Webclient dann um die Administrations- und Konfigurationswerkzeuge ergänzen, mit dem langfristigen Ziel, den Swingclient vollständig abzulösen. Wir sind die Startup-Wartezeiten leid, wir sind die Abhängigkeiten zu Java und Oracle leid. Und die immer wieder neuen Problem durch Java Updates (siehe aktuelle Java 7u25 Problematik).

Zum Einsatz kommende Technologie: http://angularjs.org/

Wir verfolgen von Anfang an das Ziel, einen rasend schnellen Client zu bauen (deshalb auch keine Server-side Frameworks wie Vaadin, GWT, RAP, etc.) der auch auf mobilen Endgeräten komfortabel und schnell ist.

[Markus Glitzner]

Danke für die ausführliche Erklärung, klingt ja recht interessant und vielversprechend. Die Startzeit bzw. das öffnen bestimmter Datensätze ist in der Tat etwas lange, warum auch viele Benutzer generell sagen Nuclos ist langsam, was aber so nicht stimmt.

Bin schon gespannt …

Gruß
Hugo

[Jan Smiesko]

Hallo,

die Konzentration auf ein JS-Client-FW finde ich positiv, was mich etwas überrascht ist die Entscheidung für „angularjs.org“, da dieses Basis-FW meines Wissens kaum moderne Widgets wie ein DataGrid usw. (variabler CellEditor oder Anpassung Spaltenbreite on the fly …) bereit stellt und hier viel manuelle Entwicklung erforderlich ist.

Verstehe ich das richtig, dass mit dem RESTful-API der Server in Zukunft schlanker werden kann, weil die Java-Client Kommunikation nicht mehr benötigt wird. D.h. wenn die Admin-Funktionen auch vom WebClient abgelöst werden.

Warum wird bei den Client-Regeln Groovy nicht durch JavaScript ersetzt? Würde sich aufgrund der Entscheidung für einen HTML-5/CSS/JS-Client anbieten?

Gibt es schon einen geplanten Erscheinungstermin für 4.0?

FG
Jan

[Ramin Goettlich]

Hallo,

mal davon abgesehen, dass sich praktisch jedes jQuery-Widget in AngularJS integrieren lässt, gibt es für AngularJS auch von Haus aus viele Widgets und viele weitere Integrationmöglichkeiten (z.B. wjimo, kendoui).

Nichtsdestotrotz ist der Entwicklungsaufwand enorm.

> Verstehe ich das richtig…
Ja, unbedingt!

> Warum wird bei den Client-Regeln Groovy nicht durch JavaScript ersetzt?
Zum einen sind wir noch weit davon entfernt, den Swing Client abzulösen – wir brauchen also etwas, dass nur einmal konfiguriert werden muss aber auf beiden Umgebungen läuft. Mit JavaScript hätte man zu viele unkontrollierbare Möglichkeiten, was wieder eine Abwärtskompatibilität korrumpieren würde: Aktualisiert man auf die neueste Version, funktionieren die eigenen JS-Regeln nicht mehr… Mit viel Aufwand haben wir in serverseitigen Regeln durch Einführung der API die Abwärtskompatibilität hergestellt, auf Clientseite wollen wir uns nicht auf ein ähnliches Horrorszenario einlassen. Ausserdem wollen wir einem Nuclet-Entwickler nicht auch noch JavaScript zumuten (Groovy ist ja schon kaum auszuhalten), da muss was Intuitiveres her, etwas, das eher wie ein Formeleditor funktioniert.

Eine Beta für 4.0 wird es spätestens im September geben. Erstmal soll unser eigenes ERP-System (natürlich auf Basis Nuclos) für unsere internen Prozesse weitestgehend fehlerfrei auf 4.0 laufen. Während wir bereits an 4.1 (Schnittstellen zwischen Nuclets) und 5.0 (Webclient) arbeiten, sind wir derzeit damit beschäftigt, die Stabilität von 4.0 herzustellen.

Grüsse,
nuclosian

[Jan Smiesko]

Hallo,

okey, es baut auf angular.js auf, um die MVC Strukturierung des Codes zu erreichen, verwendet aber jQuery bzw. jQuery UI als Basis für Widget-Generierung. kendoui (baut ja auch auf jQuery auf) hat ein interessantes Grid-Control und dynamische Erstellung von Controls ist eingebaut.

Die Server-Side-API ist aus meiner Sicht ein wichtiger Schritt in die richtige Richtung! Bei der Client-API sehe ich die mögliche Flexibilität nicht so kritisch, weil, so weit ich weiß, jQuery die Kompatibilität zum Browser gut abdeckt und Sie mit jeder Nuclos-Version die passenden JS-Libs mitliefern könnten. Mit einem Meta-Werkzeug wie der Formeleditor schaffe ich zwar Stabilität, nehme dem Entwickler aber die Möglichkeiten einer Programmiersprache. Dort wo der Formeleditor nicht ausreicht, müsste sich ein Entwickler einen eigenen Client (z.B. Web) bauen, um gewünschte Flexibilität zu haben. z.B. andere Widgets einbauen, oder von einem anderen REST-Service Daten abrufen.
JavaScript ist ähnlich Java (Objekt-Syntax) und der Umstieg von Groovy auf etwas Anderes wird, wie der Umstieg auf die neue Server API, nicht zu verhindern sein. Der Formeleditor, der in JS geschrieben ist, würde auch wieder nur JS produzieren. Klar, der Formeleditor könnte später z.B. Dart oder andere Programmiersprache produzieren und damit Kompatibilität ermöglichen. Irgendwie sind diese div. grafischen Programmieransätze meines Erachtens nicht gut lesbar, umständlich bzw. nicht gut zu debuggen.

FG
Jan

[Autor]

Beiträge