Domino 9 und frühere Versionen > ND6: Entwicklung

Größere Notes-Anwendung planen?

<< < (5/7) > >>

Simon Dotschuweit:
In der cp view hab ich das gefunden:

@Trim(@Trim(@Trim((@If (ViewSecondEntry="";ViewMainEntry;ViewSecondEntry)))+ViewEntryExtension))

Heißt das, dass er erst schaut ob es eine alternative kategorisierung gibt und wenn nicht, dann nimmt
er die main. In jedem Fall aber wird eine Extension dazu geadded, wenn die also nicht leer ist, dann gäbe es quasi für jedes dokument das zwar den gleichen main / second entry aber unterschiedliche extension hat jedes mal eine neue Kategorie.

Jetzt würde mich nur noch der Hintergrund interessieren, warum du es so implementiert hast und nicht z.B. einfach ein Array genommen hast, in der alle ViewEntries drinstehen, dann könnte man doch beliebig viele vers. kategorisierungen mit absteigender prio haben, oder hab ich mich da vertan?

Semeaphoros:
Du fragst mich etwas, was interessant wäre zu beantworten ....  ;D

Was da genau dahinter steckte, weiss ich tatsächlich nicht mehr auswendig. Gegen einen Array hat irgendwas mit der N zu N Verlinkung zu tun gehabt. Wobei natürlich auch die verbessert werden könnte. Ich glaube mal, die Sache wird dann extrem schwierig, wenn wir Dokumente in Ebene 3 haben. Das Problem ist hier, dass wenn ein Mutterdokument - egal ob in Ebene 1 oder Ebene 2 - den Schlüsselwert (Kategorie) verändert, muss das in allen abhängigen Dokumenten nachgezogen werden. Aus der Natur der Ansichten heraus reicht es auch nicht, dass das Dokument in der 3. Ebene nur sein Mutterdokument kennt, es muss auch das Hauptdokument kennen. Irgendwo in der Ecke gibt es dann Probleme - die aber bestimmt nicht unlösbar sind - wenn man mit Arrays/Multivalue arbeiten möchte. Wie gesagt, das ist jetzt nur aus dem hohlen Bauch heraus und könnte auch von einer anderen Ueberlegung herstammen.

Ah, offenbar ist in dieser View die Version drin, die nur den Kurznamen anzeigt, wenn der definiert ist und nicht der Hauptname. War ein Kundenwunsch. Hier die bessere Formel, die versteht man auch leichter:

@Trim(@Trim(@Trim((ViewMainEntry:ViewSecondEntry))+ViewEntryExtension))

koehlerbv:

--- Code: ---@Trim(@Trim(@Trim((ViewMainEntry:ViewSecondEntry))+ViewEntryExtension))
--- Ende Code ---

Ist das nicht ein wenig Overkill .. äh, Overtrim ?  ;D  Neben der Klammerninflation.

Bernhard

Semeaphoros:
Genau den Gedanken hatte ich auch. Das Ding ist uralt und da ist wohl etwas an Leichen drin hängen geblieben von früheren Versuchen. Bevor die ViewEntries in den Dokumenten vorberechnet abgelegt wurden, wurde die Ansicht echt kompliziert berechnet und mit wachsenden Bedürfnissen und Ausnahmen ist die Formel gewachsen wie wild. Da ist dann beim Vereinfachen der "Optimizer" nicht mehr ganz fertig geworden ....... ;)

koehlerbv:
Kenn ich  ;D Nach geraumer Zeit fragt man sich dann beim Studium des eigenen Codes: "Was wollte uns der Programmierer denn damit sagen ?" ...

Bernhard

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete