Formeln im Web

[ERVO]

Hallo Forum,

ich habe eine Schaltfläche hinter der sich folgende Formel verbirgt:

@SetField( "Tat_rueckgabe"; @Today);
@SetDocField( BuchID; "status"; "0");
@SetDocField( BuchID; "AusleihDatum"; "" );

In Notes Client funktioniert das, aber im Web werden zwar die Werte gesetzt aber nicht gespeichert. Die beiden unteren werden ohne Probleme ausgeführt, aber die Felder im angezeigten Dokument werden nicht gesetz. hab versucht das mit den Befehlen "EditDocument" und "FileSave" einzurahmen, hat aber nichts gebracht.

Hat jemand eine Idee woran es liegen könnte?

Grüsse Eric

[flaite]

Du kannst diese Werte über Script im WebQuerySave Agenten füllen. So geht das natürlich nicht.
Das Client-Server Kommunikationsmodell zwischen Notes-Client->Domino-Server und Web-Browser->Domino-Server sind völlig unterschiedlich.
Das erste basiert auf Remote Procedure Call und das grobgranularere und unflexiblere Webmodell auf Request-Respone auf Basis des Http Protokolls (weitgehend immer http-get und http-post).
Theoretisch ist sowas mit dem neuen Ajax Programmiermodell möglich, aber ich würds echt mit WebquerySave versuchen. Du speicherst die ID des BuchID Docs im Dokument, liest dies im WebquerySave aus, holst dir mit der ID das Dokument, führst die Änderungen durch und speicherst das Dokument.
Geht mit Formelsprache oder Skript, wobei ich hier wirklich dringend Skript empfehle.


Axel

[Thomator]

Hallo,

alternativ kannst Du dich auch der JavaScript-Ereignisse des Dokuments bedienen.

Bei einem @Command([FileSave]) in einer Schaltfläche können über das onSubmit-Ereignis die Werte auch noch gesetzt werden.

Ist evtl. etwas unkomlizierter als ein WebQerySave-Agent.
Aber eben immer Geschmacksfrage.

Nach meiner Erfahrung sind @SetField und @SetDocField im Web nicht unbedingt zuverlässig.

Thomas

[flaite]

Ich glaub, dass sich die Felder "status" und "Ausleihdatum" in einem anderen Dokument als dem gerade im Browser sichtbaren gesetzt werden müssen, oder?
Zumindest ist der 1. Parameter der 3 Parameter von z.B. @SetDocField( BuchID; "status"; "0"); ein Indiz dafür.
In Sachen Kristallkugel-Lesen bekommt man hier natürlicherweise eine gewisse Übung, hehe. Es ist auch für die Fragensteller sicher nicht einfach zu wissen, welche Kontextinfo in welchem Maß relevant ist.
Das geht nicht über JavaScript, es sei denn über Ajax, aber das ist a) komplex und würde b) in diesem Fall wenig Sinn machen.
JavaScript eigenet sich gut um Felder im gerade sichtbaren zu setzen.

Axel

[ERVO]

Ich glaub, dass sich die Felder "status" und "Ausleihdatum" in einem anderen Dokument als dem gerade im Browser sichtbaren gesetzt werden müssen, oder?

So isses! Die Befehle gehen auch, nur das aktuell zum Lesen geöffente Dokument läst sich nicht ändern :-(

Vieleicht noch mal zum Kontext:
Die Ausleihe wird mit @Command([Compose];...) angelegt, dort kann man auch mit @SetField arbeiten. Aber wenn es zurückgegeben wird, will ich ja das Dokument nicht bearbeiten, sondern nur per Schaltfläche @today als Wert für die tatsächliche Rückgabe setzen.

Wenn ich mit WebQuerySave arbeite, muss ich das Dokument dafür Speichern?

Ich hab´s jetzt anders gemacht:
Ein Schaltfläche "zurückgeben", die das Dokument in den Editier-Modus bringt, und dort eine , die die Felder setzt und speichert. Dabei kann man auch noch Bemerkungen erfassen.

Danke
Eric

[flaite]

Die ganze Webgeschichte wird imho transparenter, wenn man sich mal angeschaut hat, was ein Webbrowser an einen Server sendet.
Was der Webserver an den Browser sendet sieht man ja im Source Code im Browser.
Nur eben die umgekehrte Kommunikation --> d.h. Browser an Webserver <-- ist ohne Zusatztools nicht so richtig transparent.
Man kann das bei Domino mit Bauchschmerzen mit einem Tool in dem Webservice Paket jakarta.axis machen (TCPMon hiess das glaub ich).
Dieses Ding kann man als Proxy für ein-und ausgehende HTTP-Calls verwenden.
Es braucht aber einen eigenen Port.
Bsp:
1. Die Links und Posts von Webseiten aus einer Webanwendung sind eingestellt auf Port 8081 zu schicken.
2. Auf Port 8081 (Beispiel) wartet TCPMon. Er zeigt an, was der Browser geschickt hat und leitet es an den Port des Webservers weiter (z.B. Port 80 oder 8080). Ausserdem zeigt TCPMon an, was vom Browser geschickt wurde, weil eben auch das Zeug, was der Webserver an den Browser sendet über TCPmon geht. TCPmon ist der Proxy.
Das Teil ist Bestandteil eines Webservices Paket. Für das debuggen von Webservices kann das sehr sinnvoll sein. Verständnis von http hilft auch bei Webservices, da http gerne als Transportprotokoll derselben eingesetzt wird.

Ich weiss nicht so recht wie ich in einer Domino Anwendung einstellen kann, dass alle Post Requests und alle Get-Requests gegen einen anderen Port gehen als auf dem der Domino Server horcht. Wenn jemand mir kurz erklären kann wie das geht (ausser, man macht es händisch), erkläre ich wie man TCPMon ans Laufen kriegt (man braucht nur ein Java JDK1.4 und axis).
Vielleicht gibt es aber wie gesagt auch einfachere Wege.

Gruß Axel

Vielleicht weiss jemand wie man das irgendwie über TCP-Sniffer geht.