Domino 9 und frühere Versionen > ND8: Entwicklung

Action Button vor User verstecken, der nicht in Profildokument konfiguriert ist

<< < (3/3)

Tode:
Ja, bernhard, da verfolgen wir wohl zwei unterschiedliche Ansätze:
Ich fange gerne jeden möglichen (und unmöglichen) Fehler schon im Code ab, Auf die Gefahr hin, "schlechte Daten" zu tolerieren,
Du gehst davon aus, dass Daten immer so aussehen, wie sie aussehen müssen, und dass jeder
A) das weiss, was da drin stehen soll und
B) sich dran hält

Ich kenne leider zu viele (Kunden, Admins, Entwickler, bitte adäquates einfüllen), die das eben nicht machen, und sich mal eben ne Schaltfläche, nen Agenten, etc. Bauen um ein Feld zu korrigieren, oder ähnliches. Da ist es schnell passiert (ist session.Username abbreviated oder kanonisch?, ich meinte zweiteres, kann mich aber auch irren, und wenn ich einen namen aus einem bearbeitbaren Feld per strg +c kopiere ist in der zwischenablage auch der abbreviated name)

Ich verstehe und respektiere Deinen Ansatz, aber ich bin -was solche Dinge angeht- ein wenig paranoid... ;-)

Peter Klett:
1:0 für Tode - grundsätzlich. Allerdings muss man auch den Kontext betrachten.

Hier ist es so, dass nur diejenigen einen Button zur Genehmigung eines Dokumentes angezeigt bekommen, die in einem Profildokument genannt sind. Ist die Abfrage nicht tolerant bzgl. falscher Namensformate, entsteht kein Schaden in der Anwendung. Trägt jemand mittels schlechtem Agenten ein falsches Namensformat in das Profildokument ein, ist der Button eben nicht sichtbar. Da kann ich Bernhards Herangehensweise gutheißen.

Im umgekehrten Fall, wenn z.B. eine Namensliste eine Blacklist darstellt, also alle die, die in der Liste stehen, dürfen den Button nicht sehen, sehe ich Todes Toleranzverständnis als absolute Pflicht.

Ein weiterer Aspekt ist die Frage nach dem "Dummen", der die Intoleranz ausbügeln muss. Liefere ich eine Datenbank und darf dann im Supportfall danach suchen, wo die, die "nichts verändert haben", herumgefummelt haben, und kann das womöglich noch nicht einmal dem Kunden gegenüber abrechnen, sollte ich mir solche Fallstricke nicht einbauen.

Daher: Tode, ich sehe das genauso, wie Du!

Tode:
Sollte jetzt keine Grundsatzdiskussion werden, zumal ich Bernhard sehr schätze... Und EIGENTLICH sollten ja immer in allen Feldern saubere Werte drin stehen, so wie man das bei der Entwicklung der Anwendung mal gedacht hat, aber dieses Eigentlich hat mir schon so häufig -wie Peter schreibt unbezahlte- Stunden der Fehlersuche beschwert, dass ich da einfach (über)vorsichtig geworden bin und teilweise noch eine Abfrage einbaue in Fällen, wo es gar nicht sein KANN, dass da was falsches steht. Wie gesagt bin ich da etwas paranoid.

Aber wir sollten diese Diskussion -die sehr interessant und anregend ist- eventuell in einem Off- Topic- Thread weiterführen, denn dem Ersteller wurde ja geholfen, und hiermit hat das ja nix mehr zu tun...

mpausch:
der "Ersteller" freut sich trotzdem über diese Off-Topic-Diskussion, da er in puncto Domino-Entwicklung noch ziemlicher Anfänger ist und deshalb jede Anregung und jeden Tipp gerne aufsaugt :-)

koehlerbv:
Peter hat schon Recht - die Sache ist im Kontext zu betrachten. Sein Beispiel war da auch exzellent.

Prinzipiell gilt aber: Wer keine saubere Daten in eine Datenbank kippt, kann auch kein sauberes Ergebnis erwarten. Und wildgewordene "Programmierer", die sich mal fix einen datenmanipulierenden Agent schreiben, können ja auch Strings in Zahlenfelder schreiben (und sich dann wundern, dass die Ansicht nicht mehr richtig summiert) oder fett, rot, 16 pt. "Erst morgen!" in ein Datums-Item.
Abbreviated oder gar flache Namen kommen in Autoren- und Leserfeldern auch nicht immer gut ...

Bernhard

Navigation

[0] Themen-Index

[*] Vorherige Sete