Das Notes Forum

Domino 9 und frühere Versionen => ND6: Administration & Userprobleme => Thema gestartet von: guerilla am 09.05.05 - 17:07:38

Titel: DXL - Das alte Leid *g*
Beitrag von: guerilla am 09.05.05 - 17:07:38
Hallio Hallö.

Folgendes Problem tut sich auf:

Ich habe einen Import für DXL-Files (ich möchte Design-Elemente importieren, genauer gesagt File-Resourcen). Soweit so gut. Exportiere ich das DXL aus Notes, funktioniert das ganze auch ganz wunderbar.

Der Haken an der Sache ist folgender: Da ich einen ganzen Verzeichnisbaum durch (beispielsweise Perl) in ein DXL/XML verwandeln will, habe ich mal auf diverse "Weglassfähigkeiten" der Attribute getestet:
Die ReplicaID ist durch eine selbsgewählte Zeichenfolge ersetzbar, ebenso die NoteID (beide kann ich durch eine fortlaufende Nummerierung ersetzen lassen).

Das Problem an der Sache ist, dass dieses eben für die unid

Code
<noteinfo noteid='185' unid='2DE946FEE050A7FDC1256FF50028FB34' sequence='3'>

eben nicht gilt. Kann man die irgendwie umgehen, oder beim Einfügen der Elemente vergeben lassen / bzw. irgendwie errechnen (ausserhalb von Notes)? Falls Fragen zum Importer aufkommen, das ist der aus der Lotus-Notes-Hilfe, mit der Modifikation, dass die Dokumente nicht in eine dbCopy, sondern in die aktuelle eingefügt werden.

vielen Dank für Hilfe schon mal im vorraus
Titel: Re: DXL - Das alte Leid *g*
Beitrag von: Marinero Atlántico am 09.05.05 - 17:25:38
Hier schwirrten mal vor 2 Wochen dunkle Andeutungen durch den Raum (glaub es war Bernhard, KoehlerBv), dass man die DocUnid nach bestimmten Regeln selbst schreiben kann.
Titel: Re: DXL - Das alte Leid *g*
Beitrag von: guerilla am 09.05.05 - 17:41:00
Okay okay...

Ich geh ja schon mal in die Ecke, zum Schämen: :-[ :-X :-\

Die UNID wird automatisch erzeugt, wenn ich sie einfach komplett lösche.
Tut mir leid, ich bin halt eher vorsichtig beim desktruktiven Konstruktivismus (sprich: löschen).
Titel: Re: DXL - Das alte Leid *g*
Beitrag von: Semeaphoros am 09.05.05 - 18:24:53
Wie die UNID aufgebaut ist, lässt sich entweder in der C-API Doku nachlesen oder im Buch "Lotus Script to C-API" von Normunds Kalnberzins ( http://www.ls2capi.com )
Titel: Re: DXL - Das alte Leid *g*
Beitrag von: TMC am 09.05.05 - 22:41:44
Siehe auch:

Eknori: How to Generate a UNID (Universal ID) Using LotusScript (http://www.eknori.de/tipps/detail.php?nr=770&kategorie=tipps)
Titel: Re: DXL - Das alte Leid *g*
Beitrag von: koehlerbv am 09.05.05 - 22:55:47
Da gibt es auch einen ausführlichen KB-Artikel, aber ich glaube, der war nicht öffentlich.

Angesichts der Tatsache, dass die UNID eine absolut zentrale Rolle im internen Dokumentenhandling spielt: Ich kann aber kaum Fälle erkennen, in denen die manuelle Vergabe einer UNID wirklich Sinn machen würde. Beim Speichern eines neuen Dokuments vergibt - egal was oder wie man es macht - Notes sowieso eine eigene UNID, wenn man es nur lässt.

Der Weg, den der "Kleinkrieg" jetzt gewählt hat, ist schon ideal.

Bernhard

PS: Von wegen "Kleinkrieg": "Guerilla", kannst Du uns mal erläutern, warum Du einen in dieser Zeit dermassen negativ besetzten Begriff als nickname gewählt hast ?
Titel: Re: DXL - Das alte Leid *g*
Beitrag von: guerilla am 09.05.05 - 23:08:06
Vielen Dank für all die guten Tipps und Ratschläge, aber wie bereits erwähnt, hat sich das Thema erledigt.

@koehlerbv: Wäre denn, angesichts der Heuschreckenplage, die durch die Medien zieht, ein Vampir namens Lestat viel besser? ;D
Davon abgesehen existiert dieser Nickname schon ne ganze Weile für mich (ursprünglich guer|lla) und ich sehe nicht ein, nur weil die Ami's und irgendwelche Terroristen sich wieder mal in den Haaren haben, meinen Nick deswegen zu ändern.
Davon abgesehen bin und bleibe ich gerne ein Provokateur.

Titel: Re: DXL - Das alte Leid *g*
Beitrag von: koehlerbv am 09.05.05 - 23:10:16
Davon abgesehen bin und bleibe ich gerne ein Provokateur.

Das macht durchaus Sinn  ;)

Bernhard
Titel: Re: DXL - Das alte Leid *g*
Beitrag von: Marinero Atlántico am 09.05.05 - 23:43:04
Ausserdem bin ich ein großer Bewunderer des Perfektionierers jener Kriegstaktik im 19. Jhdt:
http://www.loc.gov/rr/hispanic/1898/maceo.html

Man kann das auch nicht direkt mit Kleinkrieg übersetzen.
Es ist viel mehr eine bestimmte Form der Kriegsführung mit den folgenden Merkmalen:
- große Ressourcenungleichheit zwischen Armeen. Eingesetzt von der mit weniger Ressourcen
- ressourcenärmere Armee kennt das Kriegsgebiet besser
- ressourcenärmere Armee ernährt sich aus dem Land (oft unterstützt von lokalen Bauern)
Guerrilla wurde früher nicht selten im Kontext von Sklavenbefreiung und nationaler Unabhängigkeit gegen *realen*Imperialismus eingesetzt. In jüngerer Zeit leider im Kontext von Drogenproduktion/schmuggel und totalitären Ideologien. Früher war es die einzige Möglichkeit, sich zur Wehr zu setzen. Heute leider oft eine Möglichkeit den Krieg ewig zu prolongieren.
Titel: Re: DXL - Das alte Leid *g*
Beitrag von: guerilla am 10.05.05 - 13:19:12
Zurück zum Thema:

Weiss zufällig jemand, wie der $FileData-Wert berechnet wird?
Ich hab festgestellt, dass es im Grunde eine Base64-Codierung ist, allerdings bekomme ich beim "normalen" (sprich: nicht Notes) kryptische Zeichen an den Dateianfang gebastelt und meine PerlScript-codierten Werte mag das Notes nicht.
Ich hab zum Beispiel eine css-Datei, die am Anfang einen Kommentar über mehrere Zeilen hat, der ist beim Encoding per "norm" durch o.g. Zeichen ersetzt.
Ist der "Notes-Base64" irgendwie reproduzierbar?
Titel: Re: DXL - Das alte Leid *g*
Beitrag von: m3 am 10.05.05 - 13:43:49
Das macht durchaus Sinn  ;)
"Das glaube ich nicht, Tim (http://de.wikiquote.org/wiki/H%C3%B6r_mal,_wer_da_h%C3%A4mmert)" ;)

Oder meinst Du "das hat Sinn (http://fb14.uni-mainz.de/~sth/sinnweb2.htm)"? ;) :D


Ad Base64: Der Standard: http://www.faqs.org/rfcs/rfc2045.html
Notes-Implementation: http://dev.kanngard.net/Permalinks/ID_20030324233829.html
Titel: Re: DXL - Das alte Leid *g*
Beitrag von: animate am 10.05.05 - 14:16:18
Ich hab festgestellt, dass es im Grunde eine Base64-Codierung ist,

Das stimmt, binäre Daten werden Base64encodiert

allerdings bekomme ich beim "normalen" (sprich: nicht Notes) kryptische Zeichen an den Dateianfang gebastelt und meine PerlScript-codierten Werte mag das Notes nicht.
Ich hab zum Beispiel eine css-Datei, die am Anfang einen Kommentar über mehrere Zeilen hat, der ist beim Encoding per "norm" durch o.g. Zeichen ersetzt.

Tut mir leid, das verstehe ich überhaupt nicht. Kannst du mal ein Beispiel posten vielleicht?
Titel: Re: DXL - Das alte Leid *g*
Beitrag von: guerilla am 10.05.05 - 14:42:11
Zuerst einmal folgendes: Nicht nur Binärdateien, sondern alle File-Resourcen werden base64-verschlüsselt.

Und als Beispiel:

fck_editor.css (Normal)
Code
/*
 * FCKeditor - The text editor for internet
 * Copyright (C) 2003-2004 Frederico Caldeira Knabben
 *
 * Licensed under the terms of the GNU Lesser General Public License:
 * 		http://www.opensource.org/licenses/lgpl-license.php
 *
 * For further information visit:
 * 		http://www.fckeditor.net/
 *
 * File Name: fck_editorarea.css
 * 	This is the default CSS file used by the editor area. It defines the
 * 	initial font of the editor and background color.
 *
 * 	A user can configure the editor to use another CSS file. Just change
 * 	the value of the FCKConfig.EditorAreaCSS key in the configuration
 * 	file.
 *
 * Version:  2.0 RC3
 * Modified: 2005-02-10 11:46:11
 *
 * File Authors:
 * 		Frederico Caldeira Knabben (fredck@fckeditor.net)
 */

body
{
	font-family: Arial, Verdana, Sans-Serif;
	font-size: 12px;
	padding: 5px 5px 5px 5px;
	margin: 0px;
	border-style: none;
	background-color: #ffffff;
}

.Bold
{
	font-weight: bold;
}

.Title
{
	font-weight: bold;
	font-size: 18px;
	color: #cc3300;
}

.Code
{
	border: #8b4513 1px solid;
	padding-right: 5px;
	padding-left: 5px;
	color: #000066;
	font-family: 'Courier New' , Monospace;
	background-color: #ff9933;
}

Daraus wird dann folgender String gebastelt:
Code
YQAcAAAAAwDSBAAAAQAAAAAAAAAAAAAAY3NzAGAA5AQAANIE0gQAAAAAAAAAAC8qCiAqIEZDS2Vk
aXRvciAtIFRoZSB0ZXh0IGVkaXRvciBmb3IgaW50ZXJuZXQNCiAqIENvcHlyaWdodCAoQykgMjAw
My0yMDA0IEZyZWRlcmljbyBDYWxkZWlyYSBLbmFiYmVuDQogKiANCiAqIExpY2Vuc2VkIHVuZGVy
IHRoZSB0ZXJtcyBvZiB0aGUgR05VIExlc3NlciBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlOg0KICog
CQlodHRwOi8vd3d3Lm9wZW5zb3VyY2Uub3JnL2xpY2Vuc2VzL2xncGwtbGljZW5zZS5waHANCiAq
IA0KICogRm9yIGZ1cnRoZXIgaW5mb3JtYXRpb24gdmlzaXQ6DQogKiAJCWh0dHA6Ly93d3cuZmNr
ZWRpdG9yLm5ldC8NCiAqIA0KICogRmlsZSBOYW1lOiBmY2tfZWRpdG9yYXJlYS5jc3MNCiAqIAlU
aGlzIGlzIHRoZSBkZWZhdWx0IENTUyBmaWxlIHVzZWQgYnkgdGhlIGVkaXRvciBhcmVhLiBJdCBk
ZWZpbmVzIHRoZQ0KICogCWluaXRpYWwgZm9udCBvZiB0aGUgZWRpdG9yIGFuZCBiYWNrZ3JvdW5k
IGNvbG9yLg0KICogDQogKiAJQSB1c2VyIGNhbiBjb25maWd1cmUgdGhlIGVkaXRvciB0byB1c2Ug
YW5vdGhlciBDU1MgZmlsZS4gSnVzdCBjaGFuZ2UNCiAqIAl0aGUgdmFsdWUgb2YgdGhlIEZDS0Nv
bmZpZy5FZGl0b3JBcmVhQ1NTIGtleSBpbiB0aGUgY29uZmlndXJhdGlvbg0KICogCWZpbGUuDQog
KiANCiAqIFZlcnNpb246ICAyLjAgUkMzDQogKiBNb2RpZmllZDogMjAwNS0wMi0xMCAxMTo0Njox
MQ0KICogDQogKiBGaWxlIEF1dGhvcnM6DQogKiAJCUZyZWRlcmljbyBDYWxkZWlyYSBLbmFiYmVu
IChmcmVkY2tAZmNrZWRpdG9yLm5ldCkKICovCg0KYm9keQ0Kew0KCWZvbnQtZmFtaWx5OiBBcmlh
bCwgVmVyZGFuYSwgU2Fucy1TZXJpZjsNCglmb250LXNpemU6IDEycHg7DQoJcGFkZGluZzogNXB4
IDVweCA1cHggNXB4Ow0KCW1hcmdpbjogMHB4Ow0KCWJvcmRlci1zdHlsZTogbm9uZTsNCgliYWNr
Z3JvdW5kLWNvbG9yOiAjZmZmZmZmOw0KfQ0KDQouQm9sZA0Kew0KCWZvbnQtd2VpZ2h0OiBib2xk
Ow0KfQ0KDQouVGl0bGUNCnsNCglmb250LXdlaWdodDogYm9sZDsNCglmb250LXNpemU6IDE4cHg7
DQoJY29sb3I6ICNjYzMzMDA7DQp9DQoNCi5Db2RlDQp7DQoJYm9yZGVyOiAjOGI0NTEzIDFweCBz
b2xpZDsNCglwYWRkaW5nLXJpZ2h0OiA1cHg7DQoJcGFkZGluZy1sZWZ0OiA1cHg7DQoJY29sb3I6
ICMwMDAwNjY7DQoJZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldycgLCBNb25vc3BhY2U7DQoJYmFj
a2dyb3VuZC1jb2xvcjogI2ZmOTkzMzsNCn0=



Dieser wiederum, bei decodierung mit einem "Normalen" base64-Algorhytmus zu folgendem:
Code
aÒcss`äÒÒ/*
 * FCKed
itor - The text editor for internet

 * Copyright (C) 200
3-2004 Frederico Caldeira Knabben

 * 

 * Licensed under
 the terms of the GNU Lesser General Public License:

 * 
		http://www.opensource.org/licenses/lgpl-license.php

 *
 

 * For further information visit:

 * 		http://www.fck
editor.net/

 * 

 * File Name: fck_editorarea.css

 * 	T
his is the default CSS file used by the editor area. It d
efines the

 * 	initial font of the editor and background
 color.

 * 

 * 	A user can configure the editor to use 
another CSS file. Just change

 * 	the value of the FCKCo
nfig.EditorAreaCSS key in the configuration

 * 	file.

 
* 

 * Version:  2.0 RC3

 * Modified: 2005-02-10 11:46:1
1

 * 

 * File Authors:

 * 		Frederico Caldeira Knabben
 (fredck@fckeditor.net)
 */


body

{

	font-family: Aria
l, Verdana, Sans-Serif;

	font-size: 12px;

	padding: 5px
 5px 5px 5px;

	margin: 0px;

	border-style: none;

	back
ground-color: #ffffff;

}



.Bold

{

	font-weight: bold
;

}



.Title

{

	font-weight: bold;

	font-size: 18px;


	color: #cc3300;

}



.Code

{

	border: #8b4513 1px s
olid;

	padding-right: 5px;

	padding-left: 5px;

	color:
 #000066;

	font-family: 'Courier New' , Monospace;

	bac
kground-color: #ff9933;

}

gut, oder?

Frage ist, wie ich den Notes-Code nachbauen kann? So wie ich das sehe hat der "normale" base64 nämlich [A-Za-z0-9+/=] wobei beim Notes + und = fehlen...
Titel: Re: DXL - Das alte Leid *g*
Beitrag von: m3 am 10.05.05 - 14:50:30
Wie machst Du das Base64 encoding?

Wenn ich Dein CSS-File nehme, bekomme ich mit

perl -MMIME::Base64 -0777 -ne "print encode_base64($_)" < x.css

folgendes Ergebnis:
Code
LyoKKiBGQ0tlZGl0b3IgLSBUaGUgdGV4dCBlZGl0b3IgZm9yIGludGVybmV0CiogQ29weXJpZ2h0
IChDKSAyMDAzLTIwMDQgRnJlZGVyaWNvIENhbGRlaXJhIEtuYWJiZW4KKgoqIExpY2Vuc2VkIHVu
ZGVyIHRoZSB0ZXJtcyBvZiB0aGUgR05VIExlc3NlciBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlOgoq
IGh0dHA6Ly93d3cub3BlbnNvdXJjZS5vcmcvbGljZW5zZXMvbGdwbC1saWNlbnNlLnBocAoqCiog
Rm9yIGZ1cnRoZXIgaW5mb3JtYXRpb24gdmlzaXQ6CiogaHR0cDovL3d3dy5mY2tlZGl0b3IubmV0
LwoqCiogRmlsZSBOYW1lOiBmY2tfZWRpdG9yYXJlYS5jc3MKKiBUaGlzIGlzIHRoZSBkZWZhdWx0
IENTUyBmaWxlIHVzZWQgYnkgdGhlIGVkaXRvciBhcmVhLiBJdCBkZWZpbmVzIHRoZQoqIGluaXRp
YWwgZm9udCBvZiB0aGUgZWRpdG9yIGFuZCBiYWNrZ3JvdW5kIGNvbG9yLgoqCiogQSB1c2VyIGNh
biBjb25maWd1cmUgdGhlIGVkaXRvciB0byB1c2UgYW5vdGhlciBDU1MgZmlsZS4gSnVzdCBjaGFu
Z2UKKiB0aGUgdmFsdWUgb2YgdGhlIEZDS0NvbmZpZy5FZGl0b3JBcmVhQ1NTIGtleSBpbiB0aGUg
Y29uZmlndXJhdGlvbgoqIGZpbGUuCioKKiBWZXJzaW9uOiAgMi4wIFJDMwoqIE1vZGlmaWVkOiAy
MDA1LTAyLTEwIDExOjQ2OjExCioKKiBGaWxlIEF1dGhvcnM6CiogRnJlZGVyaWNvIENhbGRlaXJh
IEtuYWJiZW4gKGZyZWRja0BmY2tlZGl0b3IubmV0KQoqLwoKYm9keQp7CmZvbnQtZmFtaWx5OiBB
cmlhbCwgVmVyZGFuYSwgU2Fucy1TZXJpZjsKZm9udC1zaXplOiAxMnB4OwpwYWRkaW5nOiA1cHgg
NXB4IDVweCA1cHg7Cm1hcmdpbjogMHB4Owpib3JkZXItc3R5bGU6IG5vbmU7CmJhY2tncm91bmQt
Y29sb3I6ICNmZmZmZmY7Cn0KCi5Cb2xkCnsKZm9udC13ZWlnaHQ6IGJvbGQ7Cn0KCi5UaXRsZQp7
CmZvbnQtd2VpZ2h0OiBib2xkOwpmb250LXNpemU6IDE4cHg7CmNvbG9yOiAjY2MzMzAwOwp9Cgou
Q29kZQp7CmJvcmRlcjogIzhiNDUxMyAxcHggc29saWQ7CnBhZGRpbmctcmlnaHQ6IDVweDsKcGFk
ZGluZy1sZWZ0OiA1cHg7CmNvbG9yOiAjMDAwMDY2Owpmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3
JyAsIE1vbm9zcGFjZTsKYmFja2dyb3VuZC1jb2xvcjogI2ZmOTkzMzsKfQoK

Was sich auch ohne Probleme wieder zurückverwandeln lässt.

Ich tippe daher auf ein Problem in Deiner Encoding-Routine. Schreibt die eventuell einen "Salt"-Wert an den Anfang?
Titel: Re: DXL - Das alte Leid *g*
Beitrag von: guerilla am 10.05.05 - 15:11:31
das encoding mach ich nicht. das macht notes, wenn es das dxl-File schreibt.

wenn ich per Perl das ganze encode und decode, hab ich den gleichen base64-string wie du.

Nur will Notes den aber halt nicht gelten lassen, das ist das Problem. Und wenn ich den Notes-base64-String in Perl encoden lasse, kommt das Ergebnis oben raus. Mit kryptischen Zeichen am Anfang.

BTW: Was ist ein Salt-Wert?
Titel: Re: DXL - Das alte Leid *g*
Beitrag von: m3 am 10.05.05 - 15:37:30
Ha!
http://www.developer.ibm.com/tech/faq/individual?oid=1:389:478:14:89795
Zitat
When an attachment is exported via DXL, why can't I decode the attachment's contents?
A: The DXL export functions encode binary information such as attachment data in base 64 for portability.

If the decoded attachment data isn't the same as the original file, it may have been compressed with LZ1 compression in Notes. The DXL functions automatically decompress attachments that are compressed with Huffman compression, but LZ1 attachments are not decompressed.

Ad Salt: http://de.wikipedia.org/wiki/Salz_%28Kryptografie%29
Titel: Re: DXL - Das alte Leid *g*
Beitrag von: guerilla am 10.05.05 - 15:43:36
Ich hab grade mal in die DTD von Notes geschaut, da ist der Huffman erwähnt:

Zitat
<!ELEMENT file ( created, modified, filedata )>

<!-- Attributes for <file>:
    desiredcompression:
                    This attribute is exported when the original encoding was huffman.  This is done so the filedata can be used by those without the Notes/Domino huffman decompression algorithm.

Only accepted value on import is 'huffman'.  Compression attribute value must be 'none'.
-->

Da hätte ich eigentlich gleich drauf kommen müssen.
Wenn ich das also richtig verstehe, müsste ich die Datei mit Huffman codieren/komprimieren, dann funzt der Import, oder verstehe ich das grade falsch...!? ???
Wenn dem so ist, bin ich ein super-riesen-Stück weiter. Dann muss ich mir nur noch den Verzeichnisbaumprinter zusammenklöppeln *seufz*
Titel: Re: DXL - Das alte Leid *g*
Beitrag von: m3 am 10.05.05 - 15:47:18
Also ich hab das so interpretiert, dass ein Atachment LZ1-encoded sein kann, aber nicht muss. Aber im Zweifelsfall würd ich das b62 File noch LZ1en, dann sollte es klappen - IMHO.
Titel: Re: DXL - Das alte Leid *g*
Beitrag von: guerilla am 10.05.05 - 16:14:51
also wenn ich den text aus der DTD und den aus der Developer-FAQ zusammenzähle:

DTD:
Einziges Format beim IMPORT ist huffman, ohne Kompression.

Dev-FAQ:
Beim EXPORT kann das File LZ1-komprimiert worden sein. Beim IMPORT werden nur Huffman's Decodiert, LZ1 dagegen nicht.

So hab ich's zumindest verstanden.
Aber das sind überschaubare Möglichkeiten, behaupte ich mal. Ich melde mich dann von der Front, wenn ich was raushab.

Ich denke mal, das fertige "Produkt" dürfte ziemlich interessant sein. ;)
Wer träumt nicht davon, Tools wie den FCK-Editor ohne großen Aufwand MIT einer "Filestruktur" direkt in eine Datenbank zu ballern? Ich hab mittlerweile genug Seiten durchsucht, auf die DXL-Schiene kam da noch keiner ;) Die haben alle das Zeuch per Hand reingeschoben und die Datenstruktur nachgebildet. (Gut, das hab ich auch getan, beim ersten mal, aber warum soll das nicht einfacher gehen?)
Einfacher wär's natürlich, wenn das im Notes direkt ginge, aber das geht ja nüscht ...
Titel: Re: DXL - Das alte Leid *g*
Beitrag von: guerilla am 16.05.05 - 00:12:37
UPDATE:
Also: Aufgrund nicht dokumentierter/reproduzierbarer Informationen in den $FileData-Werten ist es nicht möglich, einen für Notes validen String extern zu erzeugen, was im Klartext bedeutet: per DXL Fileresourcen zu importieren funktioniert nicht.

Vielen Dank trotzdem für die (leider vergeblichen) Mühen.

PS: Gibt es irgendwo Infos über nicht dokumentierte API-Funktionen? Besonders interessant fände ich eine Implementierung des "Add File Resource".

greetings
Chris
Titel: Re: DXL - Das alte Leid *g*
Beitrag von: TMC am 16.05.05 - 01:00:44
Ich bin nur "Hobby-DXLer", und hab auch mit Huffman noch keinen Smalltalk geführt  ;D

Aber was willst Du nun? Du hast da ein File und willst das in einem DXL-Textfile integrieren und dann als Notes-Dokument in eine Notes-DB schreiben?

Warum funktioniert denn nicht eine simple Base64-Codierung des Files?
Das Ergebnis dann ins <filedata> - Tag geworfen und dann das Textfile entsprechend importieren.

Wie Base64 encoden? Sicherlich ist Java da erste Wahl. Ich hab das mal mit LS gemacht: http://dev.kanngard.net/Permalinks/ID_20030324233829.html

Das müsste doch so gehen, oder? Zumindest war ich immer der Meinung dass das geht, bis ich jetzt dieses Posting gelesen habe.
Titel: Re: DXL - Das alte Leid *g*
Beitrag von: guerilla am 16.05.05 - 01:28:55
es geht nicht. Wenn ich Montag Dienstag in der Firma bin, schick ich dir gerne einen entsprechenden Beitrag aus notes.net zu. Oder du suchst da selbst mal nach einem Eintrag zum Thema "base64" von "Ruediger Seiffert".

Problem ist, dass Notes beim Export zu DXL einen Header vor die Informationen einfügt, der leider nirgendwo genau erläutert ist. Wenn ich das DXL-FileData zeuch mit base64 DEcodiere und den Header wegschnippel, ist das ja kein Thema, aber ich will ja ENcodieren und müsste den Header nachbilden, damit Notes das als valid erkennt.

Und da ich nicht weiss, wie der Header aussieht (beim DEcodieren bekommt man lustige Zeichen), kann ich ihn auch nicht nachbilden. PS: LOC war Perl, da gibts auch schon ein base64-Modul :)

PPS: Ich möchte das nicht als Dokument, sondern als Designelement speichern, genauer gesagt als File oder Imageresource (abhängig vom Dateityp).
Titel: Re: DXL - Das alte Leid *g*
Beitrag von: TMC am 16.05.05 - 01:48:05
Kann ich trotzdem nicht nachvollziehen.

Ich nehme ein normales Notes-Dokument. Dort hänge ich eine Textdatei an.

Inhalt der Textdatei:
Code
Hallo Welt.
AÖÜäöüß

Ich exportiere das Dokument in DXL.

Dort steht dann:
Code
<item name='$FILE' summary='true' sign='true' seal='true'><object><file hosttype='msdos'
 compression='none' flags='storedindoc' name='Hallo.txt'>
<created><datetime dst='true'>20050516T013633,50+02</datetime></created>
<modified><datetime dst='true'>20050516T013945,18+02</datetime></modified><filedata
>
SGFsbG8gV2VsdC4NCkHW3OT2/N8NCg==
</filedata></file></object></item>

Den Base64 - Teil (SGFsbG8gV2VsdC4NCkHW3OT2/N8NCg==) decodiere ich mit http://www.motobit.com/util/base64-decoder-encoder.asp.

Als Ergebnis erhalte ich wieder:
Code
Hallo Welt.
AÖÜäöüß

Beim Anhängen der Datei war "Compress" ausgewählt. Im DXL steht aber "compression='none'". Wird also wahrscheinlich beim Export entfernt.

Ich exportiere das NotesDocument via Lotus Script - nix besonderes:
Code
	Set exporter = session.CreateDXLExporter
	
	intFilenum = Freefile
	Open strPath For Output As intFilenum
	Print #intFilenum, exporter.Export(doc)
	Close intFilenum
Titel: Re: DXL - Das alte Leid *g*
Beitrag von: TMC am 16.05.05 - 02:09:28
Da fällt mir ein:
1.) Wie exportierst Du?
2.) Wie importierst Du?

3.) Welche Notes/Domino Version setzt Du ein?

Iris/IBM hat da bei den ersten 6er-Versionen noch Veränderungen/Verbesserungen vorgenommen. Also Bug Fixes und Features wie z.B. die ConvertNotesBitmapsToGIF Property beim Exporter, das kam glaub ich mit 6.0.2.
Titel: Re: DXL - Das alte Leid *g*
Beitrag von: Marinero Atlántico am 16.05.05 - 02:59:27
Mathias,

ich glaub Chris will das nicht einfach als Attachment oder eingebundenes Objekt sondern als File-Ressource. Da scheint Domino dann irgendetwas reinzumischen. Falls ich das richtig verstanden habe.
Titel: Re: DXL - Das alte Leid *g*
Beitrag von: guerilla am 16.05.05 - 12:11:10
Mathias,

ich glaub Chris will das nicht einfach als Attachment oder eingebundenes Objekt sondern als File-Ressource. Da scheint Domino dann irgendetwas reinzumischen. Falls ich das richtig verstanden habe.

Du hast :) (aber ich hab das auch mehr als einmal erwähnt...)

@Mathias:
Export: File Resourcen auswählen -> Tools -> DXL -> Exporter

Das ist aber eigentlich hinfällig, weil ich ja nichts exportieren will. Der "Export" sollte über Perl geschehen.

Import: Der Agent aus der Dominohilfe. Das hat auch geklappt, allerdings nicht mit selbstgemachten FileDatas. (eben wegen dem Header) Siehe dazu den folgenden Link:
http://www-10.lotus.com/ldd/nd6forum.nsf/55c38d716d632d9b8525689b005ba1c0/da57c862419394a385256fd50043fa2b?OpenDocument
Titel: Re: DXL - Das alte Leid *g*
Beitrag von: Marinero Atlántico am 16.05.05 - 12:46:57
Du hast :) (aber ich hab das auch mehr als einmal erwähnt...)
Sollte keine Kritik sein. Ich hau hier nur manchmal daneben.
Titel: Re: DXL - Das alte Leid *g*
Beitrag von: animate am 16.05.05 - 14:39:39
Siehe dazu den folgenden Link:
http://www-10.lotus.com/ldd/nd6forum.nsf/55c38d716d632d9b8525689b005ba1c0/da57c862419394a385256fd50043fa2b?OpenDocument

OMG! Das ist ja echt ziemlich beknackt.
Titel: Re: DXL - Das alte Leid *g*
Beitrag von: guerilla am 16.05.05 - 15:45:57
Sollte keine Kritik sein. Ich hau hier nur manchmal daneben.

Dito.