Formel Libraries

[cgorni]

Ich bin neu hier und dachte ich steige mal mit einem Trick ein, den ich so noch nirgendwo gesehen habe, den ich aber schon öfter ausgenutzt habe:

Wiederverwendbare Formeln!

Die Situation
----------------
Es kommt immer wieder vor, das man in Masken ein und dieselben Formeln (vielleicht leicht abgewandelt) an verschiedenen Stellen benutzt. Als einfaches Beispiel sei hier die typische Überprüfung von "Muss"-Feldern in der Feldvalidierung genannt:

@If(Nachname = "";
         @Failure("Bitte geben Sie einen Wert für das Feld 'Nachname' ein");
         @Success)

Das benötigt man vielleicht 10x für verschiedene Felder (wenn man nicht LotusScript und QuerySave benutzt).


Idee
------
Eine Stelle definieren, an der die Formel ein einziges Mal steht und immer wieder an verschiedenen Stellen genutzt werden kann, also eine Art "Formel-Library".


Handwerkszeug
--------------------
Es gibt in Notes6 einige ganz nette @Formeln, die uns helfen portablen Code zu schreiben:
  @ThisValue
  @ThisName
  @GetField(<Feldname>)
  und
  @Eval(...) !!

Insbesondere @Eval ist interessant: es führt Formelsprache aus, die man als String-Parameter übergeben kann.

Lösung
---------
Wir verallgemeinern zunächst die Formel, sodaß sie in jedem Feld funktioniert:

@If(@ThisValue = "";
            @Failure("Bitte geben Sie einen Wert für das Feld '" + @ThisName + "' ein");
            @Success)

Jetzt machen wir daraus einen String - die neue Stringbegrenzung sei Dank ganz einfach, indem man den Code mit {...} eingrenzt. Also auch keine Notwendigkeit die " mit einem Backslash zu "entwerten". Wir erhalten:

{@If(@ThisValue = "";
            @Failure("Bitte geben Sie einen Wert für das Feld '" + @ThisName + "' ein");
            @Success)}

Folgendes würde schon in der Validierung funktionieren:

Code := {@If(@ThisValue = "";
                 @Failure("Bitte geben Sie einen Wert für das Feld '" + @ThisName + "' ein");
                 @Success)};
@Eval(Code)

Und jetzt machen wir das ganze zu einer "Library", ganz einfach dadurch, das wir den Code-String in einem "Shared Field" speichern, das wir F_Validation nennen ("F" für "Funktion") und das "Computed for display" ist.

Der Aufruf in der Validierung lautet jetzt einfach @Eval(F_Validation) und kann in jeder Maske benutzt werden, wo man das gemeinsame Feld einbaut.

Fertig ist der erste Teil der Formel-Library!



Erweiterung
----------------
Natürlich kann man das Beispiel (und damit die Möglichkeiten der Formel-Library) erweitern, in dem man unserer Validerung eine Parameter mitgibt. Das könnte man zum Beispiel erreichen, indem man die Parameter in ein spezielles Feld schreibt (F_Parameter, editierbar und verborgen) und die Funktion so umändert, das das Feld F_Parameter anstelle eines festen Textes benutzt wird. Ungefähr so:

FIELD F_Parameter := "Sie Nase."
@Eval(F_Validation)

und F_Validation ist

{@If(@ThisValue = "";
            @Failure("Bitte geben Sie einen Wert für das Feld '" + @ThisName + "' ein." + F_Parameter);
            @Success)}



So weit der Einstieg. Ich wäre natürlich jederzeit interessiert an Erweiterungen oder Verbesserungen dieser Idee.

Viel Spaß beim ausprobieren

Gruß
Christian

[Glombi]

Hallo Christian,
das ist aber ein starker Einstieg hier ins Forum 
Vielen Dank und herzlich willkommen!

Wenn ich Zeit habe, sehe ich mir das gerne an. Mal sehen, ob es auch für die Best Practices interessant ist.

Andreas

[eknori]

  hatte ich nicht erst hier ( http://www.atnotes.de/index.php?topic=14798.msg134893#msg134893 ) so etwas herbeigefleht ?.

@Eval ist der missing link, der mir da nicht in den Sinn kam.

Danke für das Augenöffnen !!  und herzlich willkommen im Forum

[Thomas Schulte]

Ich glaub da werden wir bald ein noch neueres Release des Helpdesk erleben.

[eknori]

Habe es gerade eingebaut; funzt prima 

[eknori]

netter Nebeneffekt, den man sich zunutze machen kann, wenn man Formeln mit "" in LS mittels evaluate ausführen will.

Einfach die benötigte Formel im Designer mit {} umschließen und die Maske abspeichern

AtGetString:=
{
@If(@Trim(@Middle(_SourceField; key + _seperator ;";"))="";
@Return(@Prompt([Ok];_ErrMsgHeader;_ErrMsgText + key + _ErrNotFound ));
@Trim(@Middle(_SourceField; key + _seperator ;";")));
};

Nach erneutem Öffnen sieht der Code dann so aus

AtGetString:=
" @If(@Trim(@Middle(_SourceField; key + _seperator ;\";\"))=\"\"; @Return(@Prompt([Ok];_ErrMsgHeader;_ErrMsgText + key + _ErrNotFound )); @Trim(@Middle(_SourceField; key + _seperator ;\";\"))); ";

Die \ werden automatisch vom Designer gesetzt; damit hat man einen schönen Syntaxcheck für seine Formeln.

Man, das wird ein langer Abend 

[Axel]

... ob es auch für die Best Practices interessant ist.

Hi,

ich habe das gerade mal überflogen. Das hört sich sehr interessant an. Ich glaube, dass ist auf jeden Fall was für die Best Pratices.


Axel

[eknori]

da kommt man aus dem Staunen gar nicht mehr raus

_SourceField:=MESSAGES;

REM {get some constants};
@Eval(F_HEADER);

REM {get message strings};
key := "msgTicketError";
_ConstErr:=@Eval(F_GETSTRING);
key := "msgTicketNotAvailable";
_ConstNotFoundInConfig:=@Eval(F_GETSTRING);
key := "msgTicketWarning";
_ConstWarning:=@Eval(F_GETSTRING);
key := "msgTicketUserNull";
_ConstUser:=@Eval(F_GETSTRING);
key := "msgTicketProbNull";
_ConstProblem:=@Eval(F_GETSTRING);
key := "msgTicketProdNull";
_ConstProdukt:=@Eval(F_GETSTRING);
key := "msgTicketParam";
_ConstParameter:=@Eval(F_GETSTRING);

REM {validate fields; throw exception if field is empty};
_Field:="user";
@Eval(F_ERR_IF_EMPTY);
_Field:="problem";
@Eval(F_ERR_IF_EMPTY);
_Field:="application";
@Eval(F_ERR_IF_EMPTY);

wobei F_ ... Computed When Displayed Felder sind, die den Code enthalten. Ich habe die Felder in eine Teilmaske gepackt.

Kleine Einschränkung:

Der vom Designer erzeugte "Code" ist nicht mehr so leicht zu überschauen ( gerade bei umfangreichen Formeln ). Das liegt weniger an den eingefügten \; vielmehr liegt es an den fehlenden CRLF

Da sieht der Code im Feld F_GETPARAMETER so aus

" @If(@IsError(@UpperCase(@DbLookup( _ConstNull : _ConstCache ; _ConstNull : _ConstNull; _ConstLUView ; _LookUpValue ; 2 ))); @Return(@Prompt([Ok];_ConstErr; _ConstParameter + _LookUpValue + _ConstNotFoundInConfig)); @UpperCase(@DbLookup( _ConstNull : _ConstCache ; _ConstNull : _ConstNull; _ConstLUView ; _LookUpValue ; 2 ))); "

Nicht gerade leicht zum pflegen. Daher sollte man seinen Code zunächst einmal gründlich testen, bevor man ihn in die FormulaLib übernimmt.

 

[cgorni]

Freut mich, das die Idee so gut ankommt   Ein paar Dinge sollte man bedenken, wenn man es exzessiv einsetzen will:

1) Sobald der Code-String einmal gespeichert wird (und dadurch automatisch die oben genannte Umwandlung in  \" stattgefunden hat) wird es schwer den Code zu debuggen oder zu erweitern. Es empfiehlt sich überhaupt sicher zu gehen, das der Code funktioniert.

2) Ich habe keine Ahnung, ob es ein Performance Problem geben kann

3) Ich würde davor zurückschrecken "komplizierte" Formeln in @eval auszuführen (z.B. @DBLookup) Obwohl in der Theorie nichts dagegenspricht ...

4) Für diejenigen, die es ganz wild mögen, kann man mit der Methode sich slebst modifizierenden Code schreiben. Allerdings: Wartbarkeit ade  

Aber für kreative Ideen ist trotzdem noch genug Platz.

Gruß,
Christian

[eknori]

2) Ich habe keine Ahnung, ob es ein Performance Problem geben kann

Möglicherweise gibt es durch die Einbettung des Codes in die Felder eine Einbuße;ich kann mit blossem Auge keine Probleme feststellen.

Hast du eigentlich mal getestet, ob das auch mit verstecktem Design funktioniert ??

[koehlerbv]

Hast du eigentlich mal getestet, ob das auch mit verstecktem Design funktioniert ??

Warum sollte das nicht funktionieren ?

Bernhard

[eknori]

wenn es nicht funktionieren würde, hätte Damien Katz bei der Neu-Erschaffung der Formel Engine ( Compute/Compile) einen groben Fehler gemacht.

Da sich Christian ja schon gut mit dem Thema beschäftigt hat, wollte ich nicht auch noch einen redundanten Versuch unternehmen ...

[cgorni]

Hallo,

ich habe das mit dem verborgenen Design nicht ausprobiert, schätze aber das es so aussehen wird:

- Shared Field ist verborgen
- Zum Ausführungszeitpunkt (d.h. wenn das Dokument geöffnet wird) ist der Code im Feld über die Eigenschaften des Dokuments  sichtbar

Gruß
C.

[animate]

Spitzentipp!
Ich wusste nicht, dass es diese @Eval-Funktion gibt (ok, ich brauch sie auch nicht mehr )
Was mir dabei sofort in den Sinn kommt ist ein Frontend, mit dem sich ein  Benutzer, der nicht der Formelsprache mächtig ist, selbst Aktionen zusammenklicken und auch wiederverwenden kann. Ich hoffe, ihr versteht, was ich meine...

[eknori]

ata hat da mit seinem "Jobber" so etwas am Start. Leider habe ich ihn hier lange nicht mehr gesehen. Hatte die Chance, mal einen kurzen Blick in die DB zu werfen. Da steckt schon echt gut was hinter. Mal gespannt, wann ata damit auf den Markt kommt. Sicher ist, daß das Teil dann aber nicht als Freeware zu haben sein wird ...

[Marinero Atlántico]

Ich wüsste nicht, wo der Vorteil von diesen Sachen gegenüber eine wesentlich leichter lesbare Validierung in LotusScript liegt.

[cgorni]

Ich hatte dieses Beispiel nur gewählt, weil es einfach zu nachzuvollziehen ist. Deshalb ja auch mein Aufruf für kreative Ideen, wie man @Eval sonst noch nutzen kann :-)

Ich gebe dir Recht, LotusScript ist das Mittel der Wahl, bei vielen Validierungen (hm, eigentlich bei allen)

Gruß,
Christian

[Marinero Atlántico]

nix gegen kreative Ideen.
Und nix gegen Formelsprache.
Und ich benutze auch schon mal eval.
Aber Übersichtlichkeit ist das wichtigste überhaupt.

[eknori]

Übersichtlichkeit ist das wichtigste überhaupt.

Da stimme ich dir voll und ganz zu.

WalterL hat ja zudem im Spotlight vor eventuellen Performanceeinbußen gewarnt http://www.spotlight.de/zforen/lts/m/lts-1109333300-10979.html

Und ich hatte ja schon weiter oben geschrieben, daß der Code dann nicht mehr unbedingt übersichtlich ist.
Wäre schöner, wenn zumindest die CRLF erhalten blieben.

Ich denke, daß ist jetzt auch kein MUSS, diese Methode anzuwenden.

Ich habe es jetzt mal so in die !!HELP!! eingebaut, da ich nicht davon ausgehe, daß irgendjemand an den bestehenden Aktionen was ändern wird.