Quellcode in 8.5.1 ausblenden funktioniert nicht mehr!

[Legolas]

Hallo Forum,

ich hatte bisher den Quellcode (Script Bibliotheken) in Anwendungen für Kunden herausgelöscht.
Dies habe ich über das Löschen des  $ScriptLib" Feldes durchgeführt
(Set Item = doc.GetFirstItem("$ScriptLib")) usw...

In der 8.5.1 Version funktioniert das offensichtlich nicht mehr, da alle Agenten die diese Bibliotheken inkludiert dann auf einen Fehler laufen.

Hat hier jemand eine Idee, wie das nun zu bewerkstelligen sein soll?

Danke
Bernd

[dirk_2909]

Hallo..

Leider habe ich auch die Beobachtung gemacht. Auch wir entfernen unseren Code in dem wir das Feld $ScriptLib leeren.

Wenn man mit 8.5.1 und dem "konventionellen" Editor arbeitet, ist es wir vorher.
Aber wenn man den eclipse-basierten Editor verwendet und ScriptBibliothen bearbeitet, die Libraries verwenden, deren Code entfernt wurde, dann werden diese Libraries beim Speichern zerstört.

Das liegt daran, dass unter File -> Preferences -> Domino Designer -> LotusScriptEditor die Option "Enable automatic recompilation of all dependencies" im Standard aktiviert ist. Wenn man diese Option deaktiviert, dann kann man zumindestens die Script-Bibliotheken, die die "beschnittenen" Libraries verwenden speichern.

Achtung!! -> ein Recompile All LotusScript zerstört natürlich die entsprechenden ScriptLibraries (was vor 8.5.1 trotzdem noch funktioniert hat)

Ist das nun ein Bug im Designer oder ein "Feature"?
Wer hat noch diese Beobachtung gemacht?
Was kann man jetzt machen, um Code zu "verbergen"?


P.S.: Das Verhalten lässt sich auch nachvollziehen, wenn man über ein %Include eine ScriptBibliothek eingefügt hat, deren lss-Datei aber nicht verfügbar ist.

[koehlerbv]

Das ist ein Bug. Von "Feature" kann man ja wohl eher nicht reden. Bislang hat sich der Designer immer mit dem precompilierten Code fremder Libs zufrieden gegeben und wollte nicht den Quellcode dazu sehen. Das ist ja auch Standard.

Tja, und was kann man jetzt machen, um den Code teilweise zu verbergen, ohne dem Kunden alles zu versperren: IBM Lotus beschimpfen und den Designer 8.5.x noch nicht verwenden. Das Teil wird noch gut, dafür spricht alle Erfahrung - aber derzeit ist es eben noch nicht wirklich ernsthaft einsetzbar.

Bernhard

PS: Es wäre besser gewesen,  IBM Lotus hätte erstmal alle anderen "Hausaufgaben" gemacht, die sie jahrelang ausgesessen haben (Beispiele nennt Thomas Schultes Website http://www.welovenotesbut.com) - vieles vom neuen Stuff kann man derzeit noch nicht ernsthaft anbieten, weil viel zu viel fehlt, und gleichzeitig werden alte Probleme weiter mitgeschleppt und damit ausgesessen.

[dirk_2909]

Bernhard, da gebe ich Dir voll und ganz Recht.

Aber "leider" wollen jetzt viele Entwickler den eclipse-basierten LS-Editor des DDE nutzen. Da haben dann viele Hersteller von 3rd-Party-Tools Probleme. Die meisten verbergen ihren Code auf diese Art und Weise. Ich hoffe nur, dass unsere Kunden/Partner es verstehen wenn man sagen muss: Nicht den eclipse-basierten Editor verwenden.

[eknori]

wenn man über ein %Include eine ScriptBibliothek eingefügt hat, deren lss-Datei aber nicht verfügbar ist.

Stimmt, kann ich bestätigen 

[pram]

Soweit ich auswendig weiß, speichert der Designer fehlerhaften Scriptcode in einem anderen Namen ab.
Ggf kann man ihn "austricksen" wenn man ein $scriptlib_error Item anlegt.

[dirk_2909]

@pram

Code

Ggf kann man ihn "austricksen" wenn man ein $scriptlib_error Item anlegt.

Was willst Du da hinterlegen? Den precompilierten Code?? Das ist aber nicht was wir wollen ;-)

@All

Ich habe erst mal einen Eintrag im ND DesignPartner-Forum gemacht. Ich warte mal eine Reaktion ab. Parallel können Betroffene ja eine PMR aufmachen?!

[eknori]

Thema wird auch aktuell auf LDD dikutiert http://www-10.lotus.com/ldd/nd85forum.nsf/DateAllThreadedWeb/a2a50581a2f9fa2f85257678006b0725?OpenDocument

[pram]

@pram

Code

Ggf kann man ihn "austricksen" wenn man ein $scriptlib_error Item anlegt.

Was willst Du da hinterlegen? Den precompilierten Code?? Das ist aber nicht was wir wollen ;-)

Natürlich nicht! Ich hätte einfach eines angelegt mit wahllosen Inhalt.

[dirk_2909]

Thema wird auch aktuell auf LDD dikutiert http://www-10.lotus.com/ldd/nd85forum.nsf/DateAllThreadedWeb/a2a50581a2f9fa2f85257678006b0725?OpenDocument

Hab ich vergessen zu erwähnen. Hab es auch (über ein Partner) im ND 8.5 Forum eingetragen.

[Jens Winkelmann]

Ich habe folgendes herausgefunden:

Man muss unter Options immmer alle Libraries angeben die man benötigt.
Nicht nur die direkten (wir früher) auch die indirekten.

Ein Beispiel:

Lib_A benötigt Lib_B und
Lib_B benötigt Lib_C

In Lib_A steht also Use "Lib_B" und in Lib_B steht Use "Lib_C"

Hierbei hat man mit dem DDE 8 ein Problem.

Wenn man jetzt aber in Lib_A auch alle indirekt genutzten Libraries einträgt gibt es kein Problem.

Also im Beispiel muss bei Lib_A Use "Lib_B" und zusätzlich die Zeile Use "Lib_C" stehen.

Jetzt kann man die Library Lib_A kompilieren.


Das ist natürlich eine mortz Arbeit alle indirekten Libraries zusätzlich in den Options einzutragen.

Maureen Leland hat im Business Partner Forum dieses Problem als 'confirmed as a bug' kommentiert.

Ich warte also bis das Problem beseitigt ist.

In der Zwischenzeit kann man sich mit dem oberen Workaround helfen.

Übrigens lösche ich nicht das Feld $ScriptLib sondern tausche den Feldwert aus.
Der neue Code enthält ein %INCLUDE auf eine nicht existierende LSS Datei.
Hierbei wird das Kompilieren der Library unterbunden.

Somit kann Recompile All Lotus Script nichts kaput machen.

[dirk_2909]

Somit kann Recompile All Lotus Script nichts kaput machen.

Hast Du das auch ausprobiert?

Wenn bei einem Include das File nicht vorhanden ist klappt es nicht ...

[Jens Winkelmann]

Moment - es gibt doch eigentlich 2 Probleme

Problem 1: Im DD8 gibt es jetzt die Fehlermeldung "Error loading Use or USELSX module"

Der Grund hierfür ist, dass man eine Library ohne Source Code einbindet die ihrerseitz eine Library ohne Source Code verwendet.

Also: Lib_A benötigt Lib_B und Lib_B benötigt Lib_C und gleichzeitig haben Lib_B und Lib_C keinen Source Code.

Wenn man jetzt aber in Lib_A nicht nur Use "Lib_B" schreibt sondern zusätzlich auch Use "Lib_C" dann funktioniert es.

Die Fehlermeldung verschwindet.


Problem 2: Bei 'Recompile All Lotus Script' geht der ausführbare Code verloren, falls man den Source Code über das Feld $ScriptLib bzw $AssistAction_Ex gelöscht hat

Gab es das Problem nicht schon immer? Weiß ich nicht, da ich die Felder noch nie gelöscht habe.

Ich weiß nur, dass wenn man schon früher die Felder $ScriptLib bzw $AssistAction_Ex gelöscht hat und anschließend in die Library bzw.

den Agenten gegangen ist und diesen gespeichert hat, so ging der ausführbare Code verloren.

Ist ja auch klar. Kompiliert man einen nicht vorhanden Source Code so erhält man einen ausführbaren Code der nichts macht.

Um dieses zu verhindern, habe ich nicht die Felder gelöscht sondern den Source Code in eine LSS Datei exportiert und ihn anschließend via

%INCLUDE eingebunden. Da dieses aber zu viel Arbeit macht, habe ich einen Agenten geschrieben der die $ScriptLib und $AssistAction_Ex

Felder durch vorgefertigte $ScriptLib und $AssistAction_Ex Felder ersetzt, die ihrerseitz eine nicht vorhandene LSS Datei einbinden.

Speichert der Kunden jetzt eine so behandelte Library bzw Agenten, so wird nicht der ausführbare Code vernichtet sondern aufgrund der

fehlenden LSS-Datei erhält er eine Fehlermeldung.

Im neuen DDE 8 gibt es das Feature 'Enable automatic recompilation of all dependencies'. Kann es sein, dass hierdurch Libraries

kompiliert werden, bei denen der Source Code komplett durch Löschen der Felder entfernt wurde.

So passiert dass, was ich oben als Problem beschrieben habe, wenn der Kunde die Library manuell öffnet und speichert, jetzt

automatisch im Hintergrund. Dann müsste ein %INCLUDE dieses aber auch verhindern.

Jedenfalls kann ich auf meinen Datenbanken 'Recompile All Lotus Script' ausführen, ohne dass etwas kaputt geht.

Mir ist jedenfalls nichts aufgefallen.

[pram]

Hier kann ich auch noch was dazu sagen: Der neue Designer erlaubt ja jetzt das (zwischen)speichern von fehlerhaften code. (Ging mit Tricks beim alten auch schon)

Allerdings speichert er den fehlerhaften Code nun in einem extra Item "$ScriptLib_Error" ab und lässt das $ScriptLib unangetastet. Insbesonders ärgerlich ist wenn man "prompt me on save if there are LotusScript errors" nicht aktiviert hat. Dann editiert man wo rum und drückt CTRL+S und wundert sich, warum die Änderung keine Wirkung zeigt. Bei genauem Hinsehen sieht man dann, dass die Lib einen Fehler hat.

Weitere "lustige" Effekte treten auf, wenn man mit verschieden Designern arbeitet.

Angenommen ich erweitere mit 8.5.1 eine lib und speicher diese zwischen. Da ich noch nicht ganz fertig bin und der Code noch nicht fehlerfrei compiliert, kommen die Änderungen in $ScriptLib_error

Nun kommt ein Kollege und schaut sich meine "Erweiterungen" mit einem 8.0er an. Sieht aber davon nichts weil sein Designer das $ScriptLib_error Item nicht beachtet. Er beginnt ebenfalls etwas zu ändern und speichert. Diese Änderungen landen in $ScriptLib

Öffne ich die lib wieder mit 8.5.1, so sehe ich den Code, der im $scriptLib_error (also meinen letzten Stand) und frage mich, was der Kollege die ganze Zeit gemacht hat 

Nun bessere ich meine letzten Fehler aus und voilà, alles compiliert und wird in das $ScriptLib-Item geschrieben... Die Änderungen, welche in der zwischenzeit mit älteren Designern durchgeführt wurden, sind WEG 

Also ich frage mich, warum sie hier überhaubt die Auftrennung $ScriptLib/$scriptLib_error gemacht haben...

Gruß
Roland

[koehlerbv]

Da ich de facto ausschliesslich mit dem Domino Designer meinen Lebensunterhalt bestreite (und dies auch will), kommt mir der 8.5.1 nicht ins Haus. Ich warte auf den 8.5.3, ich habe auch Zeit, bis zum 8.5.5 zu warten.
Der neue Designer hat ja nicht einfach nur eine neue Versionsnummer, er ist von vorn bis hinten komplett neu gemacht. Das ist ein schwieriger Prozess, für Probleme habe ich vollstes Verständnis . Kein Verständnis habe ich angesichts des Stands der Dinge aber, dass das Teil schon eine Versionsnummer hat - das Ding ist bestenfalls eine Beta-Version. Und damit kann ich keine Kunden bedienen.

Bislang hat uns IBM Lotus aber noch nie (grundlegend) enttäuscht, ich warte also - und das sehr zuversichtlich. Und auf das irgendwann fertige Produkt freue ich mich.

Bernhard

[Legolas]

Hallo Zusammen,

da kann ich mich der Meinung von Bernhard nur anschließen.

Es gibt viele neue schöne Ansätze, die jedoch teilweise noch unausgereift sind.
Zudem habe ich Stabilitätsproblem mit dem 8.5.1 Designer und bekomme mit dem Eclipse Script-Designer Plugin manchmal dubiose Fehlermeldung und muss dann den Designer neu starten.
Ich hoffe da mal auf die kommenden Versionen!


Gruß
Bernd

[dirk_2909]

Hallo Zusammen,

ich wollte euch über die Lösung des Problems Bescheid geben.

IBM hat das Problem gelöst. Ab LN 8.5.2 kann der LotusScript-COde entfernt werden, in dem das Feld $ScriptLib entfernt wird UND ein Feld namens $HideInfo erstellt wird und mit einem Datumswert belegt wird.

Danach lassen sie die so veränderten Libraries im DD 8.5.2 verwenden. Den QuellCode kann man nicht sehen - auch lassen sich die Libraries nicht öffnen. Man kann sie aber in anderen gestaltungselementen verwenden. Der ClassBrowser funktioniert dann auch.

Ich find es super, dass IBM (danke Maureen leland) so schnell auf die Anfrage reagiert hat.