Lotus Notes / Domino Sonstiges > Projekt Bereich
@Formula-Befehle in Lotus Script abbilden
TMC:
OK, lasst uns doch mal starten.
Funktion: PurgingLists
Kurzbeschreibung: Sortiert ein Array alphabetisch und entfernt Leerzeilen
Verwendung: Für Felder mit Mehrfachwerten, Dokument ist im Bearbeitungsmodus
Aufruf-Beispiel:
--- Code: ---Sub Click(Source As Button)
Dim workspace As New NotesUIWorkspace
Dim uidoc As NotesUIDocument
Dim doc As NotesDocument
Dim Purging As Variant
Dim MyUnique As Variant
Set uidoc = workspace.CurrentDocument
Set doc = uidoc.Document
Purging = PurgingList(doc.IchBinDasFeld)
Call doc.ReplaceItemValue("IchBinDasFeld", Purging)
Call uidoc.Reload
End Sub
--- Ende Code ---
Die Funktion:
--- Code: ---Function PurgingList( feldwert As Variant ) As Variant
Dim k As Integer
Dim i As Integer
Dim j As Integer
Dim h As Integer
Dim r As Integer
Dim memberArray() As String
Dim temp As String
'Build an array of values to sort
For k = 0 To Ubound(feldwert)
Redim Preserve memberArray(1 To k+1)
memberArray(k+1) = Cstr(feldwert(k))
Next
'Set up for Shell sort algorithm
h = 1
Do While h < k
h = (h*3)+1
Loop
h = (h-1)/3
If h > 3 Then
h = (h-1)/3
End If
'Shell sort algorithm
Do While h > 0
For i = 1+h To k
temp = memberArray(i)
j = i-h
Do While j >0
If memberArray(j)>temp Then
memberArray(j+h) = memberArray(j)
memberArray(j) = temp
Else
Exit Do
End If
j = j-h
Loop
Next i
h = (h-1)/3
Loop
PurgingList = memberArray
End Function
--- Ende Code ---
Hier stelle ich gleich mal die Frage:
Sollte man gleich noch ein @Unique einbinden? Oder lieber separat behandeln?
Ich tendiere zu 'separat behandeln', damit es übersichtlicher bleibt.
Der Code sollte jetzt noch angepasst werden:
- Errorhandling
- unsere festgelegten Standards (wie benenne ich Variablen etc.)
- evtl. noch weiter fassen damit auch in anderen Situationen verwendbar
TMC
eknori (retired):
--- Zitat ---Der Code sollte jetzt noch angepasst werden:
- Errorhandling
- unsere festgelegten Standards (wie benenne ich Variablen etc.)
- evtl. noch weiter fassen damit auch in anderen Situationen verwendbar
--- Ende Zitat ---
... und ganau das meint Axel_Jansen: Solange das alle nicht in trockenen Tüchern ist, sollte der code gar nicht erst gepostet werden.
Und warum nicht die Informationen zum Code in einer Art "embedded XML" Struktur im Header des Codes abbilden ?
TMC:
--- Zitat von: eknori am 16.11.03 - 19:18:19 ---
--- Zitat ---Der Code sollte jetzt noch angepasst werden:
- Errorhandling
- unsere festgelegten Standards (wie benenne ich Variablen etc.)
- evtl. noch weiter fassen damit auch in anderen Situationen verwendbar
--- Ende Zitat ---
... und ganau das meint Axel_Jansen: Solange das alle nicht in trockenen Tüchern ist, sollte der code gar nicht erst gepostet werden.
Und warum nicht die Informationen zum Code in einer Art "embedded XML" Struktur im Header des Codes abbilden ?
--- Ende Zitat ---
Genau darauf war ich aus!
Laßt uns doch anhand dieses simplen Beispiel-Codes mal festlegen was wir brauchen.
--- Zitat ---Solange das alle nicht in trockenen Tüchern ist, sollte der code gar nicht erst gepostet werden.
--- Ende Zitat ---
Sehe ich anders: hier im Thread gepostet: selbstverständlich ja. In der fertigen Plattform: no!
Dieser Code hier sollte lediglich als erste Diskussionsbasis dienen.
Embedded XML halte ich auch für sinnvoll.
Axel_Janssen:
--- Zitat von: TMC am 16.11.03 - 19:31:35 ---
Embedded XML halte ich auch für sinnvoll.
--- Ende Zitat ---
Wofür brauchen wir das xml?
So wie ich das momentan sehe:
1) für das für mich sehr wichtige Kollaboration feature (use case folgt)
2) um vom Java-Tool drauf zuzugreifen. Wobei das auch völlig egal ist, da man ja auch auf normale Notes-Dokumente zugreifen kann.
Das xml braucht aus meiner Sicht nicht in die Masken-Felder reingefrickelt zu werden (falls ihr das mit embedded xml meint).
Das geht viel besser mit Spaltenformeln. (so die Art Spaltenformel: "<Beschreibung>" + Beschreibung + "</Beschreibung>".
Das klappt eigentlich gut. Bringt zwar gewisse Performance-Kosten mit sich. Die Anwendungsfälle, die ich für xml sehe (Kollaborations-Feature), sind nicht wirklich performance-kritisch.
koehlerbv:
Was das Thema XML jetzt hier soll, kann ich nicht ganz nachvollziehen ...
Vorab sollten doch folgende Fragen stehen:
- Sammeln "cooler" Codes (ich bleib' hier mal aus Erinnerungsgrünen beim nutzlosen Denglisch)
- Überlegen: Was gehört in eine LScriptLibrary, was man in jeder halbwegs anspruchsvollen Anwendung ggf. gebrauchen kann
- Art der Einbindung: Library nur komplett (Routinen dürfen sich gegenseitig aufrufen) oder jede Routine einzeln verwendbar ?
- Einheitliches Coding
- Einheitliche Kommentierung / Dokumentierung
- Sinnvolles ErrorHandling (incl. Berücksichtigung, wo der der jeweilige Code gerade läuft - FrontEnd, Backend, ErrorRoutines dürfen sich unter keinen Umständen selbst aufrufen et. pp.)
- Saubere Trennung zwischen Front- und Backend-Routinen (incl.: Was kann vom Web aus verwendet werden?)
- Umfangreiche Tests samt Protokollen
Wenn sowas steht, haben wir etwas zur Verfügung, was wir alle gebrauchen können, bei dem wir alle was lernen können: DANN können wir darüber nachdenken, wie das Einbinden vereinfacht wird, was man nach XML bringt etc. Vorher wüsste ich auch nicht, was ich mit XML anfangen sollte. Aus meiner Sícht ist das bis dahin pure, nutzlose Theorie.
Wie gesagt: Ich wäre gerne dabei. TMC hat gerade erst eine tolle Moderation bei solch einem Projekt geleistet, das nicht an theoretischen Diskussionen gescheitert ist, sondern ein wirkliches Ergebnis gebracht hat. Und ausdrücklich ist dort verwiesen auf "Version 2", an der wir alle weiter arbeiten können / sollen.
Schauen wir mal, ob wir Profs-AtNotes nun auch dieses - zugegebenermassen - viel anspruchsvollere Projekt gestemt kriegen ;-)
Ich wäre dabei ;-)
Bernhard
Navigation
[0] Themen-Index
[#] Nächste Seite
[*] Vorherige Sete
Zur normalen Ansicht wechseln