OO Entwicklung mit LotusScript - Frage externer Editor / Eclipse?

[JulianBuss]

jau, somit is m.E. nach die Entwicklung eines Syntax-Checkers direkt in Eclipse ein guter Ansatz, so dass man das Script selbst per %INCLUDE einbinden kann und trotzdem von Compile-Fehlern verschont bleibt.

Preisfrage ist aber natürlich: wie siehts denn mit Runtime-Fehlern aus...? Das teste ich mal gleich.

[animate]

da ist das gleiche Problem. Wenn du was per %Include einbindest und da tritt ein Laufzeitfehler auf, dann kriegst du nur die Zeilennummer des Include-Statements. Das is halt der Mist

[JulianBuss]

verdammt, selbes Spiel: Runtime-Fehler werden natürlich auch mit der Zeilennummer des Includes gemeldet.
D.h. wenn man Error-Handling verwendet und z.B. sowas wie
---
print "LS-Error "+error$+" ("+cstr(erl)+")"
---
steht in error$ zwar der korrekte Fehler, in erl aber die Zeilennummer des Includes.

Schade :-(

[animate]

ich habe mir u.a. hier schonmal Gedanken gemacht:

http://www.atnotes.de/index.php?board=7;action=display;threadid=12135;start=0

habs dann aufgegeben, weil zu wenig Zeit.

ich vermute, dir gehts auch darum, den Code nicht zu veröffentlichen.
für mich wäre das ein akzeptabler Workaround, eine Entwicklungsversion mit Script zu haben und eine öffentliche mit Includes.
Und wenn ich jetzt gerade die C++ API- Referenz anschaue, dann sollte das damit automatisierbar sein. Ich werde da mal weitermachen.

[JulianBuss]

ja, nicht-veröffentlichen von Code ist ein angenehmer Nebeneffekt - in der Regel liefern wir unsere Produkte aber sowieso mit versteckter Gestaltung und ermöglichen die Anpassung via definierter Schnittstellen / Plug-Ins.
Das wäre also kein primary Target für mich.

Das Problem mit der C-API ist denke ich, dass man zwar compilieren lassen kann, aber Fehler nicht verünftig (Zeilennummer) gemeldet bekommt.
Jedenfalls ist die Include-Strategie ja wohl zum Scheitern verurteilt - siehe meine vorigen Posts.

Das ist übrigens auch ein Problem von verstecken des Codes via Include - wir haben in jeder Methode ein Error-Handling, was einen Fehler mit Zeilennummer protokolliert. Das ist für den Support enorm wichtig; wenn beim Kunden doch mal ein Bug auftritt kann man mit diesem Protokoll sehr schnell die Ursache anhand der Zeilennummer rausfinden.
Wenn die Scripts nun via Include eingebunden sind und somit keine korrekte Zeilennumemr eines Runtime-Fehlers gemeldet wird, ist die protokollierung sinnlos und der Support sitzt wie der Ochs vorm Berg.

Also wäre doch die Variante mit Speichern via XML in Notes-Design-Dokumenten mit anschließendem compilieren via C-API die Bessere?

[JulianBuss]

ich hab mal geguckt; in LS-Bibliothekten ist das Script im Klartext im Feld "$ScriptLib" gespeichert.
D.h. Eclipse könnte das Script einfach in diesem Feld speichern und dann die C-API NSFNoteLSCompile anstossen.

Zusammen mit einem Syntax-Checker für die üblichsten Compile-Fehler direkt in Eclipse wäre das doch ein guter Weg!

In Agenten übrigens scheint das anders auszusehen; dort ist ein eventuelles Script in binärer Form gespeichert. Ich denke aber sowieso, dass LS-Bibliotheken erstmal das wichtigste sind.

Auf jeden Fall kann man von Java aus eine Windows C-Funktion aufrufen; d.h. das Java basierte Eclipse-Plugin kann die NSDNoteLSCompile ausführen.

[animate]

so einfach geht das nicht mit dem "im Feld speichern".
Hab ich schon mal probiert (resultierte in Generic LSE failure beim Öffnen der Bibliothek. s. hier)

das war noch zu Notes5 Zeiten, vielleicht hat sich was geändert.

aber die C++-API bietet eine ScriptLibrary-Klasse an mit den Methoden getLotusScript und setLotusScript. Das hört sich zumindest gut an.

[Semeaphoros]

Dann muss es aber auch über die C-Api direkt gehen, denn die C++ Api ist "nur" ein Wrapper um das Ganze

[JulianBuss]

nö, hat sich nix geändert. Habs grade ausprobiert :-)
So einfach gehts in der Tat nicht.

[animate]

hmm, das hier könnte der Grund dafür sein, dass es nicht so einfach geht:

(aus der C++API-Referenz)

Also note that you cannot specify the LotusScript for an agent, button, form or view action, or action hotspot by passing an LNLotusScript object that was constructed "from scratch" with a string or LNString containing pure LotusScript code as you would enter it in Notes. This is because the code lacks special comments that are normally inserted and parsed by Notes when you manually create LotusScript. To properly specify LotusScript code, you must get it from an LNLotusScript object that represents LotusScript that was manually created and saved in Notes.
This does not prevent you from using strings containing LotusScript, but it does require some extra steps. For example, if you had a library of scripts, you could add them to agents by doing the following:
  1.   Manually or programmatically create a database that holds a series of LotusScript agents named after your scripts.
  2.   Manually copy and paste your scripts from text files into the new agents.
  3.   Save the new agents so that Notes can insert its special comments.
  4.   Write code that gets the LotusScript code from the agents you just created and adds it to agents in your target database. For example:
LNDatabase    agentDb, targetDb;
LNAgent       agent, newAgent;
LNLotusScript script;

agentDb.GetAgent("Script1", &agent);
agent.Open();
agent.GetLotusScript(&script);

targetDb.CreateAgent("NewAgent", TRUE, &newAgent);
newAgent.SetLotusScript(script);
//set other properties
newAgent.Save();

[animate]

wenn du eine DB nach XML exportierst, dann sieht das allerdings recht vielversprechend aus:

<globals><code event='options'><lotusscript>Option Public
Option Declare
Use "Actions"
Use "de.tv.Document"
Use "de.tv.State"
</lotusscript></code><code event='declarations'><lotusscript>Dim oState As State</lotusscript></code></globals><code
 event='postopen'><lotusscript>Sub Postopen(Source As Notesuidocument)
   If source.isnewdoc Then
      
      Set oState = New State("")
      Set oState = oState.getStartState()
      
      Call source.Document.ReplaceItemValue("State", oState.StateName)
      Call source.Document.ReplaceItemValue("NextStates", oState.NextStates)
      'Call source.FieldSetText("State", oDummyState.StateName)
      Call source.Refresh
   End If
End Sub</lotusscript></code>

jetzt müssen wir nur noch rausfinden, ob man den Code ändern kann (das geht) und die DB updaten kann (das ist die Frage)

[JulianBuss]

das mit den "special" comments habe ich bereits rausgefunden, ich habe mal das Feld $ScriptLib in ein Textfile geschrieben, das sieht z.B. so aus:
---
'++LotusScript Development Environment:2:5:(Options):0:74
Option Public

'++LotusScript Development Environment:2:5:(Forward):0:1
Declare Sub test

'++LotusScript Development Environment:2:5:(Declarations):0:2

'++LotusScript Development Environment:2:2:test:1:8
Sub test
   Messagebox "test2"
End Sub
---

-> reicht aber nicht, einfach das File dann zu verändern, einzulesen und im $ScriptLib Feld zu speichern. Denn: Notes schreibt an vielen Stellen nur chr(10) für einen Zeilenumbruch statt 10+13 ("0A" statt "0A0D").
Und ich kann das modifzierte Textfile zwar wieder mit den 0A's einlesen (indem ich es als binary öffne), aber sobald ich diesen String wieder ins Feld schreibe werden die 0A's in 0A0D's konvertiert. Ich denke das ist Teil des Problems.

Im Grunde hast Du aber natürlich Recht, XML ist der bessere Weg, ich hoffte nur es könnte auch auf die einfache Art gehen :-)

XML einlesen kann man ja soweit ich weiß, also sollte man doch nur das ScriptLib-Dokument via XML exportieren, Inhalt ändern, wieder einlesen und dann den API-Aufruf zum compilieren starten können.

[JulianBuss]

ich hab mal eine Lib nach XML exportiert, bekomme sie aber nicht wieder importiert. Es kommt nur der Fehler "DXL import failed", im importer.log steht was von "note id not found"

Hast Du eine Idee wodran das liegen könnte?

--
Dim stream As NotesStream
   Set stream = session.CreateStream
   Dim filename As String
   filename = "c:\temp\test.xml"
   If Not stream.Open(filename) Then
      Messagebox "Cannot open " & filename,, "Error"
      Exit Sub
   End If
   If stream.Bytes = 0 Then
      Messagebox "File did not exist or was empty",, filename
      Exit Sub
   End If
   
   Dim importer As NotesDXLImporter
   Set importer = session.CreateDXLImporter(stream, db)
   importer.DesignImportOption = DXLIMPORTOPTION_CREATE
   Call importer.Process
--

[JulianBuss]

COOOOOOOOOOOOOOOOOOOOOOOL!!!!!!!!!!!!!!!

ich kann die bestehende Lib noch nicht überschreiben, aber wenn ich folgendes mache:

1.) lib nach xml exportieren
2.) xml-datei ändern, z.B. aus einem "Messagebox "test"" ein "Messagebox "test2"" gemacht
3.) lib in Desginer löschen
4.) xml importieren

dann funktioniert die geänderte Lib OHNE NEU-COMPILATION!!!

Ich kann die Lib von einem Agent aus direkt benutzen, ohne sie im Designer nochmal öffnen zu müssen.

Jetzt muss man nur noch eine bestehende Lib via DXL-Import überschreiben können und schon ist alles gut!!

[animate]

Arrgh. hab grade keinen Designer zur Hand. sobald ich wieder einen habe probier ich auch mit rum. is ja echt cool, dass das ohne Neukompilieren geht.

[JulianBuss]

nur den Replace einer bestehenden Lib krieg ich nich hin... ständig kommt der Fehler "dxl importer operation failed" und im log "note item not found"...

[animate]

selbes Ergebnis hier

Sub Initialize
   
   Dim session As NotesSession
   Dim db As NotesDatabase
   Dim nc As NotesNoteCollection
   Dim exporter As NotesDXLExporter
   Dim importer As NotesDXLImporter
   
   
   Set session = New NotesSession
   Set db = session.CurrentDatabase
   Set nc = db.CreateNoteCollection(False)
   nc.SelectScriptLibraries = True
   Call nc.BuildCollection
   
   Set exporter = session.CreateDXLExporter(nc)
   Set importer = session.CreateDXLImporter(exporter, db)
   importer.DesignImportOption = DXLIMPORTOPTION_REPLACE_ELSE_CREATE
   exporter.Process
   
End Sub

ich hab mal im notes.net-Forum gepostet und hoffe, dass Rod Whiteley hilft. Der ist der Ober-XML-Checker.
http://www-10.lotus.com/ldd/nd6forum.nsf/DateAllThreadedweb/5fe101c2d870225c85256e7a00602586?OpenDocument

[JulianBuss]

gut, warten wir also :-)
Wenn's nicht klappt, muss man die Lib vor dem Import halt löschen; im XML-File steht ja die UNID des entsprechenden Notes-Dokuments drin. Sollte also machbar sein.

Da wir ja so langsam die grundlegenden Möglichkeiten positiv getestet haben, ist die Frage: wie koordinieren wir?

Was wir aus meiner Sicht brauchen:
- ein Ort, an dem man gemeinsam Dokumente (Konzepte & Ideen) bearbeiten kann: dafür kann ich unser Wiki anbieten, das ist einfach und unkompliziert.

- ein CVS, indem wir die Sourcen managen

- ein Forum zum diskutieren -> dafür könnte ich auch uns ein neues Forum einrichten

Und weiter:
- sollen wir daraus ein openntf.org Projekt machen? (meine Meinung: vielleicht)
- soll das überhaupt OpenSource werden (ich denke: ja)
- alles (Sourcen, Doku) von Anfang an auf Englisch (ich denke: ja)

Zu openntf.org: ich würde da gerne ein "öffentliches" Projekt draus machen, ich komm nur mit der openntf.org Workspace nicht wirklich zurecht... vielleicht wäre sourceforge der bessere Ort.

[animate]

eine coole Sache ist mir grade noch aufgefallen. Für die ganzen Export-/Import-Geschichten bietet Notes ja auch Java-Klassen an. Ideal für ein Eclipse-Plugin.

Zur Koordination: das mit dem Wiki find ich gut.

Ich habe weder Erfahrungen mit sourceforge noch mit openntf.org (außer was downloaden). Bietet soureforge einen CVS-Server an? Ich hab mich grade bei denen umgesehen, blick aber null durch auf der Seite.
Axel hat ja auch sourceforge vorgeschlagen. Vielleicht kannst du ja nen Tipp dazu geben, Axel.

die anderen Fragen sind mir im Moment egal. schaun wir erstmal, ob wir ein gescheites Konzept zusammenkriegen und dann können wir darüber nachdenken.

[JulianBuss]

Ich hab mal ein englische Wiki aufgesetzt:

https://www.youatnotes.de/php-bin/wiki/phpwiki-e/index.php?pagename=HomePage

Ist ein wenig langsam, aber man kann mit arbeiten. Mozilla und Firefox mögen das verwendete Stylesheet aber nicht lesen, deswegen möglichst mitm IE verwenden.