Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.comm.software.mozilla.browser > #52808 > unrolled thread

Caching usw.

Back to article view | Back to de.comm.software.mozilla.browser

Contents

  Caching usw. Lothar Geyer <lothar.geyer@edv-berater-online.de> - 2018-04-21 14:27 +0200
    Re: Caching usw. Lothar Geyer <lothar.geyer@edv-berater-online.de> - 2018-04-22 14:08 +0200
    Re: Caching usw. Arno Welzel <usenet@arnowelzel.de> - 2018-04-22 14:28 +0200
      Re: Caching usw. Lothar Geyer <lothar.geyer@edv-berater-online.de> - 2018-04-24 07:44 +0200
        Re: Caching usw. Arno Welzel <usenet@arnowelzel.de> - 2018-04-27 01:51 +0200
        Re: Caching usw. Arno Welzel <usenet@arnowelzel.de> - 2018-04-27 01:53 +0200
          Re: Caching usw. Lothar Geyer <lothar.geyer@edv-berater-online.de> - 2018-04-27 05:38 +0200
            Re: Caching usw. Arno Welzel <usenet@arnowelzel.de> - 2018-04-27 20:54 +0200
              Re: Caching usw. Lothar Geyer <lothar.geyer@edv-berater-online.de> - 2018-05-02 09:01 +0200
                Re: Caching usw. usenetf2018.fwnsp@spamgourmet.com (Friedhelm Waitzmann) - 2018-05-02 14:42 +0000
                  Re: Caching usw. Lothar Geyer <lothar.geyer@edv-berater-online.de> - 2018-05-02 19:25 +0200
                    Re: Caching usw. Heiko Rost <heiko.rost@gmx.de> - 2018-05-02 20:03 +0200
                      Re: Caching usw. Lothar Geyer <lothar.geyer@edv-berater-online.de> - 2018-05-03 09:43 +0200
                    Re: Caching usw. usenetf2018.fwnsp@spamgourmet.com (Friedhelm Waitzmann) - 2018-05-05 22:15 +0000
                    Re: Caching usw. Arno Welzel <usenet@arnowelzel.de> - 2018-05-12 23:13 +0200
                      Re: Caching usw. Lothar Geyer <lothar.geyer@edv-berater-online.de> - 2018-05-13 13:47 +0200
                Re: Caching usw. Arno Welzel <usenet@arnowelzel.de> - 2018-05-12 23:09 +0200
                  Re: Caching usw. Lothar Geyer <lothar.geyer@edv-berater-online.de> - 2018-05-13 13:56 +0200
                    Re: Caching usw. Maik Koenig <usenetspam@maikkoenig.de> - 2018-05-13 15:03 +0200
                      Re: Caching usw. Arno Welzel <usenet@arnowelzel.de> - 2018-05-13 15:59 +0200
                        Re: Caching usw. Maik Koenig <usenetspam@maikkoenig.de> - 2018-05-13 17:35 +0200
                          Re: Caching usw. Arno Welzel <usenet@arnowelzel.de> - 2018-05-13 18:55 +0200
                            Re: Caching usw. Maik Koenig <usenetspam@maikkoenig.de> - 2018-05-13 20:00 +0200
                              Re: Caching usw. Arno Welzel <usenet@arnowelzel.de> - 2018-05-15 00:43 +0200
                              Re: Caching usw. Lothar Geyer <lothar.geyer@edv-berater-online.de> - 2018-05-17 07:50 +0200
                                Re: Caching usw. Maik Koenig <usenetspam@maikkoenig.de> - 2018-05-17 12:30 +0200
                                  Re: Caching usw. Erwin Penn <penn.er@unterderbruecke.de> - 2018-05-17 13:24 +0200
                                  Re: Caching usw. Christoph 'Mehdorn' Weber <spam-fuer@das-mehdorn.de> - 2018-05-17 17:16 +0200
                                    Re: Caching usw. Lothar Geyer <lothar.geyer@edv-berater-online.de> - 2018-06-10 13:00 +0200
                            Re: Caching usw. Heiko Rost <heiko.rost@gmx.de> - 2018-05-13 20:17 +0200

Page 2 of 2 — ← Prev page 1 [2]

#52987

Am 13.05.2018 um 15:59 schrieb Arno Welzel:
> Maik Koenig:
> 
>> Am 13.05.2018 um 13:56 schrieb Lothar Geyer:
>> 
>>> Also ist jeder Zeitraum abgedeckt und der Wechsel der Anzeige erfolgt 
>>> über meta refresh automatisch. Ist ja auch nur interessant, wenn jemand 
>>> den Tab mit der Seite offen lässt. Ansonsten wird je sowieso neu geladen.
>> 
>> Ich lese jetzt nicht den ganzen Thread, aber warum über Meta Refresh?
>> JavaScript dürfte das doch deutlich einfacher machen.
> 
> Nö - denn das erfordert JavaScript. Ein Meta Refresh geht auch ohne
> JavaScript. Deswegen halte ich es ja für fragwürdig, weil der Benutzer
> das automatische Neuladen der Seite nicht verhindern kann.

Naja, das dürfte nur bei mobilen Anschlüssen ein relatives Problem sein,
weil da unnötig Datenvolumen verschwendet wird.

Ich bin ja auch kein riesiger Fan von JavaScript, aber sowas würde ich
definitiv mit JS lösen. Es ist ein leichtes abhängig von der Uhrzeit die
Texte anzupassen.

Aber ehrlich gesagt: Wenn Nutzer nicht fähig ist so zu erinnern, dass
der Tab schon seit zig Minuten offen ist und daher die aktuellen Angaben
nicht mehr passen könnten... bzw er nicht auf die Uhr schaut um zu
merken dass der Laden längst dicht ist; naja.

Greetz,
MK
-- 
Kopp-Verlag-Gläubige, Religionsdeppen, rechte Vollidioten
 und ähnlicher Bio-Abfall werden ohne Hinweis ignoriert!
            - Sei eine Möwe: Scheiss drauf -

[toc] | [prev] | [next] | [standalone]

#52988

Maik Koenig:

> Am 13.05.2018 um 15:59 schrieb Arno Welzel:
>> Maik Koenig:
>>
>>> Am 13.05.2018 um 13:56 schrieb Lothar Geyer:
>>>
>>>> Also ist jeder Zeitraum abgedeckt und der Wechsel der Anzeige erfolgt 
>>>> über meta refresh automatisch. Ist ja auch nur interessant, wenn jemand 
>>>> den Tab mit der Seite offen lässt. Ansonsten wird je sowieso neu geladen.
>>>
>>> Ich lese jetzt nicht den ganzen Thread, aber warum über Meta Refresh?
>>> JavaScript dürfte das doch deutlich einfacher machen.
>>
>> Nö - denn das erfordert JavaScript. Ein Meta Refresh geht auch ohne
>> JavaScript. Deswegen halte ich es ja für fragwürdig, weil der Benutzer
>> das automatische Neuladen der Seite nicht verhindern kann.
> 
> Naja, das dürfte nur bei mobilen Anschlüssen ein relatives Problem sein,
> weil da unnötig Datenvolumen verschwendet wird.
> 
> Ich bin ja auch kein riesiger Fan von JavaScript, aber sowas würde ich
> definitiv mit JS lösen. Es ist ein leichtes abhängig von der Uhrzeit die
> Texte anzupassen.

Das ist es auf dem Server ebenso. Ob der Code nun JavaScript oder PHP
ist, ändert am Aufwand im Ergebnis nicht viel, nur an der Art, wie das
Neuladen ausgelöst wird.



-- 
Arno Welzel
https://arnowelzel.de
https://de-rec-fahrrad.de
http://fahrradzukunft.de

[toc] | [prev] | [next] | [standalone]

#52989

Am 13.05.2018 um 18:55 schrieb Arno Welzel:

> Das ist es auf dem Server ebenso. Ob der Code nun JavaScript oder PHP
> ist, ändert am Aufwand im Ergebnis nicht viel, nur an der Art, wie das
> Neuladen ausgelöst wird.

Bei JS müsste man gar nicht neu laden... man würde den Text einfach zur
Laufzeit umändern. Wenn man schlicht alle z.B. 60 Sekunden die Uhrzeit
kontrolliert und beim Eintreffen entsprechender Zeiten die Einträge per
Script ändern lässt, muss rein gar nichts vom Server nachgeladen werden.

Selbst wenn so eine Seite permanent offen bliebe würde das weniger Akku
fressen als ein zwangsweises Nachladen vom Server.

Greetz,
MK
-- 
Kopp-Verlag-Gläubige, Religionsdeppen, rechte Vollidioten
 und ähnlicher Bio-Abfall werden ohne Hinweis ignoriert!
            - Sei eine Möwe: Scheiss drauf -

[toc] | [prev] | [next] | [standalone]

#52996

Maik Koenig:

> Bei JS müsste man gar nicht neu laden... man würde den Text einfach zur
> Laufzeit umändern. Wenn man schlicht alle z.B. 60 Sekunden die Uhrzeit
> kontrolliert und beim Eintreffen entsprechender Zeiten die Einträge per
> Script ändern lässt, muss rein gar nichts vom Server nachgeladen werden.
> 
> Selbst wenn so eine Seite permanent offen bliebe würde das weniger Akku
> fressen als ein zwangsweises Nachladen vom Server.

Ja - das wäre in der Tat eine Alternative. Um "Akku fressen" geht es
aber dabei gar nicht so sehr, sondern eher "Daten übertragen".


-- 
Arno Welzel
https://arnowelzel.de
https://de-rec-fahrrad.de
http://fahrradzukunft.de

[toc] | [prev] | [next] | [standalone]

#52999

Guten Morgen,

Am 13.05.2018 um 20:00 schrieb Maik Koenig:
> Bei JS müsste man gar nicht neu laden... man würde den Text einfach zur
> Laufzeit umändern. Wenn man schlicht alle z.B. 60 Sekunden die Uhrzeit
> kontrolliert und beim Eintreffen entsprechender Zeiten die Einträge per
> Script ändern lässt, muss rein gar nichts vom Server nachgeladen werden.
> 
> Selbst wenn so eine Seite permanent offen bliebe würde das weniger Akku
> fressen als ein zwangsweises Nachladen vom Server.

eine Lösung in JS würde aber bedeuten, dass ich sämtliche Berechnungen 
sowohl auf dem Server in PHP als auch in JS für den Client durchführen 
müsste.
Kurz nochmal: geöffnet ist an Samstagen, Sonntagen und Feiertagen 
zwischen Ostermontag und 3.10., jeweils von 14 - 18 Uhr. Um das mit den 
Feiertagen hinzubekommen, müsste ich also die Berechnung des 
Ostersonntags und aller davon abhängigen Feiertage auch in JS realisieren.

Lothar Geyer

[toc] | [prev] | [next] | [standalone]

#53001

Am 17.05.2018 um 07:50 schrieb Lothar Geyer:

> Kurz nochmal: geöffnet ist an Samstagen, Sonntagen und Feiertagen 
> zwischen Ostermontag und 3.10., jeweils von 14 - 18 Uhr. Um das mit den 
> Feiertagen hinzubekommen, müsste ich also die Berechnung des 
> Ostersonntags und aller davon abhängigen Feiertage auch in JS realisieren.

Nein. Du musst dem Script die Daten bloss übergeben. Wenn Du die Seite
sowieso per PHP erzeugst, ist es ein Leichtes die Daten an der
jeweiligen Stelle automatisch einzusetzen.

Greetz,
MK
-- 
Kopp-Verlag-Gläubige, Religionsdeppen, rechte Vollidioten
 und ähnlicher Bio-Abfall werden ohne Hinweis ignoriert!
            - Sei eine Möwe: Scheiss drauf -

[toc] | [prev] | [next] | [standalone]

#53002

Am 17.05.2018 um 12:30 schrieb Maik Koenig:
> Kopp-Verlag-Gläubige, Religionsdeppen, rechte Vollidioten
>  und ähnlicher Bio-Abfall werden ohne Hinweis ignoriert!
>             - Sei eine Möwe: Scheiss drauf -

Gestatte, dass ich deine Sig kritisiere: das ist kein "Bio - Abfall",
sonern "kackbrauner Müll".

Bio - Afall ist etwas wertvolles.

-- 
Grüße Erwin

[toc] | [prev] | [next] | [standalone]

#53004

Hallo!

* Maik Koenig <usenetspam@maikkoenig.de>:

> Nein. Du musst dem Script die Daten bloss übergeben. Wenn Du die Seite
> sowieso per PHP erzeugst, ist es ein Leichtes die Daten an der
> jeweiligen Stelle automatisch einzusetzen.

  Eine elegante Lösung wäre es, wenn das PHP neben dem Zustand
offen/geschlossen auch den Zeitpunkt der nächsten Änderung
berechnet. Dann könnte das Script am Client nicht nur den aktuelle
Zustand abfragen und darstellen, sondern auch das Timeout so
einstellen, daß es erst wieder nachfragt, wenn auch eine Änderung
zu erwarten ist, statt -- wie anderweitig im Thread vorgeschlagen
-- alle 60 Sekunden zu pollen. Das könnte wirklich auf Akku und
Datenvolumen gehen.

Christoph

-- 
Schaltgreise - Die Loesung gegen die Rentnerschwemme

[toc] | [prev] | [next] | [standalone]

#53185

Hallo Christoph,

Am 17.05.2018 um 17:16 schrieb Christoph 'Mehdorn' Weber:
>    Eine elegante Lösung wäre es, wenn das PHP neben dem Zustand
> offen/geschlossen auch den Zeitpunkt der nächsten Änderung
> berechnet.

das macht das PHP-Script. "Wir haben geschlossen. Am dd.mm.yyyy sind wir 
ab 14.00 Uhr wieder für Sie da."

> Dann könnte das Script am Client nicht nur den aktuelle
> Zustand abfragen und darstellen, sondern auch das Timeout so
> einstellen, daß es erst wieder nachfragt, wenn auch eine Änderung
> zu erwarten ist, statt -- wie anderweitig im Thread vorgeschlagen
> -- alle 60 Sekunden zu pollen. Das könnte wirklich auf Akku und
> Datenvolumen gehen.

Durch das meta refresh wird ja der Zeitpunkt der nächsten 
Zustands-Änderung übergeben - halt in Sekunden bis da hin. Wie der 
Browser das dann handelt - keine Ahnung. Ich glaube aber nicht, dass der 
jede Sekunde die Anzahl um 1 verkleinert.

Lothar Geyer

[toc] | [prev] | [next] | [standalone]

#52990

Arno Welzel schrieb:

> Das ist es auf dem Server ebenso. Ob der Code nun JavaScript oder PHP
> ist, ändert am Aufwand im Ergebnis nicht viel, nur an der Art, wie das
> Neuladen ausgelöst wird.

Mit Javascript kann ich mir zwei Lösungen denken: 

1) Die Ermittlung des anzuzeigenden Textes erfolgt timergesteuert im 
   Browser, dann muß gar nichts neu geladen werden. 
   
2) Mit XMLHttpRequests kann die zu übertragende Datenmenge reduziert 
   werden, weil nicht die ganze Seite, sondern nur der relativ kurze  
   Text neu geladen wird. 
   
Wobei ich wegen nur geringer eigener Erfahrung nicht sagen kann, ob das
praktikabler als eine serverseitige PHP-Lösung ist.

Gruß Heiko
-- 
Eine Frau ist ein Engel mit zehn, eine Heilige mit fünfzehn, ein Teufel mit 
vierzig und eine Hexe mit achtzig.
                                                                  Sprichwort

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | de.comm.software.mozilla.browser

csiph-web