Lotus Notes / Domino Sonstiges > Projekt Bereich

Help-Webservice: serverseitiges Interface

(1/3) > >>

flaite:
Hi,

die Methode CREATETICKET(java.lang.String STRUSER, java.lang.String STRPROBLEM) gibt nicht einfach Ticket.ID zurück sondern ein Konstrukt der Art
Ticket.ID + "(" + errorCode + ")".
sieht ca. so aus:
EFG2347E (errCode:0)

Das erschwert eigentlich die Arbeit am Client.
Es wäre viel besser, wenn es ein ganzes Ticket zurückgeben würde und errorCode ein property wäre,
d.h. eigentlich noch besser errorCode wäre ein i18n Schlüssel für eine Klartextfehlermeldung in den verschiedenen Sprachen.

Ansonsten müsste ich den Rückgabewert erst einmal parsen. Es ist in my not so humble opinion viel besser, das Objektorientiert zu machen. Das heisst ein ganzes Ticket-Objekt wird zurückgeliefert. Ich kann dann einfach so abfragen:

--- Code: ---if (ticket.errorCode != 0) {
  throw new ServerException (AppUtils(listErrorKeys(ticket.errorCode));
}

oder noch besser (mit i18N Schlüssel):
if (ticket.errorKey != "") {
 throw new ServerException (AppUtils.get(ticket.errorKey);
}

--- Ende Code ---
String AppUtils.get(String key) ist mein i18n Mechanismus. Mit Nümmernchen müßte auf dem Client nochmal eine extra-Liste aufgebaut werden, die die Nümmernschen zu den i18n-Schlüsseln mappt.

So haben wir eine viel klarere Nachricht. Mit der jetzigen Lösung führen wir da eine Datenstruktur, die extra wieder low-level geparsed werden müßte. Nicht das ich das nicht könnte. Das oben beschriebene ist aber wesentlich einfacher, übersichtlicher und erweiterbarer.

Das ist letztlich ein großer Vorteil von OO.
Die Nachricht dokumentiert sich letztlich selbst.
Die Teilinfos der Nachricht stehen in den Properties des Objekts und müssen nicht aus einer proprietären Struktur rausgeparsed werden.

Gruß Axel

eknori (retired):

--- Zitat ---Ticket.ID + "(" + errorCode + ")".
--- Ende Zitat ---
Da bin ich davon ausgegangen, daß der Consumer das durch simple Stringzerlegung in die Bestandteile TicketID und RetCode zerlegt, um mit diesen Infos weiter zu arbeiten.

Ich glaube, ich muss mich davon lösen, so zu denken.


--- Zitat ---Es wäre viel besser, wenn es ein ganzes Ticket zurückgeben würde und errorCode ein property wäre,
--- Ende Zitat ---

Genau das ist dann die logische Konsequenz.

Dann könnte man auch gleich mit dem Ticket weiterarbeiten ...

flaite:
Rein technisch ist es nicht so schwierig damit umzugehen.
Nur ist es deutlich einfacher mit einem zurückgegebenen Objekt.
Die Objekte müßten dann jeweils ein Feld Error_msg enthalten.

Gemäß best practices für SOA (Service Oriented Architecture) sollten Fehlermeldungen eigentlich im Header der Nachricht stehen, also von den eigentlichen Rückgabewerten getrennt sein.
Weiss aber nicht, wie man das mit Lotus Webservices machen soll.

Solche Konventionen mögen oft ein bischen übertrieben erscheinen, aber sie machen oft Sinn. Ich hoffe, dass Lotus das blickt. Der Vorteil von SOAP gegenüber konkurrierenden Technologien ist ja, dass sich Toolhersteller auf gewisse Standards verlassen können. Codegenerierung kann hierdurch sicher erleichtert werden.
Z.B. erfordert rein auf der Swing-Seite das Binding Framework von Karsten Lentzsch auch gewisse Konventionen in den Objekten, die Daten halten. Nur konnte ich nach dessen Einführung in die Codebase massig Zeilen löschen und dabei hab ich das alles noch nicht voll verstanden. ;D

Gruß Axel

eknori (retired):

--- Zitat ---Weiss aber nicht, wie man das mit Lotus Webservices machen soll.
--- Ende Zitat ---

Die Stelle habe ich leider auch noch nirgendwo gefunden ...

flaite:
Yup. Ich auch nicht. Aber zumindest können wir die Punkte identifizieren. Dies ist auch nicht so schlimm. Die zurückgesendeten Objekte können beispielsweise ein Feld error_msg enthalten, dass im Client jedesmal abgefragt wird. Bei Rückgabewerten, die kein eigenes Objekt sind, sondern ein SOAP-Typ (String, int, etc) ist das natürlich nicht so schön.
... und jetzt habe ich verstanden, warum im SOAP error-Informationen im header stehen sollen.  ;D
... und wenn wir das alles gut durchdacht haben, können wir uns an Notes.net wenden oder sogar irgendwie zielgerichteter an irgendwelche Lotus Leute herankommen.

Ein wenig allgemeinere Information über den Stand der Dinge:

Ich bin zur Zeit mit Swing Features beschäftigt. Und auch mit dem Adaptieren von Scott Delaps Ideen. Es ist schon teilweise sehr schön. Nur manchmal kapiere ich das eben nicht richtig.
So Ideen wie:
- builder für die Gui Masken
- eine Art anwendungsglobale Benachrichtigungszentrale für Ereignisse aus dem Backend an die GUI
- Carsten Lentzschs Binding & Validation Frameworks

revolutionieren aber geradezu mein Verständnis für GUI-Programmierung. Deshalb sehe ich das als keine vertane Zeit an.
Vieles von dem kann man sehr sicher auch für Eclipse RCP (Hannover), J2ME (java auf mobile) oder Applets in Notes nutzen.
Es benutzt eine ziemlich weite Batterie von Java-Möglichkeiten:
1 Event-Handler steht z.B. als innere Klasse in einer abstrakten Klasse und die den jeweils initialisierenden konkreten Subklassen schiessen einen spezifischen Methoden Namen in den Constructor, der dann in einer Methode des Eventhandlers per Reflection ausgelesen wird.
Und das sensationelle ist: Es macht Sinn  ;D

Ich werd mich bemühen, das irgendwann alles mal zu beschreiben.
Probleme macht zur Zeit v.a. ein Gui Feature:
Wenn ein neues Ticket erstellt wird, soll dieses Ticket in den GUI-Navigatoren sofort vorhanden sein und dort auch ausgewählt sein.
Scheint nicht so einfach zu sein.
Was bereits funktioniert (und Notes hat das nicht): Wenn ein Ticket in z.B. dem View Navigator Tickets-nach-Status ausgewählt wird, dann wird es im Hintergrund auch in allen anderen View Navigatoren ausgewählt.
Swing ist insgesamt ein sehr mächtiges und damit auch nicht ganz leicht zu beherrschendes Framework.
Endgültig werde ich spätestens am nächsten Wochenende (ja, ich weiss), das erste alpha auf sourceforge uploaden. Mark Teichmann hat inzwischen Dev-Rechte auf das Projekt und wir seinen RCP-Eclipse code wohl schon vorher uploaden.


Mir gehts v.a. auch darum, nicht einfach einen look-mummy-its-with-webservice Typ von Beispiel zu erstellen, sondern eine wirkliche Erweiterung von help. Ich habs ja im Wiki geschrieben, dass so Dinge wie die Integration von "globalen Domino-Services" wie Locking und Security in der Praxis die wirkliche Arbeit machen. Aber das ist eben der kreative und software-engineering Teil der Arbeit.

Gruß Axel

Navigation

[0] Themen-Index

[#] Nächste Seite