Die widerspenstigen Profildokumente von Lotus Notes
10. März 2006 von Wolfgang SommergutZurzeit beschäftige ich mit einem kleineren Projekt auf Basis von Notes (deshalb die geringere Update-Frequenz auf meinen Blog). Nachdem ich den Domino Designer schon länger nicht mehr angefasst hatte, musste ich mich an das eigenwillige Programmiermodell von Notes erst wieder gewöhnen. Da ich eine reine Web-Anwendung erstelle, gehe ich dem üblichen Verhau aus Masken, Feldern und Formeln aus dem Weg und beschränke mich auf Lotusscript-Agents, die mit der Datenbank kommunizieren und den gesamten Ouput erzeugen. Gestern zogen mich Experimente mit Profildokumenten allerdings in die Strudel schlimmster Notes-Murxerei. Hier eine kurze Zusammenfassung, die vielleicht hilft, wenn jemand ein ähnliches Problem lösen soll (und die Dokumentation dabei nicht viel hilft).
Profildokumente sind eigentlich eine feine Sache, sie dienen dazu, Konfigurationsdaten zu speichern. Der Domino-Server lädt sie immer in den Arbeitsspeicher, damit dort abgelegte Einstellungen schnell ausgelesen werden können. In der klassischen Notes-Entwicklung erzeugt man eine Maske, mit der die Benutzer solche Konfigurationsdaten editieren können. Für das Web klappt das aber so nicht, weil Befehle wie EditProfileDocument
dort nicht verwendet werden können. Ein Beitrag auf IBMs developerWorks findet klare Worte: Using profile documents in applications served on the Web presents a challenge
. Er schlägt folgendes Verfahren vor:
- Eine Maske anlegen, die nur als Interface für den Nutzer dient und selbst praktisch nichts tut;
- In das Ereignis „Öffnen des Dokuments im Browser“ (WebQueryOpen) einen Lotisscript-Agent einhängen, der eventuell schon vorhandene Profile ausliest (mit der
GetProfileDocument
-Methode der NotesDatabase-Klasse) und sie als Vorgabewerte in die Maske schreibt; - Eine Schaltfläche für die Speicherfunktion in die Maske integrieren, die zwar den Speichervorgang auslöst (und damit das Ereignis
WebQuerySave
, aber nichts auf die Platte schreibt). Deshalb möge man ein verstecktes Feld mit dem NamenSaveOptions
in die Maske einfügen und mit dem Wert 0 versehen. Die eigentliche Arbeit verrichtet dann der Lotusscript-Agent, der durch das Speichern-Event aktiviert wird.
Für mich klingt das nach einem ziemlichen Hack, ist aber die offiziell empfohlene Methode. Ich habe mich daran orientiert, bin aber damit nicht weit gekommen. Meine Maske enthielt nämlich eine Drop-Down-Liste („Dialogliste“). Der Agent für das WebQueryOpen-Ereignis sollte die Werte dynamisch in die Liste einfügen. Wie ich bald herausfand, geht das nicht. Auch dafür gibt es eine Murx-Variante von IBM. Man muss ein verstecktes Helferfeld anlegen und die Einträge dort als Textliste hineinschreiben. Eine Formel hinter der Dialogliste übernimmt die Werte aus dem Helferfeld. Das klappte denn auch. Aber wenn der Benutzer auf die Schaltfläche „Speichern“ klickt, sollte der Agent herausfinden, welcher Wert in der Dialogliste ausgewählt wurde. Das geht mit Lotusscript offenbar nicht, zumindest fand ich nirgendwo einen Hinweis darauf.
Meine Alternative bestand darin, auf die Notes-Maske gänzlich zu verzichten und per Lotusscript-Agent ein HTML-Formular zu erzeugen. Ein zweiter Agent wertete dieses aus und schrieb die Werte in die Profildokumente. Das funktionierte im Prinzip zwar, führte aber immer wieder zu mysteriösen Effekten. Beim mehrmaligen Nachladen eines unveränderten Profils im Browser erschienen ständig andere Werte, einmal ganz alte, dann wieder die zuletzt gespeicherten. Damit war für mich das Thema Profildokumente erledigt und ein halber Arbeitstag beim Teufel. Das Suchen nach einer Lösung wurde mir von einem Debugger versüsst, der auch dann anspringt, wenn man durch die Hilfedatenbank blättert. Oder die Undo-Funktion, die den Programmcode regelrecht zerhackt. Aber zum Glück empfiehlt ein anderer Beitrag auf developerWorks, auf Profildokumente ganz zu verzichten und entwickelt stattdessen ein anderes Verfahren, um Einstellungen zu speichern. Leider habe ich den zu spät gefunden.
Kategorie: Messaging und Collaboration Ein Kommentar »
Ich hab mir fuer Profildokumente folgendes angewoehnt und das klappt auch gut:
– Normale Maske anlegen
– Normal editieren
– Normal speichern
– im PostSave (Notes) bzw. webquerySave alle Items via script ins Profildokument umspeichern. Da hat man die Daten zwar doppelt, kann aber mehrere normale Dokumente mit verschiedenen Inhalten vorhalten und dann die Konfiguration „umschalten“.
Hth
:-) stw