Domino 9 und frühere Versionen > ND6: Entwicklung

Web Navigation, Pfad des Benutzers aufzeichnen

(1/3) > >>

Thomas Schulte:
Ich bin jetzt nicht so der Web Entwickler, deswegen stellt sich das Problem für mich wohl komplexer dar als es eigentlich ist.

Das Ganze ist bis jetzt so realisiert, das ich ein verstecktes Frame mit einem Document habe in das ich beim onload Event des Documentes Daten in dieser Form einstelle:
top.fsaNavigatorHeader.document._frmNavigatorHeader.LocationHrefSave.value = location.href;
und beim Speichern bzw. beim Abbruch innerhalb eines Dokuments wird dieser Wert dann wieder ausgelesen und nach n Sekunden angesteuert.
Onload der Return Form:
TimerID = setTimeout("NextStep() ",1000)
jsHeader der Return Form:
function NextStep() {
location.href = parent.fsaNavigatorHeader.document._frmNavigatorHeader.LocationHrefSave.value;
}
Das funktioniert so nur mit einem Dokument, bzw. nur ausgehend von der Basisview so das der Benutzer auf diese View zurückkommt.

Haben will ich aber folgendes:
Wenn ein Benutzer in der Datenbank im Web sich ausgehend von einer Ansicht in ein Hauptdokument und dann in verschiedene, beliebig tief gestaffelte Unterdokumente klickt, dann irgendetwas ändert, Speichert und schließt oder die Bearbeitung abbricht, soll er eine Auswahlliste bekommen in der alle seine bisherigen Steps aufgezeichnet und ihm als Link zur Verfügung gestellt werden.
Nach Möglichkeit mit sprechenden Namen für jedes Dokument (Formname und noch andere Felder wenn gewünscht) und das als unterschiedliche Links im Return Dokument.
Frage 1: Wie bekomme ich das hin, das beim Onload der Wert für dieses Feld im versteckten Frame ergänzt und nicht überschrieben wird.
Frage 2: Wie kann ich beim Laden der Return Dokumentes die Daten auslesen und entsprechend strukturiert darstellen.

Thomas

Marinero Atlántico:
Hi,

das hört sich aber nicht so einfach an. Vielleicht verstehe ich es auch nicht richtig.
Ich würd auch spätestens bei diesen Requirements intensiv darüber nachdenken, kein Frameset zu benutzen.
Ohne Frameset wird es einfacher Aktionen aufzuzeichnen, da jede Aktion eine eindeutige URL hat.

Ansonsten würde ich diese Aktionen auch eher im Backend speichern, als sie in irgendwelchen html-Feldern mitzuschleppen.

Alternative zu einem versteckten Feld sind noch cookies. Da hast du natürlich keine "Mehrfachwertefelder", aber du kannst ein Trennzeichen verwenden.

Für mich sieht das aber grundsätzlich so aus als würdest du den Weblayer mit Business-Logik überfrachten. Das endet meiner Ansicht nach nie gut. Ich war mal - für Notes-Entwickler-Verhältnisse- ein ziemlich guter JavaScript Hacker.
Sobald du aber mit sowas wie asynchronen setTimeout, etc. arbeitest, würde ich wie gesagt ernsthaft darüber nachdenken, Funktionalität in das Backend zu verlagern.

Der Notes-Client ist für eine 2-tier Architektur gebaut. Der Browser hingegen eigentlich für eine 3-Tier-Architektur, d.h. alle Funktionalität, die nicht unmittelbar der Darstellung fürs Web dienen ins Backend tun, oder du weisst sehr ganz genau, was du tust.
-
Gruß Axel

Marinero Atlántico:
2-Tier: Sowas wie an clients deployte vb- oder c++ clients, die eine Menge Business Logic enthalten und die mit z.B. einen Datenbankserver kommunizieren.
3-Tier: Es kommt eine 3. Komponente auf einem Server in der Mitte ins Spiel, auf der die ganze Business-Logik hält, die sich mit Ressourcen (wie z.B. einem Datenbankserver) verbindet, für Security und Transaktionen, etc. verantwortlich ist.

Vanilla-Notes-Anwendungen ist eigentlich eher 2 Tier. Der meiste code, der von Userinteraktion ausgelöst wird, wird auf dem Client ausgeführt (Agenten, Formeln, Masken-Events).
Bei Notes-Web ist das ein bischen anders. Der Web-Query-Save Agent wird zum Beispiel auf dem Server ausgeführt. D.h. auch Iris tut Business Logik weg vom Client hin zum Server.

Man kann jetzt natürlich versuchen mit JavaScript einen business-intelligenten Client zu schreiben. Dafür ist aber JavaScript gar nicht ausgelegt.

Das Problem bei Framesets besteht darin, dass dies eigentlich nur ein paar äusserst lose gekoppelte eigene Browserfenster sind. Wie du vielleicht schon gemerkt hast, ist es nicht leicht, diese Einzel-Mini-Browserfenster dazu zu bewegen wie eine Anwendung zu agieren.
Weitere Probleme: Back-Button, Status-Information in hidden-fields, Cookies, etc.

Gruß Axel 
 

animate:
Mein erster Gedanke war auch Backend

Aber soweit ich das verstanden habe, ist es schwierig, im Backend was zu machen, da die Navigation über Links erfolgt und damit kein submit da ist.

Ist es möglich, im WebQueryOpen den Referrer zu ermitteln? Wenn ja, dann dürfte das recht einfach sein. Ich müsste dazu halt in einer Art Stack alle Referrer speichern, anzeigen und nach und nach wieder abtragen.

Oder?

Timer - Geschichten und versteckte Frames halte ich für abenteuerlich.

animate:
Breadcrumbs heißt das übrigens im Fachjargon, was du da vorhast.

Dazu gibts einen kleinen Beitrag bei codestore.net.
Vielleicht steht in den Kommentaren ja was hilfreiches

http://www.codestore.net/store.nsf/unid/BLOG-20040723/

Navigation

[0] Themen-Index

[#] Nächste Seite