Das Notes Forum
Domino 9 und frühere Versionen => ND6: Entwicklung => Thema gestartet von: CLI_Andreas_Schmidt am 28.07.05 - 11:01:08
-
Hi @all,
Im IE.x kann man in den Eigenschaften einstellen "Refresh bei jedem Zugriff auf die Seite". Jetzt möchte ich dieses Einstellung aber nicht global einstellen, weil es ja nicht für jede Webseine Sinn macht. Kann man das auch auf eine Seite im Header hinterlegen ?
-
Mit dem Meta TAg refresh auf die aktuelle URL sollte es funktionieren.
gruss
umi
-
Läuft leider nicht.
Es gibt zwar einen Refresh, aber leider werden die Inhalte nicht erneuert.
Was passiert: Ich habe eine eingebettete Ansicht. Diese Wird im Backend neu geschrieben (mit selben Namen - CreateView). Im Browser soll jetzt der neue Inhalt geladen werden. Leider geht das nur, wenn im Browser die Einstellung "refresh bei jedem Zugriff" angeklickt ist. Tja und nun ?
Wenn ich den Meta Tag Refresh benutze, dann refresh er die alten Ansichtsinhalte und läd nicht die neue.
-
Ich denke das refresh hilft dir da nicht weiter du solltest das hier verwenden:
<meta http-equiv="cache-control" content="no-cache">
Anweisung an den Browser: keinen Cache benutzen, sondern von Originalseite laden.
Robert
-
Es kann sein, dass es auf der Notes Seite gecached wird den von Andreas genannten Einstellungen.
Der Browser Cache, die zwischen Browser liegende Server und das caching auf Notes sind alles voneinander unabhängige caches.
Der Notes Ansichts-Aufbau-Cache wird imho nicht durch http-meta-tags beeinflusst.
(obwohl das eigentlich eine gutes Feature wäre).
@Andreas: Bist du sicher, dass du dieses CreateView Zeugs *wirklich* brauchst?
Axel
-
Der Metatag <meta http-equiv="expires" content="0"> erzwingt das erneute laden der Seite.
LG
-
@Maschina: Aber meines Wissens nicht das Neuladen der ANSICHT auf Notes-Seite.
-
Ich hab hier noch einen Betrag vom Forum gefunden.
http://www.atnotes.de/index.php?topic=22096.0
Geht um fast das gleiche!
Robert
-
Aber es gibt doch die Einstellung in Ansicht:
- Index nach jedem Aufruf verwerfen
- Index nach der und der Zeit verwerfen
Ich hab den Verdacht, dass das hier Auswirkungen hat. Va. weil Andreas nach meiner Einschätzung mit einem dynamischen Ansichtsformel-Zeugs rumexperimentiert, was imho eh nicht skallliert.
Axel
-
Erst mal vielen Dank für die Hilfe.
Zu. "kennwort"--> jupp brauche ich. Ich habe auf einer Web-Maske viele Auswahlfelder und generiere mir dann eine Ansicht im Backend die genau der Selektion entspricht. Klassische Abfrage für eine RDMS - Datenbank.
Zu. "macchina "
Dein Lösung war die Lösung. Vielen Dank. läuft.
Alle Anderen.
Danke.
-
Wärs da nicht einfacher mit der Selektion ein db.search zu machen und dann aus der DocumentCollection den HTML Code für die Ansicht zu generieren oder ist Ansicht zu komplex?
gruss
umi
-
Die Idee wäre auch gut. Die Geschichte läuft jedoch bereits mehr mals wie beschrieben. Dein Ansatz wäre wohl etwas performanter. Aber die Methode CreateView läuft super.
Gruss
Andreas.
-
Bis auf den refresh ;)
-
Zu. "kennwort"--> jupp brauche ich. Ich habe auf einer Web-Maske viele Auswahlfelder und generiere mir dann eine Ansicht im Backend die genau der Selektion entspricht. Klassische Abfrage für eine RDMS - Datenbank.
Sehe das anders. In RDBMS Programmierung gibt es sehr viele Mittel, um die Queries hinsichtlich Latenzzeiten zu tunen. Und für wirklich hartnäckigere Fälle existieren caching Produkte/ wohlbekannte Patterns.
Mich würde wirklich interessieren, wie groß die Latenzzeit dieser dynamischen Ansichtsabfragen werden, wenn - sagen wir - 10 User gleichzeitig auf die besagte view zugrifen. Eben die Skallierbarkeit. Wie reagiert dieses Feature auf eine wachsende User-Population?
Axel
-
Die Funktionen sind rein 4 Personen überlassen. Das heißt hier wird keine Performance-Problem auftreten. Wenn natürlich 10 - 20 Personen gleichzeitig den Agenten laufen lassen, dann könnte es zu Problemen führen. Aber das wird nicht der Fall sein.
-
Hallo Andreas,
also Deine Anwendung interssiert mich ja wirklich hochgradig.
Was Du da schreibst, würde ich gerne besser verstehen, ich kann's mir nämlich beim besten Willen nicht vorstellen, wie das gehen soll bzw. wie Du das gelöst hast.
Wenn ich Dich richtig verstehe,
hast Du eine embedded view, das hieße, diese Ansicht hat einen festen Namen.
Wann immer jetzt ein Benutzer eine Abfrage erstellt, wird diese Ansicht über Script (CreateView) vom Design her neu erstellt und angezeigt.
1)
Wie lange dauert sowas ?
Wenn ich das bei einer Datenbank mit mickrigen 3.000 Datensätzen mal kurz ausprobierte, dauerte so eine Web-Abfrage bei mir auf einem schnellen Webserver über 30 Sekunden. Und die Ansicht war sehr einfach aufgebaut.
2)
Was passiert denn, wenn zwei Benutzer diese Abfrage gleichzeitig oder kurz nacheinander machen? Dann ist doch der Server möglicherweise mit dem Neu-Indizieren nach der ersten Abfrage noch gar nicht fertig und soll schon wieder die Ansicht umbauen. Bekommt dann nicht Benutzer "A" möglicherweise das Ergebnis der Abfrage von Benutzer "B"?
3)
Was passiert, wenn ein Benutzer "A" diese Ansicht nach seiner Abfrage angezeigt bekommt, und ein anderer Benutzer "B" über eine eigene Abfrage, die gleiche Ansicht schon wieder vom Design geändert hat. Wenn jetzt der Benutzer "A" ein Dokument oder eine Kategorie in der Ansicht anklickt, z.B. um diese zu öffnen, dann ist doch eigentlich die Ansicht schon wieder anders und der Link funktioniert doch gar nicht?
Also ich habe auch schon mit dieser CreateView-Geschichte experimentiert, kam aber wegen solcher Fragen zu keinem brauchbaren Ergebnis.
Wie sehen Deine Erfahrungen zu diesen Fragen aus?
Aber sag bitte bitte nicht, dass Du eine Anwendung baust, wo immer nur ein Benutzer gleichzeitig damit arbeiten darf.
Gruß,
Uwe
-
I second Uwe.
Ohne jetzt als Überbringer der schlechten Nachricht/Bedenkenträger erschlagen werden zu wollen.
Geht genau in meine Richtung. Auch wenn das vielleicht relativ einfach zu programmieren ist. Wie sieht das dann in der Runtime aus?
Viele Dinge in Webservices und EJB sahen erstmal von der Programmierung als geniale Lösungen für Probleme aus. In der Praxis stellten sie sich aber als unbrauchbar heraus, weil es einfach in der Runtime dermassen ineffizient und Ressourcen-fressend war, so dass ein neuer Ansatz gesucht werden mußte.
-
2)
Was passiert denn, wenn zwei Benutzer diese Abfrage gleichzeitig oder kurz nacheinander machen? Dann ist doch der Server möglicherweise mit dem Neu-Indizieren nach der ersten Abfrage noch gar nicht fertig und soll schon wieder die Ansicht umbauen. Bekommt dann nicht Benutzer "A" möglicherweise das Ergebnis der Abfrage von Benutzer "B"?
Rein spekulativ: Ich würde vermuten, dass es sich um 2 unterschiedliche Kopien handelt, so dass keine Konsistenzprobleme zu erwarten wären. Das Problem mit der hohen Ressourcenbelastung bleibt. Wenn dieses generierte Design auch noch irgendwie zwischen 2 Clients geteilt würde, fände ich es richtig krass.
3)
wie 2.
-
zu Datenbank24.
Du hast es genau widergegeben, wie es hier läuft. Ein gleichzeitiger Zugriff ist wie gesagt recht unwahrscheinlich in dieser Umgebung. Ich habe es getestet, wenn zwei Personen hintereinander auf den Knopf drücken. Nix passiert, alles OK. Der Browser hält die Ansicht bei Klick A und wenn klick B durchgeführt wird, dann wird die Ansicht im Designer gelöscht und eine neue Erstellt die dann an den Browser B gesendet wird. Läuft recht gut und auch gar nicht so langsam. Ich habe hier eine Datenbank mit 12000 Dokumenten. Verzögerung 5-6 Sekunden.
Ist noch in der Tolleranzgrenze. Wenn ich an Probleme stosse, dann werde ich weiter Posten.
Gruss
Andreas
-
Danke Andreas,
alles sehr interessant.
Ich muß das demnächst auch einfach noch mal ausprobieren.
Das die Neu-Indizierung bei 12.000 Dokmenten SO schnell geht, hätte ich nicht gedacht.
Gruß,
UWE (!)
-
Ich würde hier auch noch den View-Cache des Domino-Servers in Betracht ziehen. Der wird es garantiert nicht lustig finden, wenn dort nicht allmählich hinzugefügt, sondern permanent zerstört und neugebaut wird.
Ich würde das Verfahren mit "CreateView" immer als Anti-Beispiel guter Programmierung sehen. Und für mich als Programmierer käme auch nie in Frage, auf einen vagen Ist-Zustand zu bauen (x User, y Parallelzugriffe sind nur denkbar). Den unbeschrankten Bahnübergang passiere ich auch nicht nach dem Motto "In den letzten Wochen kam hier auch niemals ein Zug, als ich gerade da war.".
Bernhard