Fragen zu Items mit $

[Fraiser]

Hallo

Welche besonderheit haben Items, die mit $ anfangen? 

$File dient ja "nur" zur internen verwaltung (wenn ich das richtig verstande hab)

Fragen:

1) dienen $-Items immer nur der internen Verwaltung?

2) Kann man selbst Items erstellen die mit $ anfangn?

3) wenn ja, werden diese anders behandelt?

Falls jemand nen Link zu dem Thema hat, bin ich natürlich sehr dankbar.


Danke für eure Hilfe

[koehlerbv]

Items, deren Namen mit "$" beginnen, werden in jeder Hinsicht identisch zu den Items behandelt, deren Name mit einem anderen Zeichen beginnen. Selbstverständlich kann man Items mit diesem Namen auch selbst anlegen.
Es gibt jedoch Items, die man nicht überschreiben kann - das ist Notes davor. Beispiele: $UpdatedBy, $Revisions. Das hat allerdings nichts mit dem $-Zeichen zu tun.

Bernhard

[flaite]

$ bedeutet in Notes sowas wie "vom System gesetzt" (würd ich sagen).
Ist aber (vermutlich) eher eine Konvention. Versuch mal selbst ein Feld zu erzeugen und es mit $xxxx zu benamsen. Glaub das geht.
Mach dir
Bei $File ist es ein Hinweis auf Attachments (Data Type: Attached)
$UpdatedBy ist einfach eine Textliste
$Mailer ist ein Feld vom Typ RFC822 Text



Gruß Axel

[Fraiser]

erstmal danke für eure antworten

Ich muss ein Notes-Dokument in XML darstellen.

Bei $File können manche Zeichen aber nicht dargestellt werden. Deshalb wollte ich wissen, welche ich Base64 kodieren muss.

Also ist der Name des Items nicht ausschlaggebend.

Könnte man also sagen, das Items vom Type Richtext und Attachement  in Base64 kodiert werden müssten?

[ata]

.. Einen Feldtyp "Attachment" gibt es nicht - die werden in einem Rich-Text-Feld angelegt - falls vorhanden - und werden dann in $File-Feldern vorgehalten...

Toni

[flaite]

Anton: Es gibt aber den Datentyp: Attached Object
Hat aber keine große praktische Bedeutung, weil man an sowas als Entwickler normal nicht drankommt. Vermutlich ist der Feldtyp noch nicht mal öffentlich spezifiziert.
 
Field Name: $FILE
Data Type: Attached Object
Data Length: 48 bytes
Seq Num: 2
Dup Item ID: 0
Field Flags: ATTACH SIGN SEAL SUMMARY

Und Fraiser:
Die Arbeit mit der Darstellung in xml macht Domino schon selbst.
Guck dir mal die Klasse DXLExporter an.

DXL IST XML.

[ata]

@Axel

Anton: Es gibt aber den Datentyp: Attached Object

... ich spreche auch nur von einem Feldtyp "Attachment", den es nicht gibt - Datentypen gibt es noch einige mehr, an die man so nicht direkt drankommt... 

Toni

[diali]

...
Bei $File können manche Zeichen aber nicht dargestellt werden. Deshalb wollte ich wissen, welche ich Base64 kodieren muss.
...

also $File ist der Base64 codierte Anhang. Willst Du es decodieren, musst Du auch alle Zeichen mit Base64 decodieren!!!

[flaite]

Ja, aber es ist komplett hoffnungslos. Vorallem, wenn man versucht aus den Inhalten der $Files wieder das ursprünglich herein-attachte File herzustellen.
Aus diesen und 120 anderen Gründen sollte man es eben nicht selber machen. Notes erzeugt ja mit DXLExporter XML.

[diali]

Ja, aber es ist komplett hoffnungslos. Vorallem, wenn man versucht aus den Inhalten der $Files wieder das ursprünglich herein-attachte File herzustellen.

zu Notes 4.5, 4.6.x und 5.0 Zeiten ging es nicht anders. Also hoffnungslos ist es nicht sondern nur etwas aufwendiger.

Allerdings würde ich es mit Notes 6.x auch über den DXLExporter, NotesStream und den NotesDomParser machen.

[flaite]

Kannst du mir bitte zeigen, wie man aus den Informationen aus $File eine brauchbare Datei extrahiert. 

[diali]

der Inhalt von $FILE (ist ja nur ein Base64-codierte Binärdatei, d.h. die Daten liegen als String vor) kann
- vor Notes 5.0.2 mit der Base64-Klasse von Julian Robichaux (http://www.nsftools.com/) decodeirt werden
- ab Notes-Version 5.0.2 mit den NotesMime...-Klassen decodiert werden
und in eine Binär-Datei geschrieben werden.

Dabei arbeiten die NotesMime...-Klassen schneller als die Base64-Klasse von Julian Robichaux (vor Notes 5.0.2 ist mir dazu aber keine Alternative bekannt). Unter 5.x habe ich allerdings dies nicht angewendet, die Version haben wir übersprungen.

[flaite]

Dirk,

Base64 ist hier einfach nicht mein Punkt. Das ist trivial.
Mein Problem ist:
Die Information über die Attachments verstreuen sich über mehrere $File Felder.
Wie weisst du, in welcher Reihenfolge die zusammengesetzt werden.
Wenn du 2 Attachments im Dokument hast. Wie weisst du wo Attachment 1 aufhört und Attachment 2 anfängt?
In einem RichText-Feld kann neben den Attachments auch Tabellen, Formatierungen, Abschnitte uvam. gespeichert werden.
Warum soll man das auslesen und sich ein eigenes XML Format ausdenken, wenn es das mit dxl schon gibt?


Gruß Axel
 

[diali]

Die Information über die Attachments verstreuen sich über mehrere $File Felder.
Wie weisst du, in welcher Reihenfolge die zusammengesetzt werden.

dafür stehen in den Feldern Zeitstempel.

Wenn du 2 Attachments im Dokument hast. Wie weisst du wo Attachment 1 aufhört und Attachment 2 anfängt?

Also dies ist etwas aufwändiger. Über die EmbeddedObject kann ich pro Anhang den Namen und den Source ermitteln. Im Feld $FILE steht der intern verwendete Dateiname drin über die vorher ermittelte Abhängigkeit Name <=> Source kann ich den Dateinamen wieder herstellen.

In einem RichText-Feld kann neben den Attachments auch Tabellen, Formatierungen, Abschnitte uvam. gespeichert werden.
Warum soll man das auslesen und sich ein eigenes XML Format ausdenken, wenn es das mit dxl schon gibt?

DXL gibt es erst ab Version 6. Vorher ging es nicht anders (außer über zusätzliche Tools). Ja ich habe meine Anwendungen, als wir auf 6.x umgestiegen sind, auch angepasst und arbeite mit dem DXLExporter, NotesStream, NotesDomParser usw. Den Aufwand würde ich auch nicht mehr treiben dies nativ zu machen.