Swing. Ich habs vor 2 Jahren das letztemal angefasst.
Hier ein Zwischenbericht:
Das macht viel Sinn:
http://martinfowler.com/eaaDev/PresentationModel.htmlPresentation Model pulls the state and behavior of the view out into a model class that is part of the presentation. The Presentation Model coordinates with the domain layer and provides an interface to the view that minimizes decision making in the view. The view either stores all its state in the Presentation Model or synchonizes its state with Presentation Model frequently
Wobei es bei mir - basierend auf Scottie Delap - eine Haupt-PresentationModel Klasse
und für logisch zusammenhängende Teilbereiche (etwa die recht umfangreichen und smarten Navigationsbäume) ein sub-PresentationModel gibt.
GUIs sind scheissendreck-kompliziert. Ajax-Anwendungen versuchen diese Komplexität nun erst in den Bereich Webprogrammierung zu bringen. Die innere Komplexität bringt dem Anwender eine bessere Usability.
Die Notes-UI wurde nach dem Prinzip robust, konsistente "eigene" Standard-Logik, aber eben nicht unbedingt hohe Usability programmiert.
Dies eröffnet extra-Möglichkeiten in Hannover, aber eben auch extra Arbeit. Das oben angesprochene Pattern kann die benötigte Übersichtlichkeit bieten, die man als Entwickler benötigt.
+ Die Zeiten von GridBackLayout sind vorbei. Es gibt heute gute Layoutmanager, die einfach zu programmieren sind. Formlayout von Carsten Lentzsch oder der neue von Netbeans 5, der überdies noch eine gute IDE Unterstützung hat.
+ Swing Komponenten können mit ihren Millionen von Listenern, Teil-Objekten, etc. zwischendurch mal nervend komplex sein. Gute Swing Komponenten Bücher haben oft über 1.000 Seiten. Nur braucht man eben immer nur einen Teil davon. Und damit gehts. JTabPane (20 Seiten), JTree (120 Seiten). Der Aufbau ist auch relativ konsistent.
+ Es gibt Threading Issues. Swing horcht immer auf einen AWT-Event Queue:
- die EventListener laufen da drin.
- Repainting findet da drin statt.
Zeitraubendere Ressourcen muß man aus diesem Thread raushalten. Dafür gibt es SwingUtilities.invokeLater(), SwingUtilities.invokeAndWait() (braucht man seltener).
Sun hat eine Klasse SwingWorker, die das ganze mehr manageable macht. Dies ist nicht Bestandteil des JDKs!. Es gibt eine neue verbesserte Java5 Version. (suche auf java.net).
Dann gibts noch eine openSource Projekt Foxtrott. Das macht das ganze noch einfacher.
Jeder, der Swing programmiert, muß das berücksichtigen.
http://www.javalobby.org/members-only/eps/galbraith-swing-2/?source=archivesWenn wir Threading haben, gibt es Asynchronität. Und daran sind wir alle miteinander nicht besonders gewöhnt. Für einen "normalen" Entwickler läuft code eine Zeile nach der anderen ab. Mit Asynchronität laufen aber code-Bestandteile
beängstigend parallel.
Beispiel:
-> Der Anwender klickt auf einen Button: Hole mir alle Tickets von Helpdesk. Dies wird eine Weile dauern.
-> Vielleicht ist es sinnvoll, dass der User in der zwischenzeit etwas anderes machen kann (bei sehr langlaufenden Prozessen). Oder einfach, dass die GUI nicht einfrieren soll.
-> Nun gibt es aber Operationen, die der User in der Zwischenzeit nicht ausführen darf: Etwa ein Ticket anzeigen.
Ein Ticket anzeigen geht zwar auch über den Webservice, aber wesentlich schneller.
Also
1. User klickt auf "alle Tickets holen"
2. User klickt auf "Ticket A anzeigen"
3. Ticket A kommt zurück: wird angezeigt.
4. Alle Tickets kommen zurück (obwohl der User, das zuerst angefordert hat).
Und JETZT KOMMT DER PUNKT: "Alle Tickets kommen zurück" ist so programmiert, dass es die Anzeige in der spezielles-Ticket-Maske löscht, weil das u.U. nicht mehr aktuell ist!!!
Das heisst das Ergebnis von Operation 2 ist schneller da als die von Operation 1. Und wenn das ERgebnis von Operation 1 das von Operation 2 überschreibt, hat der Anwender ein Verständnisproblem und wir ein Problem.
Man muß also diese Operationen irgendwie synchronisieren.
Und das ist die Komplexiät von Asynchronität.
Und mit Zeugs wie Websphere MQ, mehr multi-Threading, Ajax, etc. wird es asynchroner.
Das gibt Vorteile für die usability, aber auch mehr Komplexität für den Entwickler.
+ Validation ist eine Sache, für die es (auch von Carsten Lentzsch) ein gutes openSource Projekt gibt. Unbedingt benutzen, sonst erzeugt man unübersichtlichen Code.
+ Es führt oft zu viel unübersichtlicheren code, wenn man Objekte aus dem Business Modell in die Gui reinholen will. Dafür gibt es ein - nicht einfaches aber sehr interessantes - openSource Projekt von Carsten Lentzsch (schon wieder). Auf Javalobby gibts dafür ein mehrteiliges Tutorial. Automatisches Binding ist btw. eine Sache, die glaub ich ziemlich stark in Ruby-on_rails vertreten ist, in .NET eine Rolle spielt und auch beim xml processing von doc/lit-style Webservices.
Wenn man das alles berücksichtigt, kann Swing Spaß machen.
Es wird alles in Scott Delaps Buch in SourceBeat beschrieben. Imho liegen seine Stärken nicht unbedingt im Erklären, aber es ist ein gutes Buch.
Gruß Axel