Domino 9 und frühere Versionen > Entwicklung
JavaAgent vs. neue Zeile (Newline)
sudsaat:
Hallo zusammen,
vielen Dank für eure Vorschläge. Bei neuen Feldern die ich anlege habe ich bereits einen Workaround über 2 Felder gemacht. Das eine wird befüllt mit "|" als Trenner und das andere berechnet zur Anzeige mit @Replace(...).
Leider hängt am Historienfeld ein Rattenschwanz den nicht nicht 100%ig abschätzen kann, was ich bisher weiß um diese Lösung einzuführen:
- 3 Notes Libraries anpassen, die ebenfalls die Historie dann über "|" erzeugen müssen (eine client, server und interface-lib)
- einen Migrationsagenten der über ein paar Tausend Dokumente rattert (ok, das würde ja gehen)
- Anpassung der Form
soweit ja "nur" fleißarbeit, aber das Feld wird ebenfalls für die revisionssichere Ablage in Archiv-Systemen herangezogen, daher hat der Wirtschaftsprüfer ein besonderes Augenmerk darauf gelegt (weiß also nicht, ob dieser Workaround durchgehen würde). Weiter müssten die Export-Agenten für alle realisierten Archivsysteme (Infostore, Easy Enterprise, ..) angepasst und genau zu einem Zeitpunkt X umgestellt werden... und das alles weil IBM keine Zeilenumbrüche über Wrapper-Klassen hinbekommt?!?
Der Rattenschwanz ist mir ein wenig zu Heikel und auch (wie leider so oft) wieder ein viel zu teurer workaround in Notes (@Peter, da hatten wir es doch vor kurzem davon)
Bin also weiter an allen Ideen, Vorschläge und Lösungen interessiert.
Grüße Thomas :)
Peter Klett:
--- Zitat von: sudsaat am 05.04.11 - 19:47:54 ---(@Peter, da hatten wir es doch vor kurzem davon)
--- Ende Zitat ---
Darauf hab' ich gewartet ;)
Gibt es einen triftigen Grund, warum der Agent in Java geschrieben sein muss? Mit Script ist das schließlich kein Problem
Peter Klett:
Du kannst mir zu meinem ersten selbstgeschriebenen (oder zusammenkopierten) Java-Agenten gratulieren. Das Thema hat mich ja nun doch irgendwo gejuckt. Nach ein bißchen Hilfe-Stöbern bin ich zu folgender Lösung gekommen:
--- Code: ---import lotus.domino.*;
public class JavaAgent extends AgentBase {
public void NotesMain() {
try {
Session session = getSession();
AgentContext agentContext = session.getAgentContext();
DocumentCollection dc = agentContext.getUnprocessedDocuments();
Document doc = dc.getFirstDocument();
Stream stream = session.createStream();
stream.writeText("Zeile1", Stream.EOL_CR);
stream.writeText("", Stream.EOL_LF);
stream.writeText("Zeile2");
stream.setPosition(0);
doc.replaceItemValue("Test", stream.readText());
do {} while (!doc.save(false, false, true));
} catch(NotesException e) {
e.printStackTrace();
} catch(Exception e) {
e.printStackTrace();
}
}
}
--- Ende Code ---
Der tut unter 8.5.1 genau das, was er soll.
Der Trick ist bei den Stream.EOL_CR und _LF. Wenn man nur den Stream.EOL_CRLF nutzt, wird der Zeilenumbruch in der Felderliste angezeigt, aber nicht im geöffneten Dokument. Vermutlich sind da die Zeichen 13 und 10 vertauscht (laut Hilfe ist EOL_CR = ASCII 13, EOL_LF = ASCII 10 aber EOL_CRLF = ASCII 10 + 13. Korrekt wäre aber ASCII 13 + 10. Vermutlich stimmt die Doku mit der Umsetzung überein).
Durch die einzelne Verwendung von EOL_CR und _LF stimmt dann die Reihenfolge wieder.
Möglich, dass da noch ein paar Unsauberkeiten drin sind (z.B. sehe ich gerade zwei catch (Exception), da ist bestimmt einer doppelt?), aber vielleicht hilft Dir die Kernaussage weiter.
flaite:
2 catch sind ok. Du kannst aber auch einfach die erste löschen.
Oder versuch die mal umzudrehen.
catch Exception vor catch NotesException. Und dann gucken, was der Compiler sagt.
In meinem aktuellen Projekt würd ich das so schreiben, aber das ist halt auch irgendwie chi chi. ;)
--- Code: ---} catch(Exception e) { // NOSONAR catching RuntimeException is save in this context.
e.printStackTrace();
}
--- Ende Code ---
Da laufen statische Code-Analysen drüber und das würd gegen eine Regel verstossen. Ein Programm Sonar aggregiert die Verstösse. Da in bestimmten Kontexten das Verstösse-Anmeckern eigentlich keinen Sinn macht, läßt sich das mit einem Sonar Kommentar begründet ausschalten.
Was soll eigentlich diese Zeile ???
--- Code: ---do {} while (!doc.save(false, false, true));
--- Ende Code ---
Warum nicht einfach:
--- Code: ---doc.save(false, false, true);
--- Ende Code ---
Ich würd den stream sicher schliessen. Müsste man auch in LotusScript machen, macht nur keiner. Falls zwischen dem Öffnen des Streams und dem schliessen ein Fehler auftritt, wird das schliessen nie erreicht. Finally wird dagegen immer aufgerufen. In Java7 gibt es ein try with ressources AutoCloseable Feature, das diese traditionelle Turnübung unnötig macht.
--- Code: ---stream.writeText("Zeile2");
stream.setPosition(0);
stream.close();
stream = null;
} catch(Exception e) { // NOSONAR catching RuntimeException is save in this context.
e.printStackTrace();
} finally {
if (stream != null) {
try {
stream.close();
} catch (IOException ioe) {} // NOSONAR empty catch is fine to close stream in finally.
}
}
--- Ende Code ---
Aber einfach nicht verunsichern lassen. So wichtig ist das alles nicht. Hauptsache es tut.
Peter Klett:
--- Zitat von: Pitiyankee am 06.04.11 - 00:19:46 ---Was soll eigentlich diese Zeile ???
--- Code: ---do {} while (!doc.save(false, false, true));
--- Ende Code ---
--- Ende Zitat ---
Die hatte ich so aus einem Beispiel-Code aus der Notes-Hilfe zu document.save kopiert (Examples: save method).
--- Zitat ---This agent saves a document. The agent keeps trying if the document is not saved because someone else modified it while the program was running.
--- Ende Zitat ---
Navigation
[0] Themen-Index
[#] Nächste Seite
[*] Vorherige Sete
Zur normalen Ansicht wechseln