lotusscript --> java

[Micha]

Ich habe nebenbei wärend meines gesamten Studiums Notes DB's entwickelt.
Dabei habe ich immer nur LS eingesetzt. (oder formeln)
Parallel habe ich im Studium java kennengelrent (grundwissen)
nun wollte ich mal zwecks web-fähigkeit fragen mit welchem Aufwand LS codes in java portiert werden können.
Gibt es da ein Beispiel oder ne Hilfe dazu.
Ich hab leider so direkt nichts dazu gefunden.

[Axel_Janssen]

Ich hab am Freitag von etwas gehört, wo 2 fitte russische Diplomanden aus dem xml-dump einer Notes Datenbank eine struts-basierte, auf Tomcat/Websphere laufende .war generieren. Inwieweit dort aber der code weiterverarbeitet wird, kann ich nicht beurteilen. Stelle mir das auch ziemlich kompliziert vor. Verstehst du unter Webfähigkeit die Portierung nach J2EE ? Die beschäftigen sich mit sowas: http://www.img.de/e/home/news.jsp?myParam=imgdotone

Mit viel, viel Fleißaufwand und nicht mal viel Hirnschmalz dürfte es möglich sein LotusScript code zu parsen und damit Java code zu erzeugen. Jedoch gibt es Beschränkungen: In Notes-Java existieren keine UI-Klassen.
Auch schreibt man Java Anwendungen ganz anders. Ich schreibe an einer Swing-Anwendung, die auf Notes zugreift. Den code aber automatisch aus einer Notes Maske zu generieren, halte ich aber für eine explizitst nicht-triviale Aufgabe.  

Gruß Axel

[Ralf_M_Petter]

@Axel

Ich persönlich finde jede Form der automatischen Umwandlung von einer Welt in eine andere für pervers, den wie du richtig schreibst, sind Lotus script und Java zwei komplett andere Welten. In Lotus script wird zu 90% prozedural und nicht objektorientiert programmiert. Es wäre zwar eine Umsetzung (Ausnahme der UI Klassen) möglich, nur würde das Java Code ergeben, der absolut nicht den Standards üblicher Java Programmierung entspricht. Also wenn schon Umbau einer Notes Applikation nach J2EE, dann ein komplettes Reenginering, wobei auch die Stärken der neuen Umgebung ausgenützt werden, oder bleiben bei good old notes.

Grüße

Ralf

[Axel Janssen temp]

@Ralf:
(ich mag ein bischen voreingenommen sein, weil ich dort jetzt arbeite)
Das Tool, das ich btw. nur sehr oberflächlich kenne, konvertiert Teile der Funktionalität einer NotesDatenbank in auf Tomcat/Websphere lauffähigen code.

Die Konvertierung findet auf dem source code level statt. Man erhält also das
J2EE "Programm" (.war file) mit allen Servlets, JSPs und sonstigen Klassen in Form von source code.
Die so generierten J2EE Programme bauen auf dem weit verbreiteten und von IBM gepushten struts-framework auf. Struts ist ein framework. Vereinfacht gesprochen handelt es sich bei struts um ein paar open-Source extra-Klassen, die J2EE-Programmierung einfacher und strukturierter machen.

Der durch das tool generierte code sieht übersichtlich aus. Problematisch wäre es, wenn da ein undurchschaubares Gemölsch entstehen würde. Das ist nicht der Fall.

Das Tool funktioniert als Eclipse-Plugin. Ich glaube an die Zukunft von Eclipse als die Java-Entwicklungs Platform. Ich hab in den letzten Monaten auch viel mit Netbeans gearbeitet, aber Eclipse wird sich IMHO durchsetzen.

Meldungen wie diese sehe ich als tendentielle Bestätigung dafür, wobei noch nix entschieden ist:
http://www.eweek.com/article2/0,3959,1236132,00.asp

Beide sind aber sowieso recht ähnlich. In Eclipse gibt es eine ganze Menge sinnvoller Dinge zu entdecken. Ich arbeite gerade das Buch von www.manning.com (22 Euro als pdf) durch. Das ist gut. Vielleicht ist das von Joe Pluta noch besser: Link zu Joe Plutas Buch

Das Tool erzeugt natürlich nicht die gesamte J2EE-Anwendung. Vielmehr kann es aus der .nsf einen funktionsfähigen Rahmen generieren, den man natürlich erweitern muß. Man könnte z.B. Notes als Prototyping-Tool benutzen. Außerdem erleichtert das Tool die Portierung von vorhandenen Notes-Anwendungen auf J2EE.
Ersetzen wird sowas J2EE Programmierung nicht. Im neuen Javamagazin gab es einen Schwerpunkt auf Model Driven Architectures (ist ja ähnlich: code wird aus einem meist graphischen Modell erzeugt). Da kam aber auch raus, dass die erstmal naheliegende Schlußfolgerung, dann keine Entwickler mehr zu brauchen, völlig unbegründet ist. Diese Dinge unterstützen die Produktivität eines Entwicklers.

Gruß Axel