Das Notes Forum
Domino 9 und frühere Versionen => ND9: Entwicklung => Thema gestartet von: Frank_B am 10.06.16 - 09:18:21
-
Ich muss für eine "Registratur" Anwendung eine Maske mit sehr vielen Erfassungsfeldern (items) entwickeln.
u.a. habe ich viele Positionen welche ein Aufbewahrungsende benötigen.
Gibt es eine generelle Maximalanzahl an items pro Maske ? Oder Empfehlung ?
-
Es gibt kein explizites Limit für die Anzahl Felder in einer Maske, nur ein offizielles Limit von ca. 3.000 verschiedenen Feldern pro Applikation (kann per Datenbank- Eigenschaft auf ca. 22.000 aufgebohrt werden).
Hier (https://www.ibm.com/support/knowledgecenter/SSVRGU_8.5.3/com.ibm.designer.domino.main.doc/H_NOTES_AND_DOMINO_KNOWN_LIMITS.html) die Liste an Limitierungen.
Sind es denn wirklich so viele verschiedene Erfassungs- Felder oder nur "Listen" mit identischen Datensätzen?
Im Fall von Listen würde ich mit Antwortdokumenten / eingebetteten Ansichten arbeiten oder mit "dynamischen Tabellen" (Mehrfachwert- Felder mit Trennzeichen Zeilenumbruch und eben Eingabefeldern und Schaltflächen).
-
Ich komme auf rund 500 items am Ende.
Über hide/when werden die zeilenweise ein/ausgeblendet per "+" bzw. "-" Schaltflächen.
Die Idee mit eingebetteten Ansichten die Antwortdokumente enthalten ist interessant, jedoch passt bei mir nicht ganz.
danke
-
Und diese 500 Felder (oder haben die Items in der Mehrzahl keine Frontendentsprechung?) werden wirklich unter Umständen alle ausgefüllt?
In den vergangenen knapp 25 Jahren, in denen ich hauptsächlich Notes-Anwendungen entworfen habe, ist mir noch kein Fall untergekommen, wo eine derart grosse Feldanzahl in einer Maske der geschickteste Ansatz gewesen und und so umgesetzt worden wäre.
Bernhard
-
Ja, ich würde auch mal grundsätzlich am Konzept zweifeln. Wenn ich eine Maske mit 500 Feldern vor mir hätte, die ich alle ausfüllen muss, dann würde ich dem Entwickler den Vogel zeigen...
-
Die Felder werden ja zeilenweise über "+" oder "-" Schaltflächen aus-/eingeblendet (Hide/When)
Ein Lagerort:
Ein Regal (bis zu 100 pro Lagerort) hat nen inhalt. Dieser Inhalt wird aufgedrösselt in max. 20 Detailinfos. Jedes der 20 erhält ein Aufbewahrungsenddatum.
Diese "Detailinfos" sind glaube ich gute Antwortdokumente in einer eingebetteten Ansicht, oder ?
Aber stattdessen könnt ich wirklich mich mal hinsetzen und mit Antwortdokumenten ein "+" / "-" Scenario entwickeln. :)
-
Was zu beweisen war. Mit genaueren Angaben zu "Detailinfos" werden sich wohl auch diese anderes zuordnen lassen als in EIN Dokument.
Nur mal ein Hinweis / Beispiel: Regal 78 gibt ein Zehntel seines Inhalts an Regal 12 am Lagerort X ab. Was würde man jetzt machen, wenn das alles in einem Dokument steckt (ausser fluchen)?
Oder: Man "entdeckt", dass man ja Lagerinformationen auch scannen könnte ...
Bernhard
-
Nur so nebenbei: Bernhard erwähnt das nichtzufällig... wir haben (allerdings vor vielen Jahren) für einen Kunden eine Bibliotheks- Verwaltung geschrieben. Da gibt es auch "Plätze", und jeder dieser Plätze kann 1-x "Breiteneinheiten" (konfigurierbar) einnehmen. Der Inhalt der Plätze wiederum wird mit EAN- Codes versehen und kann ausgeliehen werden. Beim Ausleihen wird der EAN- Code gescannt, und automatisch in der Anwendung das Dokument auf "ausgeliehen" gesetzt. Wenn der Code ein weiteres Mal gescannt wird, dann ist der Inhalt wieder da, und wird automatisch eingecheckt...
Ich kann Dir versichern: Keine der Masken hat mehr als 10 Eingabefelder....
-
Ihr habt mich überzeugt :)
Jetzt muss ich nur noch nen Weg finden die Summen an laufenden Meter aus den einzelnen "Regal"-Dokumenten in meinem dazugehöriges Standort-Dokument (welches die eingebettete Ansicht hat) syncron zu halten.
klar, über ne Collection kann ich das berechnen/einsammeln. Jedoch wird das immer eine unsicherheit bleiben, wenn bspw. ein "Regal"-Dokument gerade bearbeitet wird und das Standort-Dokument sich gerade in Bearbeitung befindet.
...das kriege ich denk ich hin... :)
-
Ja, die größte Herausforderung in diesem Konstrukt ist die Konsistenz... Mit einem einfachen ComputedForDisplay- Feld und einem @DBLookup lässt sich aber zumindest eine "Scheinkonsistenz" wunderbar aufrecht erhalten. Dann beim speichern die Werte korrigieren, und natürlich auch beim Speichern der Regal- Dokumente das Standort- Dokument (wenn gerade nicht gesperrt) aktuell halten, und gut ist...