Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > de.comp.lang.java > #12872

Re: GUI fuer Java

Date 2015-12-26 11:58 -0500
From Gunter Herrmann <notformail0106@earthlink.net>
Newsgroups de.comp.lang.java
Subject Re: GUI fuer Java
References <n5hbbi$p64$1@speranza.aioe.org> <Server-Programmierung-20151225035310@ram.dialup.fu-berlin.de> <n5kutu$gmd$1@speranza.aioe.org>
Message-ID <9smdnfLIGbXfWuPLnZ2dnUU7-TWdnZ2d@earthlink.com> (permalink)

Show all headers | View raw


Peter Dunkel wrote:
> Am 25.12.15 um 03:58 schrieb Stefan Ram:
>> Peter Dunkel <dunkelpeter@gmx.net> writes:
>>> Sollte auf einem Tomcat (oder aehnliches) laufen. Geht um 2 bis 5
>>> Benutzer, alle im lokalen Netzwerk.
>>
>> Wenn Du etwas auf Tomcat laufen lassen willst, warum
>> erwähnst Du dann eingangs überhaupt Swing?
>
> Hallo Stefan,
>
> Danke für Deine Antwort.
> Warenwirtschaft bedeutet Datenbank, und von den Fat-Clients sind wir ja
> gluecklicherweise weg.
> Also Datenbank auf dem Server (Rechner), dort laeuft dann neben der
> Zugriffsschicht auch die Fachliche Schicht, dort werden die Eingaben
> validiert etc., bevor es schreibende Zugriffe auf die Datenbank gibt.
>
> Der Client (Software), also das GUI, laeuft auf anderen Rechnern.
> Die Verbindung koennten WebServices oder ein MessageServices (muss ja
> nicht sofort IBM MQS heissen) sein, RMI oder aehnliches scheint mir
> nicht mehr sinvoll.
>
> Mein Problem ist, wie "mache" ich aus dem XML oder was auch immer, das
> der WebService an den Client liefert, ein vernünftiges GUI.
> Dem Benutzer ein XML vorzusetzen, in dem er editieren soll, ist wohl
> nicht optimal.
> Die GUIs, die ich bei den Banken kennengelernt habe, sind meist um die
> 15 Jahre alt, beruhen also auf Swing, der Client ist eine
> Java-Applikation. Nur sieht man von diesem Swing nur noch wenig, das
> meiste ist gekapselt. Mein aktueller Kunden verwendet ein gut
> gekapseltes GWT. Der Austausch mit dem Server passiert meist über einem
> IBM MQ Server.
>
>> Viele Webbrowser können ohnehin schon XML mit CSS
>> darstellen, HTML ist nicht unbedingt nötig. Oder Du kannst
>> (X)HTML5 und XML mischen, Browser validieren ja nun nicht ;-).
>
> Wie schon gesagt, einen Server zu bauen, der HMTL oder was auch immer an
> einen WebBrowser liefert, ist eine Fingerübung. Aber es sollen Daten
> erfasst und dabei schon vorvalidiert werden (in einem Datums-Feld hat
> "Hugo" nicht zu suchen, das Sterbe-Datum darf nicht in der Zukunft
> liegen, ...).
>
>> Deinen Klienten kannst Du doch dann hervoragend mit JavaScript
>> schreiben, da brauchst Du doch nicht unbedingt Java.
>> DOM-Transformationen sollten auch mit JavaScript gehen.
>> Und es gibt natürlich auch noch Ajax.
>
> Stimmt, also schreibe ich ein passendes Framework in JavaScript.
> Nur, diese Arbeit möchte ich mir nicht antun, da suche ich etwas
> fertiges, wo ich ggf. noch Anpassungen durchführen kann.
>
> Wir reden von um die 50 bis 100 Eingabemasken.
>
> An JavaFX hatte ich auch schon gedacht. Aber irgendwie setzt es sich
> nicht durch.
>
> SWT war auch eine Idee, als ich vor einigen Jahren für ein Eclipse
> Plugin einige Dialoge schreiben durfte, hatte ich das gefühlt, es beisst.
>
> JSP oder ähnliches sind sicher auch eine Idee, aber den Aufbau der
> Masken will ich auf dem Client durchführen. Ein Server, der an den
> WebServer auf den gleichen Rechner WebServices liefert, die dann in
> WebServer in HTML umgewandelt werden, und der Server behält die
> Sessions, nicht meine Idee.
>
> Ich möchte auf dem Server nur Zustandslose Services bauen.
>
> Der Benutzer sendet via Client-Anwendung einen Request (mit Anmeldedaten
> des Benutzers) an den Server und bekommt einen Response,
> zwischenzeitlich vergisst der Server alles. Diesen Response stellt die
> Client-Anwendung dar, der Anwender kann editieren und schickt
> anschliessend die Daten der Maske als Request an den Server.
> Ob die Client-Anwendung selber das GUI darstellt, oder es ein Service
> auf dem Client-Rechner ist, der dann einen WebBrowser aufruft, will ich
> spaeter entscheiden.
>
> Gruss
> Peter

Habe mal einen Blick auf Vaadin. Du programmierst in Java, Vaadin 
erzeugt daraus Java code für Backend und Java Script für Frontend.
Es benutzt intern GWT Elemente. Die Programmierung ist ähnlich Swing, es 
erfordert aber keinen lokalen Java Client. Ich habe vor einigen Jahren 
mal privat etwas damit gespielt und es hat mir gefallen.

Zu einer Nutzung im beruflichen Feld ist es nicht gekommen.

Beste Grüße aus dem warmen (30° C) Florida

Gunter in Orlando

Back to de.comp.lang.java | Previous | NextPrevious in thread | Next in thread | Find similar


Thread

GUI fuer Java Peter Dunkel <dunkelpeter@gmx.net> - 2015-12-24 18:51 +0100
  Re: GUI fuer Java Peter Dunkel <dunkelpeter@gmx.net> - 2015-12-26 03:44 +0100
    Re: GUI fuer Java Gunter Herrmann <notformail0106@earthlink.net> - 2015-12-26 11:58 -0500
  Re: GUI fuer Java Bonita Montero <Bonita.Montero@gmail.com> - 2015-12-29 16:08 +0100

csiph-web