Autor Thema: DXL, die wahren Pain-Points  (Gelesen 2599 mal)

Offline flaite

  • Gold Platin u.s.w. member:)
  • *****
  • Beiträge: 2.966
    • mein del.icio.us
DXL, die wahren Pain-Points
« am: 28.05.08 - 18:41:51 »
Hi,

aus meinen "reale Welt"-Erfahrungen ist eigentlich mit Release 8 die "nicht voll roundtrip"-Fähigkeit nur noch marginal problematisch. Man kann z.B. in sehr komplexen RichText Feldern mit einer Menge an geschachtelten Tabellen Text ersetzen. Mit dem Mikroskop sieht man ein paar Mini-Punkte, in denen es nach einem DXL-Export - XML-Manipulation - DXL-Import ein bischen anders aussieht. In einem Projekt scheint es aber für den Kunden akzeptabel zu sein.

Die wahren Pain Points haben sich in einem anderen Projekt gezeigt, in dem ich Database Skripte manipuliere.
Es kann Sinn machen den Code von Database Skripten in einem programmatischen Workflow Prozess zu ändern. Etwa wenn Datenbanken auf einem anderen Server gezogen werden.
Es gibt in DXL keine Möglichkeit die Design-Note zu signieren. Auch db.sign funktioniert leider nicht richtig. Nicht so schlimm weil der Kunde aus der Lösung, die ich ablöse, daran gewöhnt ist.
Einige Issues sind in R8 gegenüber R65 behoben. Daran sieht man, dass Lotus weiter an dem DXL Thema gearbeitet hat. Z.B. werden in R65 die Database Skripte nicht kompiliert! In R8 läuft das. Das bei der Entwicklung sehr zu empfehlende NotesDxlImporter.Log-Property funktioniert unter R8. Unter R65 nicht.
Ein massives Ärgernis stellen einige Besonderheiten des DXLImports von Database Scripts dar. So muss man NEUE functions oder Subroutinen in die declaration-Sektion schreiben. Zwischen diesen Subroutinen oder Funktionen in der Declaration Sektion müssen mindestens 2 Chr$(10) stehen. Die Reihenfolge ist offenbar egal. Man kann die in die declarations-Sektion eingehängten Subroutinen oder Funktionen in eigene Text-Nodes hängen. Aber 2 Leerzeichen sollten schon dazwischen sein. Das ist so alles nicht dokumentiert. Vielleicht ist es noch keinem aufgefallen.

Antiquiert sind auch die von Lotus Script verwendeten XML-Apis. Besonders die DOM-Api macht in Vergleich zu Alternativen auf der Java-Seite wie JDOm oder XOM Dinge unnötig kompliziert. Z.B. werden Child-Nodes immer hinten angehängt. In JDom kann ich einfach sagen: Häng diese Node als 4. Child an die Parent-Node x. Wenn man mit DOM z.B. ein Node als erstes Child einer Parent-Node hängen will, dann muss man erst alle existierenden Nodes abhängen, die neue Node anhängen und dann später die alten Nodes in der vorher gültigen Reihenfolge anhängen. Oder Navigation erfordert wesentlich weniger Code, wenn XPath in die Api eingebaut ist (wie bei JDom oder XOm).

Ich hoffe, ich habe mich einigermassen verständlich ausgedrückt. Ich würde mich freuen, wenn andere Leute ihre Erfahrungen mit DXL hinzufügen könnten. Ich kann die, da ich auch irgendwie als Angestellter meines Arbeitgebers an dem 8.5 Design Partner Prozess teilnehme und dort bzw. über PMRs (oder wie das heisst) Rückmeldung zum DXL Thema an Lotus geben. Ein paar Sachen sind da einfach vielleicht völlig unnötig verzwurbelt.

Gruß Axel 
Ich stimm nicht mit allen überein, aber mit vielen und sowieso unterhaltsam -> https://www.youtube.com/channel/UCr9qCdqXLm2SU0BIs6d_68Q

---

Aquí no se respeta ni la ley de la selva.
(Hier respektiert man nicht einmal das Gesetz des Dschungels)

Nicanor Parra, San Fabian, Región del Bio Bio, República de Chile

Offline Werner Götz

  • Aktives Mitglied
  • ***
  • Beiträge: 249
  • Geschlecht: Männlich
Re: DXL, die wahren Pain-Points
« Antwort #1 am: 29.05.08 - 07:35:57 »
Vielen Dank für die Info.
-Werner

 

Impressum Atnotes.de  -  Powered by Syslords Solutions  -  Datenschutz