Antwortdokumente automatisch erstellen

[jotha]

Hallo @All,

da ich als neuer User in Euer Forum eingestiegen bin, möchte ich mich erst mal Vorstellen. Mein Name ist Jörg und ich betreue in einem großen Papierkonzern in erster Linie die Datensicherung und die Notes Server. Momentan arbeite ich an einer Datenbank zur Urlaubs- und Resourcenplanung für unsere Abteilung. Und da komme ich schon zu meinem Problem:

Wie kann ich beim Abspeichern eines Hauptdokuments ("PostSave"-Event) automatisch ein Antwortdokument erstellen ohne die Maske zur Bearbeitung durch den User zu öffnen.
Mit "@Command([Compose]; ""; "AntwortMaskenName")" wird ja leider die Maske zur Eingabe geöffnet.

Ach ja: Ich habe die Vorgabe (nach Möglichkeit) nur Formeln (@) zu verwenden

Vielen Dank für Eure Aufmersamkeit. In hoffnungsvoller Erwartung ob der zahlreichen Antworten...

[Axel]

Mit Formelbefehlen kommst du hier nicht weit. Das ganze muss im Backend passieren, da ja der Anwender davon nichts mitbekommen soll. Und Backend ist nur mit Script zu realisieren.

Axel

[umi]

Wer gibt den solche vorgaben?

[jotha]

@Axel: Ich habs fast befürchtet, dann muß ichs mich eben doch in Script lösen. Es hätte ja sein können, daß das Problem schon mal jemand hatte.

@Urs: Mein Cheffe. Die DB sollte möglichst einfach und überschaubar gehalten werden.

[Settler]

Was hat überschaubar und einfach mit der verwendeten Programmiersprache zu tun?
Dein Cheff bekommt normalerweise gar nicht mit was im Hintergrund so alles passiert.

Um eine Scriptlösung wirst du hier wohl nicht herumkommen.

mfg

Benjamin

[jotha]

Hallo nochmal,

also mein Cheffe meinte die DB kann von Anderen einfacher gewartet werden wenn nur Formelsprache verwendet wird. Aber da es ja eh nicht geht habe ich das ganze jetzt doch in LS gelöst.
Da muß Cheffe nun eben durch 

Danke für die Hinweise und dann bis denne...

[Settler]

Naja "nur Formelsprache", so einfach ist die mitunter auch nicht immer...
Wichtig ist aber immer das der Code (egal ob Formel oder LS) gut kommentiert ist und die Aufgabe der Funktion beschrieben wird. So kommt ein anderer Designer besser mit fremden Code zurecht.

Solltest du Hilfe bzgl. Erstellung von Antwortdokumenten per LS brauchen, meld dich

Benjamin

[jotha]

Hi Benjamin,

: Naja "nur Formelsprache", so einfach ist die mitunter auch nicht immer...

Damit hast wohl Recht. :-(

: Solltest du Hilfe bzgl. Erstellung von Antwortdokumenten per LS brauchen, meld dich

Werde ich machen. Aber momentan läufts ganz gut. Ist "nur" noch ein kleines Problem mit den Feldern im Antwortdokument aber sonst passts

Danke für das Angebot. Ich werde darauf zurückgreifen....

[Glombi]

Hier ein Vorschlag, wie es auch in Formelsprache geht:

@Command([ComposeWithReference]; ""; "<Name der Antwortmaske>"; 1);
@Command([FileSave]);
@Command([FileCloseWindow])

Anstelle von
 @Command([ComposeWithReference]; ""; "<Name der Antwortmaske>"; 1);
kann man natürlich auch
@Command([Compose];"<Name der Antwortmaske>");
verwenden.



Welche Option bei ComposeWithReference verwendet werden kann, steht in der Hilfe.
Der Code erzeugt ein Antwortdokument, speichert und schließt es wieder. Der Anwender bekommt davon nichts mit.
Es dürfen natürlich keine Validierungen zuschlagen.
Falls Informationen übernommen werden sollen, kann das über die Vererbung (Maskeneigenschaft) gemacht werden.


Dennoch halte auch ich eine Umsetzung mit Script für wesentlich besser, zumal es sich um das PostSave Event handelt. In solchen Events sollte nur Script programmiert werden.

Andreas

[flaite]

also mein Cheffe meinte die DB kann von Anderen einfacher gewartet werden wenn nur Formelsprache verwendet wird.

Diese Einstellung ist vermutlich nicht besonders smart. Es gibt eben eine Menge Dinge, die sich leichter mit Formelsprache lösen lassen und andere leichter mit LotusScript. Dinge tendieren genau dann unmaintainable zu werden, wenn krampfhaft an einem Werkzeug festgehalten wird, dass dafür nicht geeignet ist.
Ich hab eine Menge größere Datenbanken modernisiert, die mit R3/4 geschrieben worden sind und damals war reiner Formelsprache-Code noch dominierend. Die anzupassen war oft sehr, sehr schwierig.
Programmiersprachen sind eigentlich nur unterschiedliche Perspektiven wie die Inwertsetzung eines Computers verstanden werden kann.
LotusScript ist sehr gut verstanden. Es gibt viel Literatur darüber und für viele VB-Programmierprogrammierer ist es sowieso einfacher als Formelsprache.

Fazit: Die Vorgabe ist mit hoher Wahrscheinlichkeit sowieso nicht zielführend.

[jotha]

@Andreas:

Gute Idee, hatte ich auch versucht, aber beim "PostSaveEvent" mit Problemen verbunden.

@Axel:

Ich gebe Dir vollkommen Recht. Aber diese DB wurde eben mit Formeln angefangen und sollte damit auch zu Ende gebracht werden, damit nicht quer durch den Sprachendschungel programmiert wird.
Mir persönlich ist LS auch lieber, da flexibler und es mir als Pascal- und VB-Jünger wesentlich leichter fällt.

Na, nun denn... Ich habs in LS gelöst. Und meinem Boss wirds wohl keine schlaflosen Nächte bereiten.

[flaite]

damit nicht quer durch den Sprachendschungel programmiert wird.

Ich will hier noch mal kurz insistieren: Ist das nicht eigentlich egal?
Es wurden doch schon immer mit guten Grund Stored Procedues in PL/SQL geschrieben.
Auf der Java Seite:
-eine Menge der Logik von Java Anwendungen steht heute in spezifischen xml-Files und bald in annotations.
-Scripting on-top-of Java wird für die nächsten Releases gepusht.
-Business Rules Engines haben eigene spezialisierte Sprachen.

css und JavaScript sind noch mal völlig eigene Sprachumgebungen (egal was im Backend benutzt wird). Mit Ajax wird Multisprachlichkeit sogar noch weiter gepushed.

Oder das von uns favorisierte Tool für Web-Regressions + Lasttests hat auch eine eigene Skriptsprache. Die ist für die Aufgabe super geeignet und einfach.

Solange es einigermassen rational eingegrenzt ist, welche Sprache für was verwendet wird, sehe ich kein Problem.

Achso: WSDL Files für Webservices beschreiben Services und sind damit auch Programmierartefakte. Auch wieder eine eigene Sprache. Oder auch xslt.

Ich find die Multisprachlichkeit von Notes eher als "modern" an (was immer das heissen mag). Oft wurden die Möglichkeiten falsch angewendet. Aber im Grunde sollte man aus einer Programmiersprache keine Kirche machen.

Gruß Axel