RichTextItem durchsuchen (FindFirstElement(RTELEM_TYPE_DOCLINK)

[bernino1]

hallo miteinander,

wir haben hier eine domino-website die von den mitarbeitern selbst gewartet wird.

beim löschen von hotspots gibt es dabei immerwieder folgendes problem:
z.B. wenn ein bild einen doclink hatte und du später auf das bild klickst um es zu löschen fällt das bild zwar raus - der doclink bleibt aber im sourcecode des notesdocuments. (man müsste das bild wie text markieren und löschen) der hotspot ist zwar nicht sichtbar - aber - da im html-code des browsers aufgelistet - trotzdem nicht schön 

ich hab nun ein script geschrieben, das mir alle doclinks in einem RichTextFeld mit dem "HotspotText" ausliest.

das funktioniert auch prima - sobald aber ein DocLink auf einem bild gesetzt ist kann ich in der NotesRichTextDocLink - klasse keinen unterschied mehr zwischen "leeren" hotspots und hotspots auf bildern erkennen.
in beiden fällen ist die information die ich aus "NotesRichTextDocLink" bekomme identisch!!

ich möchte aber alle "leeren" doclinks/hotspots aus dem RichTextFeld löchen?
sprich - ich müsste es schaffen per script zu erkennen ob hinter dem doclink ein bild ODER ein ""(leerstring) steht!

hat irgendeiner von euch eine idee wie das zu lösen wäre?

[flaite]

DXL ist eine Option, die mit neueren Optionen immer besser wird.
Ich hab dazu jetzt keinen Source-Code, aber vor allem wenn es eine einmal Operation ist, ist es eine Überlegung wert.

[bernino1]

buoaahh hey 

DXL ist ja ein fettes zeug!
hab mal einen export eines einzelnen dokumentes gemacht, den code im editor aufgeräumt und dann wieder per DXL importiert.
funzt soweit prächtig. er aktualisiert in der notes-db das dokument und die fehlerhaften links sind weg! SUPER!!!

mir ist jedoch schleierhaft wie ich das aufräumen des files automatisieren kann.
dieses DXL-Format schiebt mir einfach zeilenweise die tags raus. hier einen agent zu schreiben der das ganze file (meine test-db ergab ein 190mb!! file) zeile für zeile durchliest ist schon ein bisschen hatschert - oder?

und die einfache umwandlung in XML bringt mir ja auch noch nix.

hast du da noch eine idee wie ich automatisiert das DXL in ein XML mit passendem DTP hin und wieder zurückverwandeln kann?
genau das brauch ich jetzt noch - oder?

[flaite]

Puristen würden sagen XSLT.
Ich würde sagen: XSLT ist die Sache, wo Leute 5 Tage lang sagen: Es ist nur noch eine Kleinigkeit. Ich  bin gleich fertig.
DXL ist XML.
XML ist eigentlich mehr eine Art Meta-Beschreibungssprache, auf deren wenige Regeln andere Beschreibungssprachen (wie DXL) mit einer strikteren Grammatik/Semantik aufsetzen, die in DTDs, Xml-Schema definiert werden.
Also: Du kannst DXL in einen xml parser jagen.
Für die Verarbeitung komm ich am besten mit XOM, JDOM mit der Verwendung von Xpath klar (auf Java). 
Von der DOM Api kann ich abraten.
Das so gewonnene Wissen kann dann auch für JavaScript-Dom-Scripting und Webservices eingesetzt werden.

BUT: Das ganze hat einen Haken. IBM garantiert nicht, dass ein Dokument nach Export/Import noch wirklich genauso aussieht. Vorallem wenn die Maske recht komplex ist. Ein Kollege hat aber im letzten Jahr wirklich recht viele Dokumente so bearbeitet und hatte keine Probleme.
 

[bernino1]

Ich hab gestern Abend mal einen reinen Export-Import Test mit mehreren (ca. 15) Dokumenten gemacht und den Code dazwischen händisch verändert.

Habe dabei auch sinnlose Leerzeilen und Tabstopps eingebaut und die genannten fehlerhaften Links entfernt.

Es hat ausnahmslos ohne Fehler geklappt.
Alle Dokumente wurden aktualisiert und das Body-Field indem sich der gesamte Content befindet ist immer optisch genau gleich wie vorher.
Also so wie es sein soll ;-)

Sieht also grundsätzlich mal Tip Top aus.

Ackere mich jetzt mal durch die DTD und XML-Sache durch und werde hoffentlich mit der Kleinigkeit schneller als in 5 Tagen fertig sein :-)

Auf jeden Fall ein dickes DANKE für den DXL - Tip.

UND
werd ich Zukunft hier mit ordentlicher Schrift posten. Hab festgestellt das dies bevorzugt wird.
Sorry ;-)