JavaAgent vs. neue Zeile (Newline)

[m3]

Also manchmal Frage ich mich schon, was die Mädls und Burschen von Iris/Lotus/IBM für ein Kraut rauchen. Anscheinend dürfte es ein Gutes sein. 

Ich hab hier eine bestehende Applikation, an deren Forms/Feldern/Views ich eigentlich nix ändern sollte. Aufgabe ist/war es, einen JavaAgenten zu schreiben, der Daten via LDAP holt und in verschiedenste Textfelder schreibt.

So weit, so gut, das macht er auch alles ganz brav, BIS AUF ...

... die besch_____ Newlines (neue Zeile; @Newline). Ich kann reinschreiben, was ich will. Von "\n" über "\r", verschiedenste Kombinationen davon, sogar mit evaluate hab ich es schon probiert. In der Javaconsole gibt er es richtig aus, im Form hab ich dann nur so schwarze Bemmerln, aber keine neue Zeile.

Auch das Umkopieren des Textes aus einem (korrekten) RTF funktioniert nicht.

Laut den notes.net Foren ist dem so und man kann auch nix daran ändern.

Ein Multivalue- oder RT-Feld kann ich nicht dafür nutzen und auch nicht neu einführen, hat wer von Euch ev. noch eine Idee???

[koehlerbv]

In LS muss man ja auch den Characterwert 10 einfügen statt 13. Versuche es doch mal auf diesem Wege, dieses Zeichen zu verwenden.

HTH,
Bernhard

[m3]

10 ist Newline ("\n")
13 ist Carrige Return ("\r")

Alles schon ausprobiert, kein Erfolg.

[koehlerbv]

Nö, Martin, ich meinte, das Zeichen direkt in den String einzufügen, so à la
"Zeile 1" & Chr$ (10) & "Zeile 2"
in LotusScript.

Bernhard

[Marinero Atlántico]

\n heisst in Java pro Plattform etwas anderes:
char(13) + char(10) auf Windows
char(10) auf Unix
Vielleicht auch ein bischen anders.
Seid ihr sicher, dass man in LotusScript in nicht RichText Feldern im Backend chr$(13) & Chr$(10) setzen kann und das auch noch funktioniert?
Vielleicht solltest du in Bob Balabans Looseleaf Forum posten.

@Bernhard: ich denke, das hat er gemacht. 

Gruß Axel

[m3]

Danke Leute, aber das hab ich alles schon probiert. Das dürfte wirklich ein Notes "Bug" sein. Auch bei Bob wurde das Problem bereits mehrmals ohne Ergebniss thematisiert.

[Marinero Atlántico]

Das dürfte wirklich ein Notes "Bug" sein.

Ich tippe auf die Auswirkung einer lange zurückliegenden Designentscheidung.
Der Begriff "Bug" ist für mich in diesem Kontext zu schwach.
Ein Bug ist für mich etwas, das mal eben durch einen fix behoben werden kann.

[m3]

Ok, ja. B0rken as designed.


BTW - ich hab nun doch eine Lösung gefunden:

Code

Vector fv = new Vector();
fv.addElement( "Text 1" );
fv.addElement( "Text 2" );
doc.replaceItemValue("History", fv);

und schon steht im Form
Text 1
Text 2
und nicht
Text1||Text2

Warum das auch bei reinen Textfeldern und nicht nur bei Multivaluefields funktionert versteh ich zwar nicht, aber ich freu mich drüber.

So, und dafür hab ich mir heute ein Bier verdient. 

[Marinero Atlántico]

congrats (auch für die Nerven)

[m3]

Grazie Mille.

Ich sch... damit schon seit Mittag herum, aber es hat mit einfach keine Ruhe gelassen. 

[sudsaat]

Hallo Martin,

der Thread ist zwar schon ein paar Tage alt, aber ich stehe gerade vor der gleichen Aufgabe mit Java eine Historie zu ergänzen und somit benötige ich ebenfalls einen Zeilenumbruch.

Dein Workaround für Domino 5 scheint in Domino 8 nicht mehr zu klappen (zumindest nicht wie in deinem Fall bei reinen Textfelder ohne Multiple-Values).

Hast du zufällig auch eine Lösung für Domino 8 parat? Multivalue und TextList kann ich leider nicht einführen.

Grüße Thomas

[pram]

Habt ihr schon mal den Character 0 ( \x00 oder wie auch immer man das in Java schreibt) probiert?

Hintergrund: ein @UrlEncode("Platform"; "Wert1" + @newLine +"Wert2")  ergibt: Wert1%00Wert2

Gruß
Roland

[sudsaat]

Hi Roland,

habs gerade mit '\u0000' auf Windows getestet, das Resultat ist, dass in Notes der String ab dieser Stelle abgeschnitten wird, also aus:

Code

"Das ist ein " + '\u0000' + "Zeilenumbruch"

wird in Notes:

"Das ist ein"

..und der Rest fehlt leider

Sonst noch eine Idee? Ist immens wichtig, da der Kunde das ohne Zeilenumbrüche nicht akzeptiert und "geht mit Java und Notes nicht" wikrt irgendwie lächerlich

Danke und Grüße
Thomas

[Peter Klett]

Mein Vorschlag ist sicherlich eine Krücke, aber von Java habe ich nicht wirklich Ahnung.

Wie wäre es denn, (falls es wirklich nicht funktionieren sollte), die Historie in ein Feld zu schreiben und keine Zeilenumbrüche, sondern stattdessen eine definierte Zeichenfolge ("\n" oder sonst etwas, was einigermaßen sinnvoll aussieht) zu schreiben. In der Maske wird dann nicht das so gefüllte Feld angezeigt, sondern ein Feld "berechnet zur Anzeige" mit der Formel @ReplaceSubstring (Feldname; "\n"; @Newline).

Ist nicht wirklich toll, aber wenn die Kundenakzeptanz dran hängt und es nur ein Historienfeld ist ...

[pram]

Ich kann den Vorschlag von Peter noch etwas ausbauen:

ein @ReplaceSubstring(@Char(13);@Newline) in der Eingabeumsetzung sollte ggf schon reichen.
du brauchst halt noch ein ComputeWithForm was aber ggf. Nebenwirkungen mit sich bringt

(zur Not ein Temp-Doc erstellen und dies mit einer simplen Form berechnen die nur ein berechnetes Feld enthält und anschließend das Item in dem das Ergebnis der Berechnung landet ins Original kopieren)

... zugegeben ein ziemlicher Hack...

Gruß
Roland

[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]

(@Peter, da hatten wir es doch vor kurzem davon)

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();
    }
  }
}

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();
    }

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)); 

Warum nicht einfach:

Code

doc.save(false, false, true);

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. 
}
}

Aber einfach nicht verunsichern lassen. So wichtig ist das alles nicht. Hauptsache es tut.

[Peter Klett]

Was soll eigentlich diese Zeile  

Code

do {} while (!doc.save(false, false, true)); 

Die hatte ich so aus einem Beispiel-Code aus der Notes-Hilfe zu document.save kopiert (Examples: save method).

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.