Domino 9 und frühere Versionen > Entwicklung

Leserfeld mittels LS füllen

<< < (2/3) > >>

TMC:
Meines Erachtens müsste beim Frontend-Speichern (z.B. @Command) ein Error kommen, wenn man zuvor in ein Nummernfeld per Backend ein Textstring gesetzt hast, weil dann beim speichern übers Frontend bzw. Refresh die Validierung zuschlägt.

Semeaphoros:
Wieso Nummernfeld?

TMC:
War nur ein Beispiel: Wenn Du ein Nummernfeld hast, und dort einen Text reintippst und das Notes-Dokument speicherst per @Command, dann meckert Notes und lässt Dich nicht speichern, weil die Validierung zuschlägt.

koehlerbv:
Klar ist, dass sich Operationen im Front- und im Backend immer gegenseitig beeinflussen können.
Was die Eigenschaften IsReaders oder IsAuthors angeht, wünschte ich mir, ich hätte mehr Zeit, hier die gegenseitige Beeinflussung von Front- und Backend mal näher untersuchen zu können. Die fehlt mir aber leider, und ich sage mir hier: Es gibt wichtigeres ...
Ich finde Semeaphoros' Ratschlag, die Property explizit zu setzen, extrem wichtig - ich mache dies immer und ohne ausnahme so, dass Backend-Items unter allen Umständen diese Properties übergebügelt bekommen. Dazu sind diese Properties für die Sicherheit einfach zu wichtig.
Vor Jahren (war R5.0.3 ?) habe ich u.a. Agents für Gedys-Applikationen geschrieben, die dort diese Properties wieder gerade gezogen haben, nachdem diese durch den Code des Herstellers verloren gehen konnten. Wie gesagt: Ich hätte dies gerne untersucht, aber die Lösung des Problems an sich war mir wichtiger. Ich ahnte (! Mehr nicht !) damals, dass ein Formel-Agent, der Inhalte entsprechender Felder änderte, während betroffene Dokumente im FrontEnd noch offen waren, dafür verantwortlich war.

Wichtig ist m.E. auch, dass man gerade bei Readers- oder Authors-Items alles dafür tut, dass diese ihre Properties behalten. Lieber eine Zeile zuviel als zuwenig. Zumal ich in letzter Zeit (wieder mal) feststelle, dass sich das Verhalten von Notes von Unterversion übel ändern kann. Letzte Woche: Zugriff von einem 6.5.3er Client auf einen 5.0.8er Server (fremde Domäne - keine nicht empfohlene Installation) (NotesView.GetAllEntries) - Red Screen of Death. 6.5.1 ging noch, 6.5.4 scheint wieder zu gehen. Dann: Zuweisung einer Currency-Variable im Backend an ein Zahlen-Feld (Darstellungsform Currency): Im Life-Betrieb (innerhalb einer Applikation) freute sich NSD über Arbeit, in einer Testumgebung (diese Funktionalität pur) wurde das Item überhaupt nicht gefüllt. 6.5.1 ging, 6.5.3 war das Problemkind, 6.5.4 geht wieder.
IBM hat da momentan ein Qualitätsproblem, das nicht zu übersehen ist. Wir hatten das in frühen 5.xer Versionen auch schon mal. Momentan nervt es mich aber und hält mich massiv von meiner Arbeit ab.

Bernhard

PS: Sorry, dass es abschliessend off-topic wurde.

TMC:
Danke für die Ausführung Bernhard.
Ich muss zugeben, dass ich da bisher teilweise etwas nachlässig war, aber man lernt ja ständig hinzu  ;)

Generell hab ich mir das gerade angesehen:
Setzt man ein Item im Backend, und speichert im Frontend, so wird lt. meinem Test der Feldtyp (nicht Item!) genommen, der in der Maske definiert ist. Dies bestätigt also meine oben gepostetes.

Nichtsdestotrotz kann ich Euch beiden (Jens und Bernhard) nur zustimmen: besser die Item-Property setzen. Man weiß ja auch nie: vielleicht fällt jem. in 1 Woche ein den Code zu modifizieren und das Backend-NotesDocument nach dem Setzen des ItemValues dann im Backend zu speichern.

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete