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:
public ArrayList getAppointmentsOfWeek (int week, int year)
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:
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
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)).
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.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