Web Navigation, Pfad des Benutzers aufzeichnen

[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/

[Thomas Schulte]

@thomas
ja und Nein Den Artikel kenne ich schon und da steht eigentlich nichts drin was mir weiterhilft.
@marinero
Nee, Business Logic ist in dem Weblayer definitiv nicht drin. Hier geht es ausschließlich um Navigation, die wie schon pompeius sagte "necesse est".

Das mit dem Hidden Frame ist zwar nur eine Krücke aber in dieser Umgebung eigentlich völlig egal.
Einzelne Moves des Users zur Laufzeit in den Frame reinzubekommen habe ich auch schon gelöst. D.h. wenn der Benutzer ein Dokument öffnet dann zechnet der Client den Absprungpunkt in der View und das Dokument das geladen wird auf und ich kriege auch einen automatischen "Return to that point of View" hin. Aber was ich noch nicht fertiggebracht habe, ist dem $$Return Dokument zu sagen, pass auf hier sind zwei Felder, eines mit einem View link und eines mit einem Array von Werten die deine verschiedenen Stationen seit dem du den View verlassen hast darstellen, mach da doch mal lauter Links draus die der Benutzer anklicken kann so das er an eine beliebige Stelle seinen Arbeitsablaufes zurückspringen kann.
Ach Ja und das mit dem Array muss ich auch noch lösen und Strukturieren muss ich die Daten auch noch so das sich zum Bleistift der Benutzer an seinen 4.ten Event zurückbeamt, von da aus weitermacht und dann wieder den 1-4 und alle neuen Events angezeigt bekommt, wenn er dann sein neues Dokument speichert.

Sch... Spiel

Thomas

[animate]

hmm, also ich finde, da ist eine Menge Logik drin, auch wenn du gegenteiliger Meinung bist.

Wenn ich diese Problemstellung hätte, würde ich im Backend für jede Session eines Benutzers seine Navigation mitverfolgen (vermutlich mit Hilfe von http_referrer) und in der Datenbank speichern.
Diese gespeicherten Daten würde ich in jedem Dokument, das der Benutzer öffnet anzeigen (in einem berechneten Feld des Dokuments, nicht in einem Frame), und zwar als Breadcrumbs.

Das Verfolgen der Naviagtion und das Bereitstellen der richtigen + notwendigen Linkinformationen in jedem Dokument ist die von Axel genannte Business Logic.

[animate]

also zumindest wäre das mein Lösungsansatz.
Kann nicht sagen, ob das so funktionieren wird

[Thomas Schulte]

OK bis zu einem ersten Step bin ich jetzt schon einmal gekommen. Das hier funktioniert soweit, das er sich jeweils den Absprungpunkt in der View merkt und das jeweils letze geöffnete Dokument und dann über Links jeweils zurückspringen kann:
Im $$Return Dokument:
<H1>Bitte wählen sie in den nächsten 60 Sekunden aus den verfügbaren Links aus wohin sie zurückspringen wollen.</H1>
<br><br>
Sonst werden sie an ihren Ausgangspunkt zurückgeleitet.
<br><br>
<a href="javascript:ShowBaseView();">Ursprungsansicht</a>
<br><br>
<a href="javascript:ShowDocument();">Dokument von dem du kommst</a>
In JS Header des  $4Return Dokumentes:
function NextStep() {
location.href = parent.fsaNavigatorHeader.document._frmNavigatorHeader.LocationHrefSave.value;
}
function ShowBaseView() {
location.href = parent.fsaNavigatorHeader.document._frmNavigatorHeader.LocationHrefSave.value;
}
function ShowDocument() {
location.href = parent.fsaNavigatorHeader.document._frmNavigatorHeader.DocumentHrefSave.value;
}
In Onload Event des $$Return Dokumentes:
TimerID = setTimeout("NextStep() ",60000)
Und im ViewTemplate beim Onload:
top.fsaNavigatorHeader.document._frmNavigatorHeader.LocationHrefSave.value = location.href;
In den Masken beim Onload ebenfalls den entsprechenden Wert, nur halt in ein anderes Feld eintragen
top.fsaNavigatorHeader.document._frmNavigatorHeader.DocumentHrefSave.value = location.href;

Nächster Schritt: Jetzt muss noch der Name der Ursprungsansicht irgendwie gespeichert werden und der Name des Dokumentes. damit die Links komplett "dynamisch" werden und dann noch den Pfad der Dokumente aufzeichnen.

Thomas

[Marinero Atlántico]

Zuerst mal must du wohl das Feld dazu bringen irgendwie Mehrfachwerte zu speichern und eine Menge mehr...

Das ist eine komplexe Aufgabe für ein Webprojekt. Bedenke v.a. das back und forward buttons im Browser das ganze ziemlich komplizieren können.
Ohne deine Requirements vollständig verstanden zu haben, würde ich trotzdem versuchen die Navigations- und sonstigen Aktivitäten des Users in Backend Notes-Dokumenten zu speichern, obwohl dies sich sicherlich auf den memory footprint der Anwendung sowie die Responsivität auswirken wird (beides Performance-Themen).

Gruß Axel

[Thomas Schulte]

und es geht doch. Noch nicht ganz fertig, so fehlt zum Bleistift das Entfernen des unteren Teiles des Zugriffspfades, Names Lookups und ein vernünftiger Date Picker aber grundsätzlich funktioniert das doch (zumindest im IE, im Firefox mögen weder die Navigationsapplets laufen noch kriegt er die Navigation richtig hin).

Thomas

[animate]

oh, sehr schönes Beispiel zum Thema breadcrumbs hier

Ohne Frames, einfach wiederverwendbar

[Thomas Schulte]

Ist wirklich ein schönes Beispiel aber, was machst du wenn du mehr als fünf Level hast, oder wenn der Benutzer nicht bei Level 0 einsteigt sondern bei Level 8, sich dann rückwärts auf ein basisdokument zubewegt, dann abbricht und sich aus der Liste der Dokumente die er bisher besucht hat ein anderes aussucht und von da aus wieder über die  diesem Dokument untergeordneten Dokumente nach oben geht?

Alle Beispiele die ich bis jetzt gesehen habe gehen von einer "geordneten" Vorgehensweise des Benutzers aus und alle fangen beim "Level0" an und bewegen sich nur innerhalb der Unterpfade dieses Levels.

Thomas

[animate]

hmm, das ist mir jetzt etwas zu wirr, um mir das vorzustellen
aber das mit den Levels in dem Beispiel würde ich nicht so eng sehen. Das wichtige ist, dass du alle Schritte des Benutzers aufzeichnest und ihm als Navigationspunkte anbietest. Dann kann der noch so ungeordner rumnavigieren.
Das, was mir an dem Beispiel besonders gut gefallen hat ist eigentlich, dass es keine Frames verwendet Und diese Listentransformation.

Naja, seis drum. Du bist zufrieden mit deiner Lösung, also is ja alles gut.