Domino 9 und frühere Versionen > ND8: Entwicklung

Sichere Alternative für ComputeWithForm

(1/4) > >>

basile:
Liebe Mitforisten,

ich suche nach einer "sicheren" Alternative für ComputeWithForm. Die Aufgabenstellung ist in etwa folgendermaßen:
Ich habe Dokumente für (elektrische) Bauteile und möchte daraus "Geräte" bauen. Dabei soll können natürlich mehrere von einem Bauteil mehrere in einem Gerät vorhanden ein (1:n-Beziehung). Die Beziehung soll auf beiden Seiten (Bauteil und Gerät) transparent sein (über embedded view). Wenn sich z.B. der Name des Bauteils ändert, möchte ich das in dem Geräte-Dokument sehen (Update). -> eigentlich ein klassisches rel. Datenbank-Problem. Ich nutze aber Lotus.
Derzeit habe ich das mit "Linkdokumenten" gelöst. Solch ein Dokument wird für jede Beziehung eines Gerätes zu einem Bauteil angelegt (1:1-Relation).In so einem Linkdokument ist die UNID des Bauteils und des Gerätes drin, der Name von den beiden und die verbaute Anzahl.
Im Linkdokument kann ich den Namen des Bauteil über eine Ansicht abfragen (Feldformel), damit ist der immer aktuell.
Diese Aktualisierung eines Linkdokuments kann ich aber nicht aus einem anderen Dokument (Gerätedokument) anstossen. Zwar kann ich aus dem Gerätedokument einfache Feldupdates (z.B. Feldwert + 1) anstossen (ComputeWithForm), das Ergebnis wird dauch ganz toll geändert/gespeichert. Aber komplexe Aktionen wie z.B. einen Feldwert über einen View besorgen/ins Feld schreiben/Linkdokument speichern geht aber nicht. Die Speichermethode nach ComputeWithForm wartet nicht auf das vollständige Durchlaufen aller Scripte in allen Feldern??!!!!!
Meine Lösung sieht so aus, dass ich aus dem Gerätedokument(Bauteildokument) alle damit verknüpften Verknüfungsdokumente abklappere und den Update sozusagen "von Ferne" und "per Hand" mache. Das geht, widerspricht aber ganz kolossal meiner Auffassung von Objektorientierung.

Habt Ihr vielleicht eine gängige Lösung/Trick für dieses Problem in Eurer Schatzkiste?

In froher Erwartung

Udo

basile:
nochwas dazu....
natürlich kann ich eine update-Methode in QuerySave des LinkDokumentes schreibehn und aus dem GeräteDokument alle Linkdokumente im Client (editierbar) öffnen/speichern/schließen, das ist zwar einigermaßen Objektorientiert, sieht aber bei 1000 Verknüpfungen auch irgendwie komisch aus, wenn die Tableiste über 10 sek flackert  ;)

In froher Erwartung

Udo

jo@chim:
Warum lagerst Du die Routine nicht auf einen Backgroundagenten aus? (RunOnServer)

Peter Klett:
Bei 1000 mal Dokument öffnen, speichern und schließen raucht Dir der Client ab, denn es wird nicht sequentiell abgearbeitet. Irgendwann ist dann der Speicher voll und der NotesClient dahin.

Ich würde die ganzen Berechnungen in eine Script-Bibliothek bauen, die unabhängig vom geöffneten Dokument funktionieren. Diese Routine kannst Du dann beim Speichern aufrufen oder aber auch bei einer Änderung "von außen". Dabei hast Du dann nur einen Code, der gewartet werden muss.

thkn777:
Da die Link-Dokumente die Teile-Bezeichnung statisch halten (sonst können diese nicht in Ansichten angezeigt werden), sollte ein Update eines Teile-Dokumentes den Update der Link-Dokumente nach sich ziehen. Ob vom Client direkt nach der Änderung, über eine Client-Aktion oder über einen zyklisch laufenden Wartungsagenten... das kommt darauf an.

Das Gerätedokument zeigt die Info's ja nur an... hat damit also (eigentlich) gar nichts zu tun.

Da ich aus Deinen Postings herausgelesen habe, daß Dir dieser Ansatz nicht gefällt, wie wäre es mit:


Alternative:
Teileliste dynamisch generieren - z.B. per Script in ein RichTextFeld schreiben. Also etwas zusätzlich zur embedded View. Das RTF kann man sinnvoll formatieren und hat ggf. sogar ein Dokument, das man als "Version x" ablegen kann. Und - es ist (analog zu SQL - "live"). Ich hatte bisher noch nie Probleme, wenn ein Nutzer ein paar Sekunden auf 20+ Seiten A4 warten mußte (Du sprachst von Teilelisten mit 1000+ Elementen).


Alternative2:
Analog, aber Export nach Word/Excel für eine bessere Darstellung / für den Druck / für Reports.


Für kleinere Datenmengen gab's da mal den TableWalker... aber da Du ja schon Linkdokumente nimmst, schau Dir mal meine beiden Alternativen an. Für die tägliche Arbeit (Teile zu Geräten hinzufügen etc. ist so eine RTF-Liste natürlich nicht gut geeignet.

Viel Erfolg,
Th.

Navigation

[0] Themen-Index

[#] Nächste Seite