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

Formelsprache TO LotusScript Code-generierer schreiben

<< < (6/20) > >>

flaite:

--- Zitat von: eknori am 30.08.05 - 19:32:09 ---und bitte nicht mit Heiligenbildchen kontern ... ;D

--- Ende Zitat ---
Das ist kein Heiligenbildchen. Auf dem schönen Bild ist eindeutig die Jungfrau Maria zu sehen.

Aber jetzt mal im ernst. Ich schaue mir das einfach mal an wie weit ich komme. Der Rest ist eh Spekulation. Bisher sind aus meiner Sicht noch keine besonders gewichtigen Gegenargumente gekommen. Ausser, dass es sehr viel ist. Aber das habe ich ja auch schon gesagt.
Und ich habe auch gesagt, dass es mir schon ausreichen würde, wenn eine Teilmenge der Formeln übersetzbar wäre. Ich will aber ein System schaffen, dass komplexitätsmässig gut skalliert. Dh. dass es am Ende genauso einfach ist, eine zusätzliche Formel einzubinden wie am Anfang. Oder noch einfacher, weil das Framework besser ist. Aber erst am Wochenende, weil ich in meinem Tagesjob
- momentan auch eine sehr interessante Aufgabe habe: Allgemeines Generierungsverfahren einer XML Datei aus verschiedenen Notesanwendungen für XML-Beschreibungsdateien (unterschiedliche und änderbare Typen) und
- wir Anfang September ein Punktrelease haben und da sind noch issues auf der Liste.

Möglicherweise ist die Grundarchitektur relativ einfach und die explodierende Anzahl an in die Gesamtarchitektur problemlos einplugg-baren Klassen ist dann Fleißarbeit. Ich weiss es einfach noch nicht. Prognosen sind schwierig, vor allem wenn sie sich auf die Zukunft beziehen.
Naja. Ich werds mal anfangen.

@Gandi: Ich würd keine Arrays nehmen, sondern List, bzw. als konkrete Klasse wohl java.util.ArrayList. Das Identifizieren ist kein Problem. Ich will die semantische Bedeutung quasi schon beim parsen klären (vereinfacht ausgedrückt). Aber das ist alles Spekulation.

Axel

flaite:
@Bernhard: einen Sinn hat das schon und ich hab das weiter oben gesagt: Ich arbeite öfters mit älteren Formelsprache-Code. Und da wurde Formelsprache in Kontexten verwendet, in denen wir heute Skript verwenden. Und das macht die Anwendungen schwer wartbar. Ich hab schon einige male per Hand bestehenden Formelsprachecode in LotusScript umgewandelt. Andreas G. (zu schwieriger Nachname) hat glaub ich auch mal erwähnt, dass er das gemacht hat. Oft ist der Kontext, in dem in bestehenden Anwendungen Formelsprache verwendet wird historisch gewachsen. Und dafür kann das hilfreich sein.
Es soll in keinem Fall eine Art Tool werden, mit dem Leute die "Formelsprache nicht können" Lotusscript generieren. Sondern es hat einen ganz klaren Fokus auf "Refaktorierung von Legacy Code".
Anwender brauchen Java nicht zu können. Ich kann da verschiedene Interfaces für bauen. Eine GUI, eine Webseite, Files, ein Webservice. Egal.
Anwender müssen natürlich Java können, um Arten von Formeln konvertieren zu können, die noch nicht unterstützt werden. Es gibt ja viele Formeln. Und da es explizit als Framework-Code gedacht ist, soll es relativ einfach sein Erweiterungen zu schreiben. D.h. es gibt einen gewissen Rahmen, auf denen die Klassen aufsetzen können.

Es gibt bestimmte prä-XHTML-parsing openSource Frameworks in Java, mit denen HTML Files geparsed und aus den einzelnen Tags ein Objektbaum generiert wird. Da könnte ich vermutlich einiges abkupfern.

Axel

koehlerbv:

--- Zitat von: Gandhi am 30.08.05 - 19:03:30 ---@Bernhard: Syntaxüberprüfung ist definitiv gar nicht drin ;)

--- Ende Zitat ---

Das war schon klar, Gandhi. Der von Dir gepostete Code war sehr gut lesbar  ;D Das war eher ein Joke auf Ulrichs Beispiel - und eigentlich nicht (ganz) ernst gemeint, da eine Validierung wohl dann die absolute Kür sein müsste (der zu übertragende Code sollte ja wenigstens schon mal lauffähig gewesen sein).

Bernhard

koehlerbv:
Völlig ohne Frage, Axel. Ich habe es logischerweise auch mit Situationen zu tun, in denen "hysterisch gewachsener" Code mit @functions sinnvollerweise (weil @functions dort wegen fehlender Möglichkeiten / durchaus auch schlechter Wartbarkeit) durch LS ersetzt werden müssen.

Bisher bedeutete das nach meiner Erfahrung immer Situationen, in denen das ganze Herangehen auszutauschen war. Und an vielen Stellen sind @functions prinzipiell nicht austauschbar, weil technisch bedingt einfach nicht ersetzbar.

Weiterhin - und was ich schon einmal geschrieben habe: Wenn man @functions austauscht gegen LS, dann verfolgt man damit sinnvollerweise auch ein ganz anderes Konzept der Programmierung. Ich kann mir einfach nicht vorstellen, dass eine sture "Sprachkonvertierung" hier wirklichen Zugewinn generierert.

Als eine Art "Recompiler / Umsetzer" mit starkem Parser ist das Thema natürlich hochinteressant. Ich bezweifele nur den praktischen Nutzen. Ansonsten  würde ich mich da liebend gerne beteiligen (mein erstes "Projekt" war Mitte der 80er ein 6510 Assembler, der logischerweise erstmal in Maschinencode zu erstellen war, bis er selber "mithelfen" konnte, sich selber verbessern zu helfen).

Bernhard

flaite:
... denke aber, dass auch wenn man nur Teile des Formelsprache-Code automatisch in LotusScript umwandelt, dann hat man eine Basis, mit der die Umstellung auf LotusScript einfacher ist. Das soll ja keine LotusScript Programmiermaschine ohne menschliche Interaktion sein. Man kann den generierten Code ja weiterverarbeiten.

Aber das sind eh alles erstmal ungelegt Eier.
Ich suche erst einmal nach openSource Projekten mit einer ähnlichen Aufgabe.
Bisher gefunden:
http://sourceforge.net/projects/htmlparser
FALLS JEMAND EINEN WEITEREN VORSCHLAG HAT, bitte posten.

Ich versuche dann Design-Prototypen zu erstellen. Sobald ich etwas habe, poste ich.

Axel

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete