Domino 9 und frühere Versionen > Entwicklung

Wert aus Profildokument im Webbrowser

<< < (3/4) > >>

aoibhneach:
Hallo Forum, hallo Pete(r)!

@pete_bla

Entschuldigung!!! Ich mußte am Freitag dringend los und hatte über's Wochenende keine Internetverbindung. Drum würde ich jetzt gerne fortsetzen.

Der Grund für mich, den Servernamen in die Formel einzutragen ist folgender:
Wenn ich in einem vorhandenen Gliederungspunkt die Formel @GetProfileField() ohne den Servernamen benutze, wird die Gliederung im Webbrowser !!! einfach nicht mehr angezeigt, im entsprechenden Rahmen erscheint dann nur "Seite nicht gefunden..."

Deshalb hatte ich zunächst, und das war auch ein Irrtum, @LocationGetInfo() benutzt, um den Servernamen zu erhalten. Dies ist aber eine lokale Einstellung im Verbindungsdokument, und liefert ggf. einen "falschen" Servernamen zurück.

Der Name des Servers steht im Profildokument...  ^-^

Vielen Dank + Grüße,

Nils

pete_bla:
Hi,


--- Zitat von: aoibhneach am 08.10.07 - 09:25:26 ---Der Name des Servers steht im Profildokument...

--- Ende Zitat ---

genau so habe ich das auch verwendet, insbesondere, wenn ich z.B. einen anderen http-Servernamen hatte. Man musste dann nicht jedesmal im Adressbuch "nachschauen" und eben das Problem mit "" war auch umgangen. (gegebenenfalls musst Du natürlich darauf achten, dass der Eintrag aktualisiert wird, wird aber nicht häufig sein.)

Ich vermute Dein Problem liegt nun daran, dass Du das Profil zuerst mit ProfileKey befüllst, und beim auslesen ohne key eben nichts erhälst, da ohne key ein anderes Profil herangezogen wird.
Also versuch mal das Profil auch ohne ProfileKey zu erstellen.

so schreiben:

--- Code: ---@SetProfileField( ProfileFormname ; fieldname ; value ; ProfileKey )
->
@SetProfileField( "(DBProfile)" ; "Hostname"; "meinserver.de")
--- Ende Code ---

oder so das Profil bearbeiten:

--- Code: ---@Command( [EditProfileDocument] ; ProfileFormname; ProfileKey )
->
@Command( [EditProfileDocument] ; "(DBProfile)")
--- Ende Code ---
und so lesen:

--- Code: ---meinserver:=@GetProfileField( "(DBProfile)" ; "Hostname")
--- Ende Code ---

Für den "Servernamen"/"Hostname" in Deinem Fall ist es ja wirklich nicht notwendig, verschiedene Profile zu pflegen. Also auch ist auch kein ProfileKey notwendig (meine Meinung).

Gruss, Pete(r)

-korrektur: hatte im oberen code einen kleinen fehler-

aoibhneach:
Hallo Pete!

Ja, danke! Ich habe auch nochmals geforscht. Das Problem löse ich jetzt so, dass ich in der Gleiderung einen Eintrag für's Web (nur im Browser angezeigt) und einen  für den Notes-Client.

Vielleicht kann ich Dir die Ursache beschreiben.

Bei Nutzung der Datenbanken im Notesclient hat die in Masken/Gliederungen enthaltene Funktion @LocationGetInfo(HOMESERVER) immer den Namen des Home-/Mailservers der aktuellen Arbeitsumgebung des lokalen Adreßbuchs (des Nutzers) geholt.
Das ist nicht der Name des Servers, auf dem die gesuchten Datenbanken liegen, sondern des für diese Arbeitsumgebung eingetragenen Home-/Mailservers.
Im Web funktioniert das, weil der Notes-Server alles an den Webserver liefert und auch auf das Adreßbuch auf dem Server zugreift.

Ich habe jetzt das versteckte berechnete Feld mit der Funktion @LocationGetInfo aus der Maske genommen. Beim Öffnen im NotesClient meckert Notes nun nicht mehr.
In der Gliederung verwende ich nun die oben erwähnten, wechselseitig sichtbaren Einträge für Web-Browser bzw. Notes-Client.

Nochmals vielen Dank + viele Grüße,

Nils.  :)

aoibhneach:
Hallo Forum!

@pete_bla


--- Zitat von: pete_bla am 08.10.07 - 13:47:13 ---Ich vermute Dein Problem liegt nun daran, dass Du das Profil zuerst mit ProfileKey befüllst, und beim auslesen ohne key eben nichts erhälst, da ohne key ein anderes Profil herangezogen wird.
Also versuch mal das Profil auch ohne ProfileKey zu erstellen.

--- Ende Zitat ---

Genau das war es. Das spezielle Profildokument in allen Datenbanken wurde mit dem Namen des Servers als Key angelegt.
Im Web soll dieses Profildokument wieder ausgelesen werden. Dafür habe ich als 3. Parameter in @GetProfileField() den Servernamen angegeben.
Ich hatte geglaubt, diesen auch im Web mittels
servername := @Name(@Subset(@DbName;1)) ermitteln zu können.
Im Web ist dann aber servername leer! Dadurch wurde mit @GetProfileField ein Profildokument gesucht, welches ohne Key angelegt wurde, also das allgemeine - und natürlich nicht gefunden.

Es ist zwar nicht schön, aber ich hätte nur zwei Lösungen:

1. Erzeugen eines neuen Profildokuments, ohne key. Das erforderte aber das Durchforsten des gesamten Codes aller Datenbanken.

2. Einfach Einfügen eines versteckten Feldes in die entsprechenden Masken, welches den Servernamen "fest verdrahtet" enthält. Dann könnte der key (und damit alle, in den DB'n verwendeten Funktionen) und damit das bestehende Profildokument weiter verwendet werden.

---->>> Gibt es eine bessere Lösung???  ???

Vielen Dank und Grüße,

Nils.

pete_bla:
Hi,

die drei zwei Möglichkeiten hätte ich Dir noch (spontan), um das "im Code Fest Verdatete" mit dem Server zu umgehen:

1. Du verwendest noch ein Profildokument, ohne ProfileKey, nur mit dem Feld "ServerName", trägst dort den @Subset(@DBName;1) mit Notes ein (z.B durch bei der Konfiguration oder einem periodischen Agenten ect.)
und im Web kannst Du ja ohne ProfileKey dieses auslesen und hast den aktuellen ServerNamen, womit du wiederum das Profildokument holst.

2. im Web die CGI-Variable

--- Zitat ---DesingerHelp: Table of CGI variable names
"Server_Name"
   The server's host name, DNS alias, or IP address as it would appear in self-referencing URLs.

--- Ende Zitat ---
einfach ein zur Anzeige berechnetes Feld mit der Variable als Wert.
Dies hat aber das Problem, dass der Hostname = Notes-Name des Servers sein Muss und, dass User nicht über die IP-Adresse auf die Web Seite gelangen sollten, da dann diese gemeldet wird.

3. notessession.GetEnvironmentString( "ServerName" , true )
fällt aber wegen dem WebQueryopen aus (wird relativ zu umständlich)
und mit @Environment( "ServerName") geht das leider nicht, da sie nur $ServerName ausliest.

Ohne Änderung würde für mich nur noch das mit dem zweiten Profil
als Alernative in Frage kommen.

Gruss, Pete(r)

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete