Formelsprache TO LotusScript Code-generierer schreiben

[flaite]

Hallo,

hat jemand dafür vielleicht irgendwelche verwertbaren Ansätze, Artikel, ähnlich geartete openSource Projekte oder Literatur?
Damit ich das direkt ein bischen schlauer anfange.
Oder gibt es sowas schon?
Da ich das relativ häufig machen muß, hab ich mir überlegt, dass eventuell zumindest teilweise zu automatisieren.
Naiv würde ich sagen, dass ich den Formelsprache rekursiv in immer kleinere Tokens zerlege und daraus mir dann LotusSkriptcode zusammenschreibe.
Ziemlich rekursiv und dann State Maschine und Command Pattern (das kann jetzt total danebenliegen, fiehl nur eben so ein).
Muß ja nicht direkt jeder Formelsprachen-Befehl umgewandelt werden. 
Aber schon allein die DB-Lookups wären eine echte Arbeitserleichterung.
Falls jemand Lust hat. In C# oder in Java.
Wenn Interesse, dann yes or no. Keine "Ich weiss nicht ob ich das kann"-Meldungen. Dann lache ich immer so hämisch. Das macht Falten im Gesicht...

Axel

[Gandhi]

Evaluate  ?

Im Ernst: Mit Evaluate müssten wenigstens die Lookups funktionieren.
Aber: Was ist denn das Ziel? Der User gibt @Formulas ein und Du wandelst diese dann um? Dann wären meine nächste Frage "wozu" und mein Statement zu den Usern: "Das müssen ziemlich fortgeschrittene User sein"
Oder geht es um eine Möglichkeit @Formulas in Deinen Skripten zu verwenden (Library?)

Mit Evaluate habe ich mal gearbeitet um einen Excel Import/Export Agenten zu schreiben (benutze Excel Zeile X mit Formel Y und berechne daraus Feld Z). Das hat bei wenigen Formeln gut und bei den meisten gar nicht funktioniert.

[Gandhi]

OK, ich glaube ich beginne zu verstehen. Du willst KOMPLEXE Formulas in Skripten ausführen.

Dazu wäre mein Ansatz erst mal die Funktionen wenigstens zu wrappen.
Dann benötigt man einen Parser, der die Funktionen tranchiert. So erhält man einen Tokenarray, der dann an die Subfunktionen übergeben würde....

Habe leider gar keine Ahnung von Compilerbau - beim ersten Punkt wäre ich aber definitiv dabei.

[flaite]

Doch so ungefähr. Mit den Tokens und Tranchieren sehe ich genauso.
Dann müssen die Tokens eben gruppiert, umsortiert und in LotusScript konvertiert werden.
Ich möchte Formelsprachencode reinkopieren und unten kommt Skriptcode raus.
Wenn ich an bestehenden Notes-Datenbanken arbeite, kommt es des öfteren vor, dass ich Formelsprachen-Code durch Skriptcode ersetzen zu müssen. Ich glaub Glombi hat sich einmal ähnlich ausgedrückt.
Ich hab nix gegen Formelsprache. Es ist einfach nur so, dass es Sinn macht, um eine Anwendung zu "konsolidieren", d.h. halbherzig implementierte Features rausschmeissen oder User-fähig zu machen. Es kommt dann oft vor, dass ich Skriptcode brauche. Z.B. ein Fall wo ein Feld des öfteren die 32-K (oder whatever) Grenze überschreitet. Dieses Feld wird leider von ca. 9 verschiedenen Skripten in Formelsprache oder LotusScript gefüllt (nicht übertrieben). Ich möchte das Feld ab einer bestimmten Größe auf 2 oder mehr Felder aufteilen (Adressen, Adressen_1, etc.). Dafür muss ich aber den Prozess managen und dafür möchte ich erstmal allen Code, der dieses Feld füllt oder verändert in Skript umwandeln.
Ein anderer Fall für diesen Formelsprache-zu-Skcript-Prozess ist RichText-Handling. Das wurde früher oft mit Formelsprache gemacht. Aber seid Domino6 gibt es da offenbar stabil funktionierende Klassen. Dort wäre ich mit Skript auch flexibler.

Ziel ist es so ein (ein bischen anonymisiertes) Skript einzugeben:

Code

_A := @DbLookup("Notes":"NOCACHE";"":"";"($aaa)";"AToc";"ATitle");
_Application:=@If(@IsError(_A); @Failure("Fehler Meldung !"); _A);
_B := @DbLookup("Notes":"NOCACHE";"":"";"($AVIEW)";"ADOC";"Admin");
_Server := @Name([Abbreviate];@Subset(@DbName;1));
_DB := @ReplaceSubstring( _B;"@CurrentServer";_Server);
_DbView := "($Server)";
_DbKey := _Application + "@CurrentServer";
_Res:= @DbLookup("": "NoCache"; "":_DB; _DbView; _DbKey; 2);
_Server1 := @Subset(@DbName;1);
_Fields := @ReplaceSubstring( _Res;"@CurrentServer";_Server1);

_SerienbrDB := @Left(@Right(_Fields;"||aDB#"); "||");

_DataFormulare := @DbLookup("": "NoCache"; "": _DB; "(aView)"; "A DB" ; "DataBerichte");

@If(@IsError(_DataFormulare) | _DataFormulare = "";@Do(
@Prompt([OK];"Fehler";"a meldung.");
@Return("")
);
"");
_EleFormular := @Sum(@DbLookup("": "NoCache"; "": _DB; "(aView)"; "AnDB" ; 2));
@If(_EleFormular > 1; @Do(
@Prompt([OK];"Fehler";"kind of meldung.");
@Return(""));
"");

_SerienFormulare := @Explode(@Left(@Right(_DataFormulare;"||BerichteFormulare#"); "||"); "$");

_a1 := @Left(@Right(_DataFormulare;"||Name1#"); "||");
_a2 := @Left(@Right(_DataFormulare;"||Name2#"); "||");

_SerienFormulare3 := @Explode(@Left(@Right(_DataFormulare;"||BerichteFormulare3#"); "||"); "$");

_Maske_1 := _Maske_1;
_Maske_2 := _Maske_2;

_Aktionen := _SerienFormulare3;
_antwort := @If( @Elements( _Aktionen ) = 1; _Aktionen; @Prompt([OKCANCELLIST] : [NoSort]  ; "Ausführen von" ; "Bitte wählen sie ..." ; @Subset(_Aktionen ;1) ; _Aktionen ) ) ;
@If(_antwort = _a1;
     @Do(
             @Set("_Maske_1";@Left(@Right(_DataFormulare;"||Maske1#"); "||"));
             @PostedCommand([FileOpenDatabase]; "" : _SomeDB ; "(Mainnavigator)" ; "" ; "" ; "");
             @PostedCommand([Compose];  "" : _SomeDB ; _Maske_1)
                );
_antwort = _a2;
     @Do(
             @Set("_Maske_2";@Left(@Right(_DataFormulare;"||Maske2#"); "||"));
             @PostedCommand([FileOpenDatabase]; "" : _SomeDB ; "(Mainnavigator)" ; "" ; "" ; "");
             @PostedCommand([Compose];  "" : _SomeDB ; _Maske_2)
                );
"")

Und daraus LotusScript Code erzeugen.
Oder zumindest Teile davon übersetzen. Der Rest bleibt in Formelsprache stehen. Da ich das sowieso übertragen muß. Wäre zumindest eine Arbeitserleichterung.

Ich find das eine interessante Aufgabe.
Axel

[flaite]

Die Tokens einsammeln und daraus einen Tree aus Command Objekts bauen. (Composite-Pattern + Command Pattern). 
http://www.dofactory.com/Patterns/Patterns.aspx

[Gandhi]

OK. Solche Skripte sind die Hölle. Wobei ich mich immer frage: Wer schreibt so etwas?

Wie aber geht man da vor? Keine Ahnung

Die Schwierigkeit beginnt ja beim Auslesen der Token...@x(parameter1(@Y(p2;p3;@Z(p4))))
Ein wenig Orientierung geben ja die Klammern - vielleicht wäre dies ein allererster Ansatz zur Zerlegung.

Irgendwan habe ich mal BNF lernen müssen...das kommt mir gerade hoch, wenn ich an syntaktische Token denke.

Wie ist der Syntax von Formelsprache?
Entweder eine Variablen/Feldzuweisung - oder ein Select - oder ein Semikolon - oder eine @Funktion. Korrekt?

Dann müsste man den Syntax der einzelnen Elemente identifizieren.
Auf jeden Fall würder man vermutlich sehr sehr viel über @Formulas lernen. Wozu das auch immer gut sein sollte

[Gandhi]

Genau, ein Tree zum Sammeln der atomischen Tokens wäre richtig.
Das macht die Sache auch vom Verfahren her einfacher:
Der gesamte Baum wird bei Root, also der Gesamtformel beginnend, schrittweise aufgeteilt - bis die Knoten nicht mehr differenzierbar sind.
Dann wird von den Knoten aus das Script erzeugt - also genau der entgegengesetzte Vorgang gestartet.

[flaite]

Formelsprachenkenntnisse hab ich genügend.
Das Ende vom nächsten Token hängt vom Kontext ab.
Kann Klammer sein oder ein Semikolon.
Manches muß umgruppiert werden (im Tree). Die Parents im Tree rufen jeweils die Kinder auf. Das muss irgendwie gehen.

Für sowas wie @Explode gibt es kein direktes Äquivalent in Skript. Aber ich hab für sowas SkriptLibraries, die das abbilden.
Ich sag nicht, dass das einfach ist. Aber ich halte es irgendwie für schon machbar.

Axel   

[eknori]

Für sowas wie @Explode gibt es kein direktes Äquivalent in Skript

Kommt auf die Version an; in ND6 SPLIT

[Gandhi]

Mit den Klammern als Kennzeichen meinte ich: Eine Funktion mit Parametern beginnt stets mit einer öffnenenden Klammer und endet mit einer schliessenden. Dazwischen müssen alle Klammern die geöffnet werden auch geschlossen werden. Sobald also [Anzahl öffnender Klammern]-[Anzahl schliessender Klammern]=0 ist die Funktion beendet - und der Inhalt zwischen ( und ) kann weiter aufgelöst werden.

Weiterhin bekannt ist, dass zwei Funktionen/Zuweisungen/Anweisungen/... immer mit Semikolon getrennt werden. Für weiteres muss dann tatsächlich der Kontext bemüht werden - was bei Dingern wie Picklist - mit sehr vielen Parametern  - zumindest aufwändig sein kann.

[flaite]

Attraktiv finde ich:
- ich kann es direkt sinnvoll einsetzen
- ich kann nach dem "Scharping-Prinzip" vorgehen: laaannngsam. Dh. muss nicht alles direkt fertig sein, damit es einen Nutzen stiftet. Wenn der Teile des Formelsprachencodes stehen lässt und z.B. erstmal nur die DBLookups konvertiert ist es besser als vorher.

Ich glaub ich fang am WE an. Oder vorher. Ist aber schwierig vorher anzufangen. Sobald ich was habe, poste ich.

[Gandhi]

Genau: Formeln lassen sich wie folgt aufteilen: In einen Array aus Trees.

Ist keine Klammer mehr zu schliessen ergibt ein Semikolon einen neuen Tree.

Im ersten Schritt müsste also nach dieser Regel ein Array von Root-Knoten erzeugt werden, die dann separat aufzudröseln sind.

Problematisch ist auch der Kontext einer Formula - je nach Ort des Auftretens ist da ein anderer ScriptCode zu erzeugen.

[flaite]

Ich brauche ich bruache für den ganzen Tree EINEN Einstiegspunkt. Ist aber egal. Dieser eine Einstiegspunkt hat dann eben eine List aus dem was du meinst.

[Gandhi]

Also ein Array hat - gegenüber einem 'normalen' Tree den Vorteil, dass er sortiert ist - was bei der Reihenfolge der Auswertung ja nicht ganz unwichtig ist.
Ausserdem - und viel wichtiger - entspricht das meiner Meinung nach eher dem, was eine Formel darstellt: Eine Reihe von Trees - letztendlich durch Semikolon getrennt (wenn keine Klammer zu schliessen ist).

Einen solchen Array mit Einstiegsknoten erhält man - z.B. so: (entnommen einem Button, der ein Feld namens Formula zerlegt).

   Dim formula As String
   Dim openBrackets As Integer
   Dim closedBrackets As Integer
   Dim stringPointer As Integer
   Dim TreeArr() As String
   Redim TreeArr(0)
   Dim cursor As String
   Dim token As String
   
   Dim uwo As New NotesUIWorkspace
   Dim udo As NotesUIDocument
   Set udo=uwo.currentdocument
   
   formula=udo.FieldGetText("formula")
   
   For stringPointer=1 To Len(formula)
      cursor=Mid(formula,stringPointer,1)
      If Not (cursor=Chr(10) Or cursor=Chr(13)) Then 'ignore
         If cursor=";" Then
            If openBrackets=closedBrackets Then
            'Token complete
               Redim Preserve TreeArr(Ubound(TreeArr)+1)
               treeArr(Ubound(TreeArr)-1)=token
               token=""
            Else 'still open brackets
               token=token+cursor
            End If
         Elseif cursor="(" Then
            openBrackets=openBrackets+1
            token=token+cursor
         Elseif cursor=")" Then
            closedBrackets=closedBrackets+1
            token=token+cursor
         Else
            token=token+cursor
         End If
      End If
   Next

Nur als Beispiel - ziemlich ungetestet und ungeschönt.

[Gandhi]

Diese Trees müssen nun weiterverarbeitet werden - hierbei beginnt dann wohl die Arbeit...

[flaite]

Sehe ich nicht so. Das sind spezielle Commands mit einem gemeinsamen Command Interface.

Code

Class CommandDBLookupSingle implements CommandLotusScriptGenerator {
 
// die alle mit set und get
StringBuffer tempDoc;
StringBuffer dbVariable; 
StringBuffer vwVariable;
StringBuffer docKeyVariable;
StringBuffer fieldVariable; 
StringBuffer resValue;

// in Interface definiert
public StringBuffer execute() {
   StringBuffer retVal = new StringBuffer(60);
    retVal = tempDoc.append("=").append(dbVariable).append(".getDocumentByKey(").append(docKeyVariable).append()).append("\n")
.append(resValue).append("=").append(tempDoc).append("getItemValue(").append(fieldVariable).append(")").append("(0)"); 
}
}

Ziemlich naiv. Aber so die Richtung. Für jeden Formelsprachenbefehl muss man natürlich mehrere Command-Objekte erstellen.

Axel
 

[Gandhi]

Was meinst Du mit 'Sehe ich nicht so'?

Dass es viel Arbeit ist?


Und: Planst Du die Umsetzung in Java (was ist mit Frontend Befehlen) oder in Script?

UND: Vermutlich sitzt/sass bei IBM jemand, der genau sowas für die Eclipse Plattform geschrieben hat...aber an den Code werden wir in diesem Leben vermutlich nicht mehr rankommen...

[flaite]

Wieso ich fang an das in Java zu schreiben. Wenn man komplett jeden @Befehl unterstützen soll ist es komplex, aber so kann ich erstmal anfangen.
Falls sich das als tragfähig erweist, kann das dann auf eine openSource Plattform getan werden und andere können - wenn sie wollen - die Lücken füllen. Glaub nicht, dass IMG daran kommerzielles Interesse hat. Mehr will ich nicht. Für mich ist das auch erstmal keine Arbeit sondern Training.
So etwas fehlt mir eben.

[flaite]

Dafür eine praktisch umgesetzte architektonische Basis zu schaffen ist ja auch keine stumpfsinnige Sklaventätigkeit, sondern eigentlich ganz interessant.

[eknori]

sehr interessantes Thema; leider raucht mir schon der Schädel, wenn ich _retVal:=@if(@Command([CN];@UserName)="Hein Bloed";1;2) tokenized in Script umsetzen muesste.
Und an verschachtelte @IF möchte ich erst gar nicht denken ...

Die Umsetzung ist sicherlich möglich, da es sich "nur" um String Operationen handelt ( das kann Notes ja bekanntlich ). Ob der Aufwand aber in Relation zum zu erzielenden Erfolg steht wage ich zu bezweifeln.

@Gandhi: wie behandelt denn dein Code mein Beispiel ? Als Ergebnis erhalte ich @if(@Command([CN];@UserName)="Hein Bloed";1;2) zurück; und jetzt ?