swing besser/einfacher: gefährliche Versprechungen oder Zukunft?

[Axel_Janssen]

Hi,

hab mich jetzt mal umgeschaut, was es - neben der sehr guten Netbeans IDE - für Möglichkeiten gibt Swing-GUIs einfacher zu erstellen.
Auch IBMs swt beobachte ist, aber die sollen da erstmal ein Buch rausgeben.
Ich habe mich für meinen konkreten Anwendungsfall dagegen entschieden Laborratte für die existierenden xml basierte Konzepte zu spielen. Interessant sind sie trotzdem.

Beliebt sind Konzepte, wo man die GUI quasi als xml schreibt und eine engine daraus wohl swing-Klassen oder irgendeinen GUI-code erzeugt. Es gibt wohl 3 führende Konzepte:
+ Java Desktop Network Components propagiert von Suns hübschester Software Ingenieurin Amy Fowler (ist z.Zt. noch alpha oder beta):
http://www.javadesktop.org/articles/JDNC/index.html

+ SwingML
- OpenSource Projekt
- mehrere releases
http://swingml.sourceforge.net/news.html

+ Gerald Bauers XUL mit Java
- Open Source, basiert auf Framework von meinem Browser Mozilla
- wird in newsgroups oft als nicht praxistauglich bezeichnet
- Gerald Bauer wird eingesperrt, wenn er so weitermacht wie in den letzten Wochen. Ausser Javaranch gibt es kein Forum, wo er sich nicht selbst zum Thema macht.
http://luxor-xul.sourceforge.net/

Ich werde nun aber die seit 2 Wochen unter BSD-Lizenz freigegebenen frameworks forms und looks von Karsten Jentzsch antesten. Für mich verspricht das erstmal mehr professionelleres und windows-konformes Aussehen von Swing-GUIs. Der hat da eigene LayoutManager eigene Look-And-Feels und vermutlich noch andere goodies von denen ich noch nix ahne.
Der postet öfters auf de.comp.lang.java und wirkt :
- wie ein echten GUI-Fachmann
- persönlich integer
https://jgoodies.dev.java.net/


Gruß Axel

[Ralf_M_Petter]

Hallo Axel!

Ich entwickle gerade eine kleine Kundensuche in Swing und ich muß wirklich sagen, ich bin von Swing begeistert. Sicher man hat zuerst eine sehr harte Einarbeitungszeit, aber wenn man mal begriffen hat, wie Swing funktioniert, bzw. wie die Layoutmanager funktionieren, dann braucht man auch keinen Gui Form Builder mehr.  Also ich werde in Zkunft erst mal alles mit der Hand codieren, da das auch die einzige Form ist, mit der man wirklich lernt, wie Swing funktioniert.  Positiv überrascht bin ich auch von der Performance, den selbst auf meinem alten PIII 750 performt meine kleine Swing Applikation wunderbar, obwohl ich in dem Swing Fenster eine JTable habe die 6792 Zeilen und 9 Spalten hat. Die Daten werden online aus einer Notesview herausgelesen. Also nicht den Swingverdammern glauben, sondern selbst probieren. Es lohnt sich wirklich. Wobei ich auf jeden Fall einen Kurs empfehlen würde, da autodidaktisch so eine komplexe Materie zu lernen nicht wirklich einfach ist.

Grüße

Ralf

[Axel_Janssen]

Ralf,

dass sehe ich genauso. Hab meine Swing-Feindlichkeit völlig über Bord geworfen. Swt als Alternative halte ich im Auge, aber das ist aus Entwicklersicht sowieso auch relativ Swing ähnlich.

Das mit der Performance stimmt. Die Zeit, die Swing benötigt, um die Dinge so anzuzeigen wie ich es will, ist insignifikant, im Vergleich mit der Zeit, die Notes benötigt um die Daten zu holen (auch wenn ich über die C-Wrapper gehe). Zur Zeit habe ich im Projekt keine Performance-Probleme.  

Sicher braucht man den GUI-Editor letztlich nicht. Aber diese ganzen Komponenten selbst zu erzeugen, ist schon ein wenig langweilig. Werde jetzt aber vermutlich wieder auf Eclipse umswitchen, weil ich den Forms-Layout-Manager von Carsten Jentzsch benutzen will (s.o.) und dafür gibt es keine GUI. Muß also Handcoden. Bzw. werde die Dinge mit Netbeans erzeugen, rüberkopieren und ein bißchen die Reihenfolge nach meinem gusto anpassen.
Diese oben angesprochenen xml-Ansätze sehe ich als sehr interessante Forschungsprojekte an, die aber noch nicht reif für den Praxis-Einsatz sind. Irgendwann kann einer dieser Ansätze den time-to-market des gui-codings extrem beschleunigen. Das ist meine grundlegende Tool-Philosophie: Das Tool schützt mich nicht davor, etwas wirklich verstehen zu müßen, wenn ich es einsetze. Wenn es ausgereift ist, kann es aber meine Arbeit extrem beschleunigen.
Hab keine Zeit zu Schulung, habe komplexeren Auftrag .  
Letztlich ist das auch nur Java. Werde fragen posten sobald sie auftauchen und am Wochenende dann hoffentlich der Screenshot.
Das komplexe ist die JTable, aber eigenes TableModel schreiben, eigenen Renderer, etc. ging alles gut soweit.
Nächste Aufgabe ist, in den JTable Headern den default-renderer Label durch JTextArea zu ersetzen, damit "\n" funktioniert (und dann noch eine Menge weiterer Aufgaben).
Ist soweit ein kontrollierter Prozeß.
- im Internet gibt es eine Menge Ressourcen.
- als Notnagel gibt es immer noch die über-Experten aus de.comp.lang.java
- das Swing Buch von www.manning.com ist oft sehr hilfreich.

Vielleicht geben wir beide lieber Tipps als Fragen zu stellen ,
aber schau dir mal das an: http://www.jgoodies.com/freeware/jdiskreport/index.html
So sollen Swing Anwendungen aussehen. Der Mann hat eine Menge open source gestellt (s. Link oben).

[Ralf_M_Petter]

Hallo Axel!

Eine Frage, verwendest du in deinem Tablemodell auch Cacheing. Ich habe jetzt nämlich in meinem Tablemodell ein einfaches Cacheing eingeführt und es hat enormen Performance Gewinn gebracht, aber es ist sicher noch nicht ideal. Vielleicht können wir uns ja dazu etwas austauschen.

Grüße

Ralf

[Axel_Janssen]

Hi Ralf,

da denke ich auch drüber nach, für meine Gruppenterminkalender-Applet.
Würde aber wenn möglich darauf verzichten. Schließlich ist es eine Einschränkung der Funktionalität, wenn das Applet Daten nicht von Notes direkt, sondern aus einem cache holt. Performance-Argumente können aber für einen cache sprechen.

IMO macht meine layer-of-indirection Struktur das Implementieren von caches einfacher.

Ich spreche ja Notes nicht direkt aus dem TableModel an. Vielmehr gibt es die Klasse DbFacadeNotes, die wiederum mit NotesConnection kommuniziert.

Hab z.B. in der Facade die Funktion:

Code

public ArrayList getAppointmentsOfWeek (int week, int year) 

Diese kommuniziert mit einer gleichnamigen Funktion in NotesConnection.
Ich könnte in der Facade-Klasse einfach eine HashMap reinbasteln, mit dem key (week, year) und als value die ArrayList der in Notes gefundenen Daten.

Die Facade-Methode mit cache-Funktionalität sähe dann in a-personal-flavour-of-pseudo-code so aus:

Code

private HashMap cacheAppointments = new HashMap();
private ArrayList alAppointments = new ArrayList();

public ArrayList getAppointmentsOfWeek (int week, int year) {
        alAppointments.clear(); 
       String key = year + "-" + week;
      ArrayList result = cacheAppointments.get(key); 
       if (result == null) {
              result = notesConnection.getAppointmentsOfWeek (week, year);
              cacheAppointments.put(key, result);
        }
         //*doPostProcessing //
        return result;      
}

Sehe das als einfach und wiederverwendbar an und ist IMHO ein weiteres gutes Argument für mein Facade-Framework.

Ich poste davon bald (hoffentlich bis Donnerstag) eine Beispielimplementierung, aber ich bin ein bischen hinter meinem heiligen Zeitplan.

Bis jetzt ist es ohne Klima-Anlage hier noch erträglich (ohne Klimaanlage, aber mit großen Ahorbaum im Hof, erster Stock). Gestern auf der Autobahn (auch ohne Klimaanlage) war der Fahrtwind bei 150 km/h zwischen 11:00 und 17:00 Uhr wie ein Fön. Unglaublich.

Gruß Axel

[Ralf_M_Petter]

Wie siehts da mit der Performance bei deiner Tabelle aus, z.B. wenn du die Grösse einer Spalte anpasst. Den laut Java Swing Tutorial soll man in der  getValueAt Methode des Table Modells so performant wie möglich programmieren und eher nicht komplexe Funktionen in verschiedenen Klassen aufrufen.

Grüße

Ralf

[Axel_Janssen]

Wie siehts da mit der Performance bei deiner Tabelle aus, z.B. wenn du die Grösse einer Spalte anpasst. Den laut Java Swing Tutorial soll man in der  getValueAt Methode des Table Modells so performant wie möglich programmieren und eher nicht komplexe Funktionen in verschiedenen Klassen aufrufen.

Guter Punkt, aber ich mache es so auch nicht.
Der User kann (Jahr/Woche) in Comboboxen in der Swing-GUI umstellen.
Aus den entsprechenden Listenern der ComboBoxen wird dann im TableModel die BusinessMethode dateChanged (int week, int year) aufgerufen. Das sieht dann in etwa ungefähr so aus (das hat für die letzte version geklappt, jetzt nach Gespräch mit Auftraggeber ist totaler Design-Wechsel angesagt (d.h. ich nähere mich immer mehr einem framework, wie ich es haben will)).  

Code

public void dateChanged (int week, int year) {
      // setzt member ArrayList alAppointments auf einen neuen Wert.  
     dbFacadeNotes.getAppointmentsOfWeek (week, year);
     // folgenden Methoden sind notwendig, um die gui zu refreshen (geht so nicht automatisch und 
// yup: Das ist ein Nachteil, aber keine Performance-Problem so far. 
       TableAbwesenheit.frame.validate();
        TableAbwesenheit.frame.getTable().repaint();            
}

Die TableModel.getValueAt wird offenbar bei jTable.repaint() aufgerufen.
Die TableModel.getRowCount() bei frame.validate();
Beide holen sich ihre Daten dann über dbFacadeNotes.getAlAppointments();
// diese Variable wird innerhalb der dbFacadeNotes.getAppointmentsOfWeek (week, year); geändert.

Hat bei der letzten Version soweit gut, dh performant funktioniert.
Ich bin ein großer Freund von solchen gelayerten Designs. So 100% sicher, ob ich hier nicht vielleicht Swing mit J2EE-patterns vergewaltige bin ich mir übrigens auch nicht, aber ich werde dich informiert halten über die Ergebnisse.

Gruß Axel

[Ralf_M_Petter]

Hallo Axel!

Das mit den Repaint ist nicht ganz die korrekte Methode das zu machen. Du musst die Methode fireTableDataChanged(); des Tabellenmodells aufrufen, dann holt sich die Tabelle die neuen Daten. Neben diesem Event gibt es noch ein Vielzahl andere mit dem man der Tabelle mitteilen kann, dass z.B. eine neue Zeile eingefügt oder gelöscht wurde. Das ein bestimmter Bereich der Tabelle geändert wurde usw. Das bringt natürlich Performance.

Grüße

Ralf

[Axel_Janssen]

muß ich mal ausprobieren.

In Bereich der genauen update-Funktionsweise der Layoutmanager bin ich ohnehin noch mehr am raten.
Ich habe das durch ausprobieren rausbekommen. Hab eine wechselnde Anzahl an Tabellenzeilen (zumindest in der letzten Version, jetzt ändert sich das vermutlich, aber das ist eine andere Geschichte).
Jedenfalls änderte er die sichtbare Zeilenanzahl nur durch ein repaint auf einen parent-container.

Gruß Axel

[Ralf_M_Petter]

Kann du nur empfehlen, die richtigen Ereignisse zu verwenden, da es sonst sein kann, das deine Anwendung mit einer anderen JDK Version nicht mehr funktioniert. Momtentan ist es zwar so, das er bei einem neuzeichnen die Daten aus dem Tablemodell holt, aber es nicht sicher gewährleistet, das er das auch in Zukunft tut. Er könnte sich z.B. auch die Anzahl der Zeilen in der Tabelle zwischenspeichern und dann würde das mit dem repaint nicht mehr funktionieren.

Grüße

Ralf