@Formula-Befehle in Lotus Script abbilden

[eknori]

der Humor der Schweizer ist unschlagbar  

[Semeaphoros]

Also, weiss ich nicht, wie stark das generalisiert werden darf, dazu kommt, dass mein Pass nicht in Bern ausgestellt wurde ......

Na, der Ausdruck "cool" triggered bei mir meistens auch nicht unbedingt positive Gefühle, und so kommt es dann ab und an mal zu einer Parodie ......  

[TMC]

nur coole Codes aufnehmen, keine 0815 Einzeiler

OK, cool ist ja bekanntlich relativ.

Ich meine:
Ein

Code

Function min(a,b)
   If a < b Then
      min = a
   Else
      min = b
   End If
End Function

müsste nicht aufgenommen werden.
Dafür schaut keiner in einer Code-Plattform etc. nach.

Coole Codes wären z.B.
 - eine Liste bereinigen (Leere Zeilen rausschmeißen, doppelte Werte raus,
   alphabetisch sortieren);
   sowas verwende ich bsp. in Setup-Docs wo man Kategorien vorgibt, wäre auch
   praktisch in Addressbooks wo in den Gruppen Namen eingetragen werden
 - Listen / Feldinhalte etc. in Windows-Zwischenablage kopieren; dabei noch
   der Funktion übergebbar, wie die einzelnen Werte getrennt werden sollen
   (@Newline, Semikolon, etc.)
u.v.m.

TMC

[TMC]

*Nachtrag*
Also cool im Sinne des DAU's
"hey, cool, hab hier zig doppelte Werte drin und ewig viele Leerzeilen, aber wenn ich auf den Button klicke ist alles purged..."

TMC

[Semeaphoros]

......    ah, ein Purgativ .....

[eknori]

das kommt ja auch ein bisschen auf die Zielgruppe an; ein Anfänger mag so seine  Schwierigkeiten haben einen Min / Max/ stdDev  Funktion zu schreiben

Auch solcher Code ist wichtig; möglicherweise kann man dan kategorisieren: absolute Beginner, professional, god user... wobei dann bei der letzten Kategorie keine  Ergebnissen angezeigt werden dürften

Was für den Einen selbstverständlich ist, ist es noch lange nicht für einen anderen; also sollte auch de bewährte Min /Max Code berücksichtigt werden.

Aber da ist das noch recht einfach. Wenn ich mir so die unterschiedlichen "ReplaceSubstring" anschaue; da sollte man sich schon für eine  entscheiden. Es darf halt nichts redundantes dabei sein.
Da stellt sich bei mir die Frage, was ist performanter ?? native LS oder auch ein @evaluate ?

Das muss man testen, ob das in allen Versionen verwendbar ist; und wenn, dann gibt es EINE freigegebene Version der Funktion oder Sub.

Und wenn die dann in Appl. eingesetzt wird, kann man die auch supporten

Ulrich

[TMC]

ich weiß zwar nicht was ein Purgativ ist aber wenigstens gehst Du nicht auf meine Anglizismen los... (z.B. purged)  

Sonst bau ich hier mal ein @DBLookup ein zu http://vds-ev.de/denglisch/anglizismen/anglizismenliste.php

 
TMC

[eknori]

hey, cool, hab hier zig doppelte Werte drin und ewig viele Leerzeilen, aber wenn ich auf den Button klicke ist alles purged...

also "cool" im Sinne von "Ey, Alder, krrass coding" oder so.

Getz check isch das  

[Semeaphoros]

Kul ........  





Vielleicht sagt Dir Bernhard, was ein Purgativ ist, passt jedenfalls sehr gut zu Deinem Bleistift ....  

[Glombi]

Ich für meinen Teil halte es nicht für unbedingt nutzbringend, etwas in LotusScript nachzuprogrammieren, was einem die @Formelsprache bereits "schenkt" - zum Bleistift ein "@ReplaceSubstring".

Als Einstieg in die Evaluateonstheorie hier ein Link:
http://www-10.lotus.com/ldd/today.nsf/0/1b582ddee7c72e10852566ac005f0b99?OpenDocument

Bzgl. der Performance denke ich, dass Evaluate meistens schneller ist (ausser jemand hat da einen super Script-Algorithmus, welche dem "eingebauten" Algorithmus bzgl. Performanceüberlegen ist).

Andreas

[TMC]

@Ulrich:
Hmm, stimmt, eigentlich hast Du schon Recht.

Zum anderen begonnenen Projekt (http://www.free.dominoserver.de/computer/noteslibrary.nsf):

Ich wußte vorher gar nicht dass es da schon was gibt;
Die Ansätze sind M.E. auch wirklich prima. Nur wird das wohl nicht (mehr) gelebt.

Vielleicht sollte man das zusammenfahren (dieses Projekt hier und das von damals).

Schön wäre in der Notes-DB noch ein Berechtigungskonzept, damit nicht nur 1 Person schreiben darf. 2-3 sollten es schon sein. Und mit Prüfroutine (z.B. auch: es kommt nix rein, wenn nicht vorher hier gepostet und getestet wurde).
Und die erwähnten Pflichtfelder (Autor, Version, etc.)

TMC

[Semeaphoros]

Andreas:
Das ist auch meine Meinung, das Nachprogrammieren von @Functions war solange sinnvoll, wie Evaluate noch massiven Einschränkungen unterlag.

Meine Taktik:
Gibt es in LS ein Aequivalent, das fast dasselbe tut? --> Use it

Sonst: Verwende Evaluate, ggf. mit Nacharbeit des Ergebnisses.
¨
Erst wenn auch das nicht möglich ist: ausprogrammieren.

Ausnahme: die LS-Ersatzfunktion für @Func ist sehr kurz und performant, so dass sie die Kosten des Aufstartens der @-Engine unterschreitet.

Ein Performance-Test ist bestimmt interessant.

[eknori]

Nur wird das wohl nicht (mehr) gelebt

schade eigentlich. Ich muss aber auch zu meiner Schnade gestehen, dass meine Aktivitäten dort arg zu wünschen übrig gelassen haben.

OK, es heißt ja "Reboot tut gut", also lasst uns noch einmal beginnen.
( unter Einbeziehung des bisher Geleisteten )

Ulrich

[TMC]

OK  

Wer hat denn eigentlich Schreibrechte auf die DB?
Und gibt es irgendwo ein Template davon, dass man um die besagten Felder erweitern kann?

Ich würde sogar das nochmal neu starten (leere DB, und nur Functions etc. übernehmen, die hier im Thread als  'OK' befunden werden.

TMC

[eknori]

es war damals so vereinbart, daß der zu veröffentliche Code an AXEL geschickt wird. Der hat Schreibrechte.

Ich biete mich gerne an, ein solches project auf meinem Server zu hosten. Nur sollten wir Axel dabei bitte nicht übergehen.

Ulrich

[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

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

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]

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

... 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]

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

... 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 ?

Genau darauf war ich aus!
Laßt uns doch anhand dieses simplen Beispiel-Codes mal festlegen was wir brauchen.

Solange das alle nicht in trockenen Tüchern ist, sollte der code gar nicht erst gepostet werden.

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]

Embedded XML halte ich auch für sinnvoll.

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