Lotus Notes / Domino Sonstiges > Java und .NET mit Notes/Domino
HELP:Webservices-> Swing Client als Webservices Consumer
flaite:
Hi,
hier ein paar gesammelte Infos für den Swing Client für !!Help!!:
1. Swing ist eine komplexe Library. Ich hab relativ wenig Erfahrung damit. Mein Problem mit Swing Anwendungen war immer, dass mit den ganzen Listenern, Adaptern, Widgets, Models, Threading-Zeugs, etc. das ganze immer hin zu einem schwer zu maintainenden Chaos tendierte.
In diesem Projekt versuche ich nun - basierend auf einem Buch von Scott Delap - gewisse Architektur- und Designrichtlinien einzubauen, so dass es mit wachsender Größe maintainable bleibt. Dies könnte vielleicht für andere interessant sein, die ebenfalls mit Spwing (oder einer anderen GUI-Library) arbeiten. Viele der Ideen lassen sich vermutlich auch auf swt/JFace übertragen. Ich werde dazu noch was in hoffentlich verständlichen Form posten. Wenn ich bestimmte Konzepte erstmal nicht so schnell kapiere (aktuell namentlich Binding und Validation Libraries von Karsten Lentzsch) gehe ich in eng abgegrenzten Teilbereichen erstmal Low Tech, um Funktionalitäten zu implementieren. Dies schreib ich dann aber später um.
2. Ich kann dieses Projekt auf sourceforge.net publizieren. So können andere leicht auf den Code zugreifen. Ich hab vor bis spätestens Montag den Source ins cvs meines Sourceforge.net -Projekts zu bringen. Würd mich über Mitarbeit, Code-Bashing und Vorschläge freuen.
3. Dieses Projekt benutzt als Datenbasis den Webservices Layer der erfolgreichen Domino Helpdesk Anwendung !!Help!! von Thomas und Ulrich. Der Webservices-Producer Teil auf der HELP Seite ist zur Zeit noch eine Art Technologie-Proof-Of-Concept. Wir wollen nun bald eine fachliche Analyse der Anforderungen an einen Webservices Client durchführen und damit den Service entsprechend designen, dass er auch wirklich aus Sicht eines potentiellen Anwenders sinnvoll einzusetzen ist. Ich bemühe mich auch deshalb um eine solide Codebasis, um auf Erweiterungen/Änderungen des Webservices Producers auf HELP Seite schnell reagieren zu können. Dieses Projekt soll uns auch dazu dienen, Webservices vernünftig zu planen und zu designen.
4. Es existiert eine strenge Trennung zwischen GUI-Layer sowie den separierten Business und Service Layern. Die Business und Service Layer können später wiederverwendet werden, um z.B. mit Servlets/JSPs oder auch Mobile Java darauf zuzugreifen, wobei mit Mobile Java die Service und Business Layer leicht auf J2ME umgeschrieben werden müßten. Als Framework für Servlets/JSP schwebt mir Spring mit Webworks2 vor, aber das ist Zukunftsmusik.
5. Genau wie !!HELP!! besitzt dieses Projekt Unterstützung für Internationalisierung/Lokalisierung.
Unten der aktuelle Screenshot mit englischem Locale.
Gruß Axel
flaite:
Tja. Da rede ich so groß von: Wir-müssen-erstmal-eine-Design-Analyse machen und ich verliebe mich in Swing-the-Scott-Delap-way. ;D
Ich unterstütze jetzt verschiedene Ansichten.
Hab mir überlegt, dass man 2 "Navigatoren" anbietet:
1. für die Tickets an denen der User selbst beteiligt ist
2. Alle Tickets.
Der Anwender kann dann auswählen.
Ich hab jetzt die ganze Zeit an Punkt 1) gearbeitet. Hier sind verschieden sortierte Ansichten möglich (fertig ist: der User als Supporter, sortiert nach Status und nach Ersteller).
Die beiden Ansichten sind immer synchronisiert. Die Auswahl nicht. Ist aber erstmal nicht so wichtig.
Im Test benutze ich den User Heinz Ulrich Krause. Geht eigentlich ganz gut. Im Inneren werden es auch eher weniger als mehr öffentliche Methoden und das ist ein gutes Zeichen:
Der Prozess ist nicht unbedingt schnell aber kontrolliert. Aber ich lerne ja auch viel dabei.
Ulrich sollte mal ein titleProperty für TICKET und TICKETDETAIL spendieren. ;D
Axel
eknori (retired):
--- Zitat ---Ulrich sollte mal ein titleProperty für TICKET und TICKETDETAIL spendieren.
--- Ende Zitat ---
gerne, was soll denn da drinstehen ?
flaite:
Das ist eine gute Frage. Ich hätte einen Titel erwartet. Aber tatsächlich wird in HELP auch Problem in den Ansichten verwendet. Und da kann sehr viel drinstehen.
Zumindest in einem JTree halte ich das darstellungstechnisch für problematisch, auch wenn es technologisch machbar ist. Werd mir wohl fürs erste die ersten 20 Zeichen von problem holen.
Was mir jetzt bei HELP aufgefallen ist, sind die Auswahllisten (z.B. die Felder application, failureType und failureSubType). Für bestimmte Dokumente vom Typ "CONFIG":"CONFIGDEPENDAND" sollte es imho einen eigenen WSDL geben (find ich). Solche Konfigurationseinstellungen können dann im Client in einer eingebetteten HSQL oder Derby-Datenbank abgespeichert werden. So werd ichs in Java machen.
Der Swing Client kann ja einfach die Dokumente so wie in Notes darstellen.
Bitte schicke Datumsfelder nicht als String sondern als Datum runter.
Was ich nicht kapiere sind Aktionen und Teilaufgaben. Gibt es da eine Beschreibung für?
Übrigens gilt auch für die Internationalisierung, dass dies am besten synchronisiert wird. Ich hab mir bisher im Client meine eigene Mapping-Tabelle geschrieben. Ich sollte die gleichen Keys wie ihr in LanguageDocs verwenden. Ist es eigentlich normal, dass meine deutschen LanguageDocs alle englisch sind?
Gruß Axel
eknori (retired):
--- Zitat ---Was ich nicht kapiere sind Aktionen und Teilaufgaben. Gibt es da eine Beschreibung für?
--- Ende Zitat ---
Die Aktionen stammen aus der Ur-Zeit der Anwendung. Da habe ich einfach nur eine Möglichkeit eingebaut, Einzelaktionen zack zack hintereinander einzugeben. Quasi als Info, wenn mehrere an einem Ticket arbeiten.
Die werden aber spätestens in V 2.0 ebenso wegfallen, wie der Reiter Historie. Die Teilaufgaben werden die Aktionen ersetzen.
Beim Titel hatte ich eigendlich gedacht, daß man sich consumerseitig aus den übermittelten responses was passendes zusammenklöppelt. Mögicherweise habe ich da aber einen Denkfehler.
--- Zitat ---Für bestimmte Dokumente vom Typ "CONFIG":"CONFIGDEPENDAND" sollte es imho einen eigenen WSDL geben (find ich).
--- Ende Zitat ---
sehe ich genau so ...
Navigation
[0] Themen-Index
[#] Nächste Seite
Zur normalen Ansicht wechseln