[Gelöst] XmlPort verschluckt Zeilenumbrüche beim Import?

Ich habe einen XmlPort erstellt, bei dem ich einen Knoten habe mit dem Node Type = Element und dem SourceType = Text. Der Text, der in diesem Knoten enthalten ist, enthält einen Zeilenumbruch (CR LF). Wenn ich vor dem Import den gesamten XML-Text ausgebe per Message, ist der Zeilenumbruch auch da. Aber im Import::OnAfterAssignVariable - Trigger des o.g. Knotens scheint der verschwunden zu sein.

Lösung
Property "PreserveWhiteSpace" im XMLPort auf "Yes" setzen. (Globale Property, nicht Feld-bezogen)

Ursprüngliche Problembeschreibung:

Folgende Test-Funktion führt zu "nichts erkannt":

Code:

LOCAL ReplaceCrLfWithBr(ParText : Text) ReturnText : Text
LF := 10;
CR := 13;
CarriageReturn := FORMAT(CR) + FORMAT(LF);
IF STRPOS(ParText, FORMAT(CR)) <> 0 THEN BEGIN
  ERROR('Carriage Return erkannt');
END ELSE IF STRPOS(ParText, FORMAT(LF)) <> 0 THEN BEGIN
  ERROR('Line Feed erkannt');
END ELSE BEGIN
  ERROR('nichts erkannt');
END;

Auch wenn ich den Wert des o.g. Knotens direkt im o.g. Trigger per Error ausgebe, ist kein Zeilenumbruch mehr enthalten. Schmeißen XML-Ports die Zeilenumbrüche beim Import einfach weg?

Ich würde es jetzt mal damit versuchen, dass ich ein "CDATA" in der XML einfüge für den o.g. Knoten direkt nach dem Download, bevor ich die XML in den XMLPort kippe. Gibt es dafür evtl. eine elegantere Lösung?

(ich musste auch schon das Attribut "xml:lang" vor der Verarbeitung durch "xmllang" ersetzen, weil XmlPorts nicht mit Doppelpunkten in Attributsbezeichnungen klar kommen . Ich bin echt kein Fan von XmlPorts, das ist wieder sowas halbgar drangeflanschtes, ähnlich wie RDLC.)

Update - selbst mit CDATA gehts nicht

Code:

      <KNOTEN_TEXT>
        <VALUE xml:lang="x-default"><![CDATA[Test vor Absatz.

Das ist ein Test nach einem Absatz]]></VALUE>
        <VALUE xml:lang="x-bmde"><![CDATA[Test vor Absatz.

Das ist ein Test nach einem Absatz]]></VALUE>
      </KNOTEN_TEXT>

Zuletzt geändert von InfoWissler am 23. Juni 2021 11:15, insgesamt 1-mal geändert.

Ich bin echt kein Fan von XmlPorts, das ist wieder sowas halbgar drangeflanschtes, ähnlich wie RDLC.)

Wenn du kein Fan bist, warum verwendest du dann einen XMLPort?
Muss ja anscheinend irgendwas Magisches an sich haben :P
Es gibt viele Anwendungsfälle, wo ein XMLPort völlig ausreicht - den also als halbgar zu bezeichnen, halte ich für fragwürdig.

Versuch's mal über den "XML Buffer"

Hallo,

also so ganz von der Hand zu weisen ist InfoWisslers Kritik nicht, wenn du wirklich XML- machen musst/ bist du mit den XML- Ports ganz schnell am Ende (oder warum benutzt NAV da wo wirklich XML- gemacht werden muss MSXML via DotNet?)

Bei CSV/Txt- Importen bist du mit einem Report den du dir einmal erstellst, auch wesentlich flexibler und anwender freundlicher unterwegs als mit einem XML-Port.

Gruß Fiddi

sicher, sage ja nicht dass es falsch ist, oder das die XMLPorts total super wären - sind sie nicht, das sollte klar sein ;).
aber halbgar sind sie aus meiner Sicht nicht - sie machen was sie sollen -> einfache Ex-/Importfunktionalität bereitstellen.

ich stimme eher zu, dass RDLC halbgar (wenn nicht noch schlimmer) ist

ich stimme eher zu, dass RDLC halbgar (wenn nicht noch schlimmer) ist

Was den Belegdruck angeht sicherlich. Aber auch da habe ich bis auf die Sache, die Belegsumme unten auf den Beleg zu drucken, alles hin bekommen, was auch im NAV- Report Designer möglich war.

Im Nachhinein, muss ich sogar sagen, das man mit dem RDLC- Report Dinge sogar wesentlich einfacher realisieren kann, als mit dem NAV- Reports. Und das betrifft auch die Belegreports.
Für Listen und ähnliches ist RDLC eigentlich super, man muss es nur erst einmal verstanden haben.
Und da liegt das eigentliche Problem: Hätte sich jemand von MS der sich mit RDLC wirklich auskennt vor der Umstellung auf RDLC die (Beleg)- Berichte wirklich so angepasst, das sie (fast) wie vorher funktionieren, dann wäre es für die Anwender und Entwickler wesentlich einfacher gewesen umzusteigen, anstatt diesem halbgaren Konvertierungstool, und den an dieses Tool angepassten in der Funktion reduzierten (Beleg)-Berichten.

Gruß Fiddi

Ich habe in den Ausgangspost die Lösung hineingeschrieben: Property "PreserveWhiteSpace" im XMLPort auf "Yes" setzen. (Globale Property, nicht Feld-bezogen)