Domino 9 und frühere Versionen > ND6: Entwicklung

Anfängerfragen - Ansicht anpassen und Feld in 2 Dokumenten

<< < (2/4) > >>

Peter Klett:
Die Lösung für 1. kannte ich auch noch nicht, ist ja wirklich einfach.

Nochmal zu 2.: Du hast also ein Admin-Dokument, in dem Du für jedes Land die Marke eintragen kannst. Dann hast Du für jedes Land ein eigenes Dokument, in das Du jetzt auch die Marke eintragen willst?

Am einfachsten ist dann ein periodisch laufender Agent, der die Werte aus den Länderdokumenten mit dem Admindokument abgleicht. Wie schon gesagt, eine automatische Synchronisation mit Haken setzen, synchronisiere Feld A mit Feld B, gibt es nicht (oder besser, ist mir nicht bekannt).

Mich90:
Zu Lösung 2 : Hmm, das Feld muss nicht unbedingt im Admin-Dokument bleiben, es würde auch genügen, das Feld (allerdings inklusive der schon bestehenden Inhalte zu jedem Land) in die andere Maske zu migrieren? Wäre so etwas denn möglich? Ansonsten muss ich eben damit leben  ;D

Peter Klett:
Du musst schon wissen, was Du willst, dann geht ziemlich alles.

Erst schreibst Du, dass das Feld nicht aus dem Admindokument entfernt werden soll, weil Dokumente und Ansichten (Ansichten halte ich allerdings für ein Gerücht) sich die Informationen daraus holen.

Jetzt schreibst Du, dass es da nicht drin bleiben muss? Und die willst das Feld in eine andere Maske migrieren?

Falls Du soetwas suchst, wie: "Ich ziehe das Feld aus der Maske A in die Maske B, dadurch gibt das Dokument mit der Maske A die Inhalte logisch verteilt an Dokumente der Maske B ab und alle Funktionalitäten in der Datenbank (und vermutlich noch anderen Datenbanken, die darauf zugreifen) passen sich dem vollautomatisch an", dann musst Du in eine Verkaufsveranstaltung gehen, wo einem sowas schön bunt in PowerPoint präsentiert wird. Und sicherlich findest Du dort auch Leute, die das glauben (die nennt man "Entscheider"). Mit der Realität hat das allerdings nichts zu tun.  ;)

Also im Ernst:

Wenn Du Ländereinstellungen hast, die zu Länderdokumenten gehören, dann bau die da ein, denn da gehören die auch hin. Wenn Du die Informationen schon in einem Admindokument hast, baue Dir eine Routine, die die Daten verteilt. Alternativ gibt es dafür die Drucker-Tastatur-Praktikanten-Lösung. Funktionalität, die auf das Admindokument schaut, musst Du umbauen. Zum Testen empfiehlt es sich absolut, die Felder (genau Items) aus dem Admindokument zu löschen (@Deletefield, oder NotesDocument.RemoveItem), denn durch das Löschen eines Feldes in einer Maske ändert sich kein einziges Item eines bestehenden Dokuments.

Wenn Du das alles nicht willst, kannst Du mit einer Notlösung, wie von mir vorher beschrieben - also die redundante Datenhaltung in Länder- und Admindokument incl. automatisiertem Datenabgleich - arbeiten.

Also: Erst musst Du wissen, was Du willst, dann kannst Du überlegen, wie es gehen soll, und dann kannst Du das bauen. Anders wird das nix.

Mich90:

--- Zitat ---Und sicherlich findest Du dort auch Leute, die das glauben (die nennt man "Entscheider").
--- Ende Zitat ---
Ja und genau so einen habe ich á la: Es ist doch schon alles da, du musst das doch "nur mal eben" woanders hinschieben. Ich bin Azubi und dies ist keine Entwickler- sondern eine Anwenderabteilung in der ich gerade eingesetzt bin, also ist auch kein "Techniker" außer mir da, der mir da Unterstützung geben kann.

Na gut .. back to the topic:
Das, was jetzt in dem Admin-Dokument funktioniert, soll auf das Anwenderdokument übertragen werden. Nicht mehr, aber auch nicht weniger.
Eigentlich ist es egal, wie das gemacht wird, es sollte eben eine schöne und vor allem funktionierende Lösung sein. Da der Admin sowieso Zugriff auf alle Dokumente hat, müssen die Felder nicht im Admin-Dokument bleiben.
Ich war am Anfang der Ansicht, es wäre einfacher, die bisherige Funktionalität so zu belassen und beim Anwender ein neues Feld hinzuzufügen (eben Felder zu verknüpfen - geht nicht). Das scheint aber so einfach, wie ich mir das vorgestellt habe, ja nicht zu funktionieren.

Peter Klett:
So in etwa hatte ich mir das schon gedacht ...

Dann solltest Du zuerst analysieren, welche Masken, Events (evtl. sogar weitere Datenbanken) usw. auf die Admindokumente zugreifen und diese Informationen verwenden. Das ist eine sehr schwierige Aufgabe, die Du so vermutlich nicht lösen kannst. Hast Du alle Stellen lokalisiert, kannst Du überlegen, ob ein Umbau wirtschaftlich ist. Wenn Du Azubi in einer Anwenderabteilung bist, stellt sich mir natürlich die Frage, wer das gebaut hat (Entwickler innerhalb / außerhalb der Firma / zugekaufte Software) und wer für den Betrieb der Datenbank verantwortlich ist. Mit denen solltest Du das unbedingt abstimmen.

U.U. operierst Du mit den Einstellungen direkt am offenen Herzen, das ist aus der Ferne aber nicht sicher zu beurteilen.

Wenn Du sicher gehen willst, dass die Anwendung nachher noch funktioniert, lässt Du grundsätzlich alles so, wie es ist. Die Einstellungen bleiben im Admin-Dokument, werden dort aber nicht mehr angezeigt oder nur noch zum Lesen, also nicht bearbeitbar. In die Länderdokumente nimmst Du im ersten Schritt die Einstellungen auf. Dann musst Du die Daten aus dem Admindokument in die Länderdokumente verteilen (vermutlich per Hand). Zuletzt baust Du eine Routine, die die Daten aus den Länderdokumenten in das Admindokument übernimmt. Dann hast Du die Steuerung des Systems unverändert über die Admindokumente, die Bearbeitung dieser Steuerung aber in den Länderdokumenten. Das ist nicht die ideale Lösung, die man bei einem Redesign erreichen würde, erscheint mir aber wesentlich wirtschaftlicher und sicherer.

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete