Nutzt Ihr DXL bei der N/DEntwicklung?

[TMC]

Immer schwierig, alle möglichen Antworten zu erfassen bei einer Umfrage.
Eure Meinungen würden mich interessieren.

[Manfred Dillmann]

Hallo Matthias,

ich kann da nicht abstimmen, weil keine der Optionen so richtig passt. Ich habe das zwar mal testweise ausprobiert - das wars aber auch. Mir fehlt das im Kontext der Entwicklung der richtige Nutzen...

Wolfgang Flamme hatte zwar mal in seinem Blog geschrieben, dass er für einen Kunden x Ansichten in einer NSF ändern musste. Er hat die Ansichten als DXL exportiert, dann die entsprechenden Items geändert (weiss nicht mehr wie...) und in die NSF reimportiert.

Sowas könnte ja ein Ansatz sein. Aber sonst?

Für mich würde das Sinn machen, wenn es eine externe Entwickler-IDE geben würde (Eclipse?), die den Domino-Designer komplett emuliert, man so elegant programmieren kann und das XML-Zeugs dann später in die NSF zurückgeschoben wird. 

Vielleicht bin ich aber nur "betriebsblind"?

P.S.
Du hast doch Java Head Start gelesen? Kannst du das empfehlen?

Gruß
Manfred

[Semeaphoros]

Manfred, vielleicht wird das dann mit dem Workspace-Designer ein Thema. Ich hab Usability-Tests machen dürfen an der Lotusphere, und das Teil sieht wirklich schön aus.

[Marinero Atlántico]

Manfred, vielleicht wird das dann mit dem Workspace-Designer ein Thema. Ich hab Usability-Tests machen dürfen an der Lotusphere, und das Teil sieht wirklich schön aus.

Wieviel CPUs hatte der Rechner? (typische Heini Schwammerl Frage, aber der ist gerade nicht da)

[Manfred Dillmann]

Hi Jens,

da Du direkt an der Quelle warst, hast Du natürlich einen anderen Blick für das, was da kommt. Ich lasse mich überraschen.

P.S.
Wie ich gehört habe, war Dein Vortrag auf der LS ein voller Erfolg. Herzlichen Glückwunsch!

Gibt es für die "Daheimgebliebenen" ggf. ein PDF - ich möchte ja nicht dumm sterben... 

Gruß
Manfred

[Semeaphoros]

Hey, wo hast Du denn das gehört? Ich selbst habs auch als Erfolg erlebt, danke für die Meldung. Mein Material gibts in 2 bis 3 Tagen auf meiner allmählich wieder auferstehenden Web-Site, ich melde es dann. Möglich, dass ich in den Best Practices einen Auszug davon erstelle - wie das jemand in einem anderen Thread vorgeschlagen hat.

Axel: Ich hab keine Ahnung, was das für eine Maschine war (von der konfig her), war aber auch kein Thema, wir mussten ein paar Sachen machen und wurden über unsere Eindrücke interviewt. Ausserdem wars eine Alpha-Version vom Workplace-Designer. Das Teil macht wirklich einen ganz guten Eindruck und ich bin auch sicher, dass die Hardwareanforderungen, die der Workplace bis jetzt noch stellt, bald einmal sich reduzieren werden. Anspruchsvoll wird er immer sein, schliesslich kann man das Teil quasi auch als Erweiterung des heutigen Notes-Client sehen......

[Manfred Dillmann]

>> Hey, wo hast Du denn das gehört?<<

Hmm, gute Frage. Hatte da nicht jemand was im Daumen-drückt-Thread hier geschrieben? Egal. War doch klar, dass Du das locker meisterst... 

Manfred

[TMC]

Mir fehlt das im Kontext der Entwicklung der richtige Nutzen...

Auslöser für diese Umfrage war für mich u.a. der folgende Thread:
http://www.atnotes.de/index.php?topic=20963.0

Spontan fällt mir folgendes ein:

• Anpassen und Verteilen von Designelementen. Siehe auch z.B. hier: http://www.benpoole.com/80256B44004A7C14/articles/simpledxl (diese DB funktioniert bei mir aber nicht, ich bekomme eine nichtssagende Fehlermeldung, muss da mal ein besseres ErrorHandling einbauen, um der Ursache auf die Spur zu kommen)
• Auslesen/Schreiben von Dokument-Inhalten, an die man so nicht drankommt (z.B. eingebettete Bilder - oder z.B. eine verbesserte Funktion für "IsRichtextEmpty") Oder etwa Spielereien, wie z.B. Attachment-Symbole austauschen.

Sicherlich gibt es da noch mehr. Daher auch mein Post hier. Mich würde auch interessieren, in wie weit die AtNotes-Besucher DXL noch nutzen.
Ich könnte mir auch vorstellen, eine DB mit DXL komplett zu bereinigen (also eine Kopie über DXL zu erstellen, und dabei alles unnötige rauswerfen ($UpdatedBy, Agent Logs, etc. etc.).
Oder z.B. bei "kaputten" Dokumente versuchen, diese per DXL zu retten (wenn andere Versuche fehlschlagen).

Du hast doch Java Head Start gelesen? Kannst du das empfehlen?

Das Buch heißt genau "Head First Java" (http://www.oreilly.com/catalog/hfjava/), und ich kann es sehr empfehlen - obwohl ich es noch immer nicht ganz durchhabe. Für den Einsteiger IMHO ideal. Beim o.g. O'Reilly - Link gibt's auch ein Probekapitel als PDF.


Matthias

[Manfred Dillmann]

Matthias,

OK, das sind ein paar Ansatzpunkte. Im Tenor aber immer dann benutzt, wenn man was spezielles "Zaubern" will, was sonst so nicht geht. Das ist auch OK.

Ich verwende ja auch in meinem RSS Reader den DomParser, um das angelieferte XML in Notes-Dokumente zu wandeln.

Grundsätzlich auch ein interessantes Thema - keine Frage. Ich wollte ja nur mal kund tun, warum ich bei den Antworten nicht abstimmen kann... 

Danke auch für die Infos zum Buch...

Manfred

[Marinero Atlántico]

DXL ein bischen weiter gefasst xml:
- gut für Austausch von Daten zwischen unterschiedlichen Programmen (egal welche Art von Programm oder ob in gleichen Netzwerk). Z.B. könnten per dxl Notes-Dokumente zwischen Geschäftspartnern hin und hergeschickt werden, ohne dass beide in einem gemeinsamen Netzwerk sind (nur per Internet verbunden). Ist natürlich eine security Frage, wenn man das wirklich macht. PKI Zeugs, non repudiation, encryption und dies alles lässt sich aber über Java mittlerweile ganz gut organisieren. Da unterstützen auch die extrem xml-lastigen Webservices mit den total vielen Zusatzspezifikationen für security, transactions usw.  
 
Oder Austausch zwischen Java/.NET und Domino (wir nutzen das z.B. für unify/store.one.

rss auslesen fällt auch unter diese Kategorie.

- gut für jede Arten von "Beschreibungsdaten":
Metadaten für Archivsuche, Konfigurationsdateien, etc.
Es kann ziemlich nerven, ist aber praktisch.

[heini_schwammerl]

Wieviel CPUs hatte der Rechner? (typische Heini Schwammerl Frage, aber der ist gerade nicht da)

Nein, ich gelobe Besserung und werde mich zukünftig nicht mehr über IBM Workplace beschweren.

[animate]

ich entwickle nix mehr mit N/D, aber bei meiner alten Firma haben wir den DXL-Export dazu benutzt, um aus unserem Produkt (Anforderungsmanagementdatenbank) die Inhalte zu exportieren und dann per XSLT in vom Benutzer gewünschte Zielformate (HTML, Word, pdf) zu transformieren.
Das ist für mich persönlich DAS Einsatzgebiet für DXL, weil Notes sonst mit gescheiten Möglichkeiten zum (formatierten) programmatischen Export  geizt.
Die Möglichkeiten, die sich mir damals damit auf diesem Gebiet boten waren (und sind) für einen Notesentwickler traumhaft.

[Marinero Atlántico]

ich entwickle nix mehr mit N/D,

Was machst du?

[animate]

ich entwickle nix mehr mit N/D,

Was machst du?

Immer noch Analyse, Design und Programmierung. Aber halt nicht mehr Notes, sondern hauptsächlich Java (mit Framework, das auf Struts und OJB aufbaut).
Ich brauchte mal etwas Abstand zur Notes-Entwicklung

[-Michael-]

Hi,

ich habe in der Yet another Doc Library DXL verwendet, um eingebettete Bilder des aktuellen Dokumentes zu extrahieren.
Als Parser verwende ich allerdings weder DOM noch SAX, sondern einen eigens geschriebenen LotusScript-Parser (Schande über mich).
In diesem Zuge musste ich allerdings feststellen, dass man einiges an Code optimieren kann.
Z.B. die in ND6 eingebaute Replace-Funktion war um ca. 30-100 mal schneller als die typischen ReplaceSubstring - Methoden oder etwa ein @ReplaceSubstring - Evaluate.

Zu der von TMC erwähnten Funktion "Is Richtext Empty": klar, das kann man über DXL machen. Aber Achtung: Das kann schnell mal sehr langsam werden. Mit einem 5-Zeiler ist das nicht getan. Z.B. ein Instr(strDXLOutput, "<picture>") kann sehr langsam sein, wenn die Quelldatei groß ist. Hier muss man sich also Algorithmen überlegen, die das wirklich schnell machen. Da wäre wohl SAX die erste Wahl.
Bei der Umsetzung in meiner "Yet another Doc Library" ist eigentlich alles relativ schnell, bis auf die Base64-Dekodierung, die ich noch in LotusScript mache. Das ist aktuell sehr langsam.

Michael