Konkatenation von Variablennamen

[kevisback]

Hallo zusammen,

wie kann man in LS Variablennamen konkatenieren?

Das soll dann so aussehen:

Code

For i = 1 To count
doc.d + i = irgendwas
next i

d1 bis d10 sind meinetwegen die Felder im Dokument, die ich fuellen will per Schleife. Die Konkatenation habe ich schon mit allen bekannten Operatoren probiert, aber nichts funktioniert.

Hat jemand eine Idee?


Danke vielmals!!!

[m3]

Du willst notesDocument.ReplaceItemValue( ) verwenden, da kannst Du den Feldnamen als String angeben:
Set notesItem = notesDocument.ReplaceItemValue( itemName$, value )

Die "extended class" Syntax (doc.feldname) hat nicht immer Vorteile.

[Gandhi]

doc.feldname=...
ist irgendwie auch schlechter Stil - da der Code dann schlechter zu pflegen bzw. weiterzuverwenden ist, wobei ich ganz klar sagen muss, dass ich ob Faulheit das auch selbst ziemlich häufig nutze - vor allem für kleine Sachen.

[TMC]

doc.feldname=...
ist irgendwie auch schlechter Stil

Ja genau. Ist für mich *mittlerweile* selbe Liga wie Option Declare nicht einzuschalten, zumal auch Probleme auftauchen können wenn reservierte Properties Feldnamen entsprechen.
Ich kann es auch nicht nachvollziehen, warum das in größeren Apps überhaupt noch Leute verwenden, und nicht auf in Konstanten definierte Feldnamen verweisen.

[flaite]

Ich bin dieses Jahr zu der Überzeugung gekommen, dass: Es kommt drauf an.
In vielen Situationen ist es einfach nicht wichtig, ob man doc.getItemValue("feldName")(0) oder doc.feldName(0) schreibt. Es kommt eben einfach auf den Kontext an. Es gibt keine einfachen Regeln. In Python und Ruby wird zum Beispiel als Fortschritt gefeiert, dass es kein Äquivalent zu Option Declare gibt ! Wenn man einen functional programming Stil folgt mit kurzen Funktionen, mag das auch einfach so sein.
http://en.wikipedia.org/wiki/Python_programming_language#Functional_programming
Aber das ist offtopic.

In vielen Situationen finde ich Kurzschreibweise besser, weil einfacher zu schreiben und zu lesen. Es kommt eben immer auf den Kontext an.

[Gandhi]

Also Option Declare sollte meiner Meinung nach defaultmässig eingeschaltet sein - nicht mal wegen Stilfragen, sondern weil es mich vor unglaublich vielen Tippfehlern und endlosem Debuggen bewahrt.
Über die andere Sache lässt sich streiten. Ich setze das wie gesagt auch Situationsbezogen ein - und Konstanten für Feldnamen benutze ich sehr selten - da ich die irgendwie per se als fix betrachte.
Aber auch hier gilt, dass ich das tun werde, sobald es für mich Sinn macht.
Aber es gibt schon ganz schöne Unterschiede zum Stil:
Während viele inzwischen fast ausschliesslich objektorientiert Script schreiben - hat mein aktueller Vorgänger noch nicht mal (kaum) Funktionen oder gar Bibliotheken benutzt.
Dafür ist der Code dann wild über die DB verteilt - und ich wurde zum Suchenden...

[Glombi]

Die Extended Class Syntax zu verwenden ist meiner Meinung nach kein schlechter Stil. Solche Aussagen sollten vorsichtiger formuliert werden, ansonsten schmeisst nachher der Auftraggeber dir den Code um die Ohren.

Die Extended Class Syntax hat aber auch Nachteile gegenüber ReplaceItemValue:
1. Die Performance ist wesentlich schlechter, da der Compiler erst nach der Property/Methode sucht und dann - nachdem er keine gefunden hat - das als Abkürzung für ReplaceItemValue erkennt.
2. Aus 1 ergibt sich dann sofort das Problem: Wenn es DOCH eine Property gibt, so führt das zu Fehlern. Das ist bspw. der Fall, wenn in einer neuen Notes-Version eine neue Property hinzukommt.
Akutelles Beispiel (wurde auch hier im Forum behandelt): Lock

ein doc.Lock = "1" funktioniert dann eben nicht mehr.
Und sowas kann mit ReplaceItemValue nicht passieren.

Andreas

[flaite]

Die Extended Class Syntax hat aber auch Nachteile gegenüber ReplaceItemValue:
1. Die Performance ist wesentlich schlechter, da der Compiler erst nach der Property/Methode sucht und dann - nachdem er keine gefunden hat - das als Abkürzung für ReplaceItemValue erkennt.

Das ist in vielen Kontexten eben auch egal. In vielen Fällen wird keiner die eingesparte Zeit merken.
In 7 haben wir ja eine Profiling Klasse. Damit bekommt man für einen konkreten Kontext konkrete Aussagen über die Zeit, die für die einzelnen Funktionen benötigt wird. Betrachtet man Performance vom Standpunkt der merkbaren Auswirkungen beim User (und alles andere macht keinen Sinn), dann sind solche Argumente eben mehr so metaphysisch.

2. Aus 1 ergibt sich dann sofort das Problem: Wenn es DOCH eine Property gibt, so führt das zu Fehlern. Das ist bspw. der Fall, wenn in einer neuen Notes-Version eine neue Property hinzukommt.
Akutelles Beispiel (wurde auch hier im Forum behandelt): Lock
ein doc.Lock = "1" funktioniert dann eben nicht mehr.
Und sowas kann mit ReplaceItemValue nicht passieren.

Das ist ein Argument. Mit einem vernünftigen Test-Prozess bei einem upgrade auf die neue Version, in der das implementiert ist, sind die Kosten möglicherweise nicht besonders hoch.

Was ich nur sagen will ist, dass man an einer Menge Stellen aus verschiedenen Gesichtspunkten (Latenz, Skallierbarkeit, Wartbarkeit, etc. ) optimaleren Code schreiben kann. Wir machen es nur nicht, weil man eben nicht alles berücksichtigen kann. Und zwar keiner. Man kann nun 5 einfache Gesetze für "optimalen Code" aufstellen und das als "perfekten code" deklarieren. Die Regeln lassen aber bestimmt 120 Aspekte ausser acht. Ich bin sicherlich nicht gegen gute Programmierpraktiken. Will nur sagen, dass dies oft sehr komplex ist. Und das Ergebnis hinsichtlich einer totalen Betrachtung nie optimal ist.
Eine Architektur-, Design- oder Programmierentscheidung ist letztlich das Ergebnis einer Kosten-Nutzen Rechnung von denen ex ante die wirklichen Kosten und Nutzen nicht kennt.

Ein bischen wie die Theory of the second best in Wipol. In einem Markt mit Störungen führt eine Maßnahme die eine von mehreren Störungen beseitigt zu besseren, genau gleichen oder schlechteren Ergebnissen 
http://internationalecon.com/v1.0/ch100/100c030.html

Axel 

[Tode]

Würde jetzt möglicherweise jemand auf die Ursprüngliche Frage eingehen ?

Der Arme Kerl hat noch keine Antwort erhalten.

In LS funktioniert das concat. so:

Dim x(9) as String
For i = 1 to 10
  feldName = "D" & Cstr( i )
  x(i-1) = doc.GetItemValue( feldName )(0)
next

Das concat funktioniert aber nur mit Dokument- Feldern, für Variablennamen gibt es sowas nicht, da würde man das aber auch nicht so lösen, sondern entweder mit einem Array (x im obigen Beispiel) oder aber mit einer Liste.

HTH
Tode

[m3]

Tode: Die erste Antwort (meine) auf sein Posting enthielt bereits diese Antwort. 

[kevisback]

@Tode

Danke fuer die Antwort. Erst sie hat mich weitergebracht 

[Gandhi]

Ganz ehrlich, wenn Dir m3s Antwort nicht gereicht hat bist Du evtl. in dem Job falsch..

[kevisback]

Ich habs immer so gemacht, wie m3 es gesagt hat.

Ich dachte, dass meine Frage ohne jegliche Wertung haette beantwortet werden koennen und das hat nunmal als einziger Tode gecheckt...

[Gandhi]

Und was genau war an der Antwort M3s nicht in Ordnung

[kevisback]

Na er hat nicht gesagt, wie man eine Konkatenation durchfuehrt...

[Gandhi]

Also ganz im Ernst: 
Dafür gibt es
a) die Hilfe
b) wird es in jedem Buch beschrieben
c) wird es in jeder Schulung gelehrt
d) stehn hierzu im Forum bereits tausend Beispiele.

Also hast Du weder a) noch b) noch c) noch d) bemüht.

[kevisback]

.....aus folgenden Gruenden:


ad a) zeig mir, wo das steht
ad b) ich komme aus Shanghai -> hier gibts ehrlich keine Lotus Buecher
ad c) siehe b)
ad d) siehe a)


 

[Glombi]

Also jetzt kommt mal wieder runter.

@Ghandi:
Das Problem ist nun gelöst und es gibt keinen Grund, hier Kevisback so anzugehen.

@Kevisback:
Das in den Thread ausserdem eine Expertendiskussion zur Extended Class Syntax dabei war, würde ich an Deiner Stelle als Add-On mit nach Hause nehmen und für zukünftige Entwicklungen berücksichtigen.

Andreas

[Gandhi]

Also Hilfe:
Über den Designer öffnen
Auf Suche gehen
Concat eingeben
oder String eingeben

Dann werden verschiedene Dinge angezeigt.
Die Hilfe ist DIE Referenz - da stehen alle Basisfunktionen drin - und man muss schon lernen damit umzugehen, wenn man Notes entwickeln will.
Mein Groll richtet sich auch weniger gegen Kevisback als vielmehr gegen die, die hier jemanden Notes entwickeln lassen, ohne ihm wenigstens eine Basisschulung zu spendieren. Das kann nichts werden.

[m3]

.....aus folgenden Gruenden:


ad a) zeig mir, wo das steht

Es muss wirklich schwer sein, in der Notes Designer Hilfe im Index "String Conc" einzugeben. Damit wirst Du nämlich DIREKT auf den Hilfetext "String concatenation operators" geleitet.

Wenn jemand einen Variablennamen dynamisch erzeugen will, gehe ich davon aus, dass Lotusscript nicht seine erste Programmiersprache ist und die Person daher prinzipiell mit einer Online-Hlfe umgehen kann. Daher ist es in meinen Augen nicht vermessen anzunehmen, dass jemand das Kapitel "Lotus Script Language -> Expressions and Operators -> Overview of Expressions and Operators" anschaut. Dort findet sich nämlich auch ein hübsches "String concatenation" Beispiel.