Formelsprache und dynamische Feldnamen

[florianh78]

Hallo zusammen,

ich knoble hier an einem Problem für das ich einfach keine Lösung finde. Kern des Problems ist, daß ich keinen Weg finde die Formelsprache dazu zu bringen mir einen String als Feldnamen zu interpretieren.

Das Skript sieht folgendermaßen aus:

feldname := "KEYWORDS_" + @Implode( @ReplaceSubstring( @V3UserName; " " : "/" : "-" : "ß"; "_" : "__" : "___" : "ss" ) );
inhalt := feldname;
ausgabe := @If( @Length( inhalt ) = 0; "(keine)"; inhalt );
@Implode( ausgabe; "; " )

Der Riesenausdruck bei feldname erzeugt einfach nur den Feldnamen, der dann z.B. heißt "KEYWORDS_Florian_Holeczek__bla__blubb" (wenn der Username Florian Holeczek/bla/blubb lautet).

Solange ich diesen "String" ohne Anführungszeichen hinter "feldname :=" schreibe funktioniert alles wie es soll (Trivialfall). Das bringt mir jedoch nichts, da der Feldname dynamisch ist.

Ich weiß, daß LotusScript sowas unterstützt, bin jedoch aufgrund der Verwendung in einem Berechneten Text wohl oder übel auf die Formelsprache angewiesen.

Falls also jemand weiß wie man a) die Formelsprache zu der gewünschten Funktionalität überreden kann oder b) mittels LotusScript einen Berechneten Text "simulieren" kann, der möge sich doch bitte äußern!

Vielen Dank + beste Grüße,
 Florian

[Driri]

Hi,

vielleicht habe ich das falsch verstanden, aber wenn ich deine Formel mal ausprobiere, kommt bei mir auch der gewünschte String raus, sprich je nach User enthält "feldname" einen "personalisierten" String.

Allerdings vermute ich mal, daß das nicht alles ist, was Du an Code hast, wo hakt es denn ?

[klaussal]

... sollte es so sein, dass ein feldname dynamisch erzeugt werden soll, je nachdem was in einem string drinne steht. also: inhalt string = "uschi" ergibt ein feld namens uschi ? dann frage ich mich, wie deine maske aussieht mit diesem dynamischem feld  

[ata]

... du könntest dir entweder ein normal berechnetes Feld nehmen und im Initialize des Feldes den Wert in dieses Feld schreiben lassen, oder du machst es per @GetDocField( ... ) => hier wird der Feldname als String übergeben...

ata

PS: Konzeptionell ist das mit den dynamischen Feldnamen aber nicht ganz unkritisch, da Notes-Datenbanken nicht ubegrenzt Felder enthalten können...

ata

[florianh78]

Hallo zusammen,

danke erstmal, mit so einer "Masse" an Antworten hab ich nicht gerechnet. Werde am Donnerstag weiterprobieren und poste eine eventuelle Lösung dann natürlich hier rein.

Nur mal ein paar Zeilen an die bisherigen Tip-Geber:

driri:
Ja Du hast das falsch verstanden, es soll eben nicht der Feldname, sondern der Inhalt eben dieses Feldes erscheinen!

klaussal:
Richtig erkannt! Das ganze ist Teil einer Konstruktion mit folgenden Beteiligten: 1 Schaltfläche "ändern", 1 durch Code hinter der Schaltfläche angelegtes (und deshalb nicht sichtbares) Feld, und 1 Berechneter Text, der den Inhalt des versteckten Feldes enthalten soll. Zweck/Vorteile: a) Benutzer dürfen nur aus einer im Profildokument festgelegten Menge von Keywords auswählen und b) jeder Benutzer sieht nur seinen eigenen Eintrag, kann jedoch mittels der Suche auch auf die Felder der anderen Benutzer zugreifen.

ata:
- Danke einstweilen für den Tip, hab in der Richtung jedoch schon rumgeforscht... erster Teil des Tips hört sich vielversprechend an, ist jedoch in diesem Fall nicht verwendbar, da die Felder ja von einem LotusScript angelegt werden und außerdem immer nur genau eins sichtbar sein soll.
- Mittels @GetDocField() kommt im Berechneten Text eine Fehlermeldung, daß ich dazu in diesem Kontext keine Berechtigung habe. Vielleicht ein Tip parat, wie man das umgehen kann?
- Daß es nicht unkritisch ist weiß ich, aber ich hoffe (!?), daß Notes doch genügend Felder für ein paar Dutzend Benutzer bereitstellen wird. Weißt Du die genaue Grenze?

Grüße,
 Florian

[ata]

... die Grenzen liegen bei Version 4 bei ca. 3000 Feldnamen. Die Namen werden als String mit 64K gehandelt - daher der Erfahrungswert mit ca. 3000 Feldern...

... in Version 5 kann man dies in den Datenbankeigenschaften erweitern => "Allow more fields" auf dem letzten Reiter. Dann hat man 64.000 Feldnamen zur Verfügung => laut Hilfe. an die Grenze bin ich bisher noch nicht gestossen  

... zu deinem anderen Problem mach ich mir nochmal Gedanken...

ata

[florianh78]

Hallo zusammen,

wie versprochen hier eine Aktualisierung und zugleich Konkretisierung meines Problems, leider noch nicht mit Lösung.

Es geht darum, ein Feld auszulesen, dessen Name variabel ist und der erst zur Laufzeit "zusammengesetzt" wird.

Unterproblem a): Kann der Formelsprache sowas klargemacht werden? Definitionen der Form
feldname := "bla" + "blubb"
implizieren offensichtlich leider eine unumgängliche Interpretation als String.

Unterproblem b): @GetDocField() liest leider nur aus _anderen_ Dokumenten, beim Zugriff auf das aktuelle tritt ein Zugriffskonflikt auf.

Lösungsansatz 1: eine Möglichkeit für Unterproblem a) finden

Lösungsansatz 2: Es irgendwie schaffen, in einen Berechneten Text o.ä. ein LotusScript einzubauen, das mit der Aufgabe ja keine Probleme haben dürfte.

Irgendwelche Kommentare hierzu?

Grüße,
 Florian

PS: M.E. fehlt der Formelsprache hier wichtige Funktionalität... Da will man sich schon an das Notes "Dokumenten"-Konzept halten (im Unterschied zur relationalen Modellierung), und siehe da, Notes widerspricht mit der unverständlichen Implementierung @GetDocField "Du darfst nur aus anderen Dokumenten lesen".

[florianh78]

So, jetzt hab ich eine funktionierende Lösung bzw. eher einen Workaround gefunden. Hier eine kurze Skizze für alle, die's interessiert:

1) Beim Öffnen/Aktualisieren des Feldes im Dokument wird ein LotusScript angestossen, das den neuen Feldinhalt im Profildokument ablegt. Als Feldname dient dabei KEYWORDS_ + UNID.

2) Daraufhin kann dieses Feld in der Berechneter-Text-Formel mit den entsprechenden Profildokument-@-Funktionen ausgelesen werden.

Da ist wohl noch niemand drauf gekommen, denn meine Frage hab ich in abgewandelter Form mehrfach auch im Lotus Developer Domain Forum gefunden, doch nie mit positiver Antwort.
Hat meine Lösung etwa gravierende Nachteile, die ich noch nicht sehe?

Grüße,
 Florian

[ata]

... wie legst du das Profildokument an, mit einem Key?
... greifen eventuell mehrere Personen schreibend auf dieses Dokument zu - könnte Probleme geben...

ata

[florianh78]

@ata:
Das ganze steht dann im benutzerspezifischen Profildokument, also greifen schonmal nicht mehrere User schreibend zu.

In diesem Dokument sind dann nach und nach folgende versteckte Felder enthalten:
KEYWORDS_UNID1 = kw1, kw2, kw3, ...
KEYWORDS_UNID2 = kw4, kw5, ...

Werds wahrscheinlich so machen, daß ich beim Öffnen des benutzerspez. Profildokuments alle diese Felder lösche, damit sich keine Leichen ansammeln. Das beeinträchtigt ja die Funktionalität nicht, denn ich überschreibe/lege neu an mittels ReplaceItemValue.

Grüße,
 Florian

[ata]

... du solltest beim Handling von Profildokumenten die folgenden Dinge beachten:

1. Profildokumente befinden sich während der Session eines Users im Cache. Das hat zur Folge, daß das Dokument permanent vorliegt. Das macht den Zugriff sehr schnell. Hat aber zur Folge, daß die Daten nicht für alle immer gleich sind. Während der Session findet meines Wissens nach keine Aktualisierung des Dokumentes statt - will sagen - ich kann nicht sehen was andere User im Doc hinterlegt haben solange die DB nicht vom User geschlossen wurde.

2. Ich hatte Probleme mit Replikations-/Speicherkonflikten. Es ist also wichtig, daß du eine Maske entwirfst und ihr die Eigenschaft "Replikationskonflikte mischen" mitgibst. Damit wird auf Feldebene repliziert. Konflikte tauchen erst auf, wenn ein Feld von 2 Usern zur gleichen Zeit gespeichert wird.

... eventuell ließe sich das auch mit "normalen" NotesDokumenten abbilden - die sind besser zu handeln...

ata

[florianh78]

Also, ich hab jetzt alles implementiert und auch schon auf einem Domino-Server mit mehreren Benutzern getestet... funktioniert einwandfrei.

Trotzdem noch danke an ata für den Hinweis mit dem Profildokument. Da aber ja jeder Benutzer (für diesen Zweck) sein eigenes hat stellt das kein Problem dar. Werde mir aber für zukünftige Verwendungszwecke diese speziellen Probleme merken.

Grüße,
 Florian