Lotus Notes / Domino Sonstiges > Java und .NET mit Notes/Domino

Formelsprache TO LotusScript Code-generierer schreiben

<< < (5/20) > >>

flaite:

--- Zitat von: eknori am 30.08.05 - 18:45:43 ---Ob der Aufwand aber in Relation zum zu erzielenden Erfolg steht wage ich zu bezweifeln.

--- Ende Zitat ---

Dir fehlt einfach der Glauben an die Kraft und Reinheit der GOF Design Patterns, Ulrich.




 ;D

koehlerbv:

--- Zitat von: eknori am 30.08.05 - 18:45:43 ---Als Ergebnis erhalte ich @if(@Command([CN];@UserName)="Hein Bloed";1;2) zurück; und jetzt ?

--- Ende Zitat ---

Und das Ergebnis müsste ja eigentlich lauten: "Syntax error !"  ;D

Ich halte das Thema auch für hochinteressant - aber eher theoretischer Natur. Das Vorgehen bei @functions und mit LS ist ja teilweise ein völlig anderes, und ein pures Umsetzen von @functions nach LS erscheint mir zweifelhaft. @functions habe ihre Welt (und lassen sich teilweise durch LS überhaupt nicht ersetzen), und LS hat eben einen ganz anderen Hintergrund. Ein derart automatisch umgesetzter Code waäre auf jeden Fall alles andere als optimal.

Weiterhin: Warum soll neben @functions (source code) und LS (target code) noch eine weitere Sprache (und System) (Java) zum Tragen kommen ?

Bernhard

Gandhi:
@Bernhard: Syntaxüberprüfung ist definitiv gar nicht drin ;)
@Eknori: Genau das soll es auch ;)

Wie gesagt: Jede einzelne Anweisung wird erst mal in einen neuen Tree umgewandelt - der im ersten Schritt eben Deine gesamte Formel ist, da sie aus nur einer verschachtelten Anweisung besteht.

Bsp.:
_Field feld:=feld;  ==> erster Tree
_retVal:=@if(@Command([CN];@UserName)="Hein Bloed";1;2)  ==> zweiter Tree
_b:=@if(cond1;@if(cond2;@if(cond3;.....==>dritter Tree

jeder Tree muss dann baummässig soweit aufgesplittet werden, bis nichts mehr geht - und die Blätter/Endknoten dann in Script übersetzt und zusammengebaut werden.
Die Sache mit dem Array von Trees hat meiner Meinung nach den grossen Vorteil, dass die Reihenfolge nicht verloren geht.

Um das Ergebnis zu erhalten, dass Du gerne hättest, Ulrich, vergeht sicher noch ein wenig Zeit.

Insgesamt ist es aber aufgrund des relativ klaren Syntax (Tokentrennung) vermutlich relativ einfach Formulas so zu zerlegen (ganz im Gegensatz zu LotusScript - wo so eine schöne Trennung mittels klar definierter Zeichen und simplen Regeln fehlt)

Das Hauptproblem sehe ich in der (Deppenarbeit) alle Formeln umzusetzen - und in der Kontextabhängigkeit von Formeln. FormelAgents umzusetzten ist sicher gar kein Problem, was aber macht man z.B. mit Wertformeln.
Ich will mich daher auf Agenten beschränken - und hier kann man das ruhig auch in Java machen - wobei man sich damit - zunächst (bis zur Eclipse Plattform) einiges verstellt.

Gandhi:
Aber das gibt tatsächlich Probleme ohne Ende...

Angenommen:

Am Ende eines Baumes steht: 1:2:3:4
Also ein Integer Array.
Das muss man erst identifizieren bevor man es weiterverarbeiten kann.

Und selbst bei einer Beschränkung auf Agenten gibt es ja solche, die auf alle Dokumente der DB wirken, solche, die auf eine Auswahl wirken und solche, die auf keine speziellen Dokumente wirken. Also 3 verschiedene Scripte je nach Agenteneinstellung...

eknori (retired):

--- Zitat ---Syntaxüberprüfung ist definitiv gar nicht drin
--- Ende Zitat ---

Doch, wo .ohl, siehe !!HELP!! Projekt  :D

und bitte nicht mit Heiligenbildchen kontern ... ;D

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete