Es gibt ja im Netz zahlreiche Beispiele, für Arduinos mit Webinterface, z.B. Relaissteuerungen. All diesen Beispielen ist gemeinsam, dass bei Betätigung eines Buttons ein Submit erfolgt und die gesamte Site neu vom Arduino geladen wird. So lange diese Site nur aus Standard-HTML besteht, geht das meist auch so schnell, dass man das Laden auf dem Endgerät nichtmal sehen kann. Sobald aber z.B. Icons zum Einsatz kommen (habe ich ausprobiert mit Base64-codierten embedded GIF und SVG), wird die Ladezeit so lang, dass man das Auffrischen der Site deutlichst bemerkt. Ein Speicherproblem stellen die Icons aufgrund der Verwendung der F()-Funktion bisher nicht dar (50% frei auf einem Uno). Mir sind Ajax und JQuery durchaus bekannt, aber die erfordern Libs, die statisch für den Arduino zu groß sind oder eine Internetverbindung, um sie direkt von ihren Home-Servern zu inkludieren. Für ein anderes (PC-) Projekt, allerdings mit einem "richigen" Webserver im Hintergrund, habe ich gerde eine Lösung gefunden, um mittels unsichtbarem iFrame permanent Informationen nachzuladen, ohne dass die Trägerseite ihrerseits nachgeladen werden muss. Die Frage ist nun, ob sich sowas mit dem Arduino auch machen ließe, gesteuert durch GET-Parameter, die ja meist sowieso zur Anwendung kommen. Beim ersten Request liefert der Arduino die gesamte Site aus, bei jedem weiteren Request nur noch den Inhalt des iFrames. Die Ergebnisse eines Submit lassen sich ja durch Verwendung der "target"-Option ins iFrame lenken, wodurch der erneute Seitenabruf entfällt. Für den Zugriff auf die Daten innerhalb des iFrame und ihrer Visualisierung auf der Host-Site habe ich Javascript-Funktionen. Ich würde in der zu submittenden Form z.B. ein auf hidden gestelltes Textfeld unterbringen, in der die Info "frame" steht. Dann get das als GET-Parameter mit in den Request, den der Arduino filtert. Beim ersten Seitenaufruf ist das nicht der Fall, dann wird die komplette Site gesendet. Bei einem Submit (wegen der Info) nur noch ein par verkürzte Infos, die im IFrame landen und danach vom Browser "herausgefischt" werden. Ergibt das Konzept einen Sinn, oder habe ich da eine grundlegenden Denkfehler? Danke für Tips. Klar werde ich das demnächst selber ausprobieren, aber könnte ja sein, dass hier jemand etwas weiß, was derartige Versuch von vorne herein sinnlos macht.
Ajax lässt sich auch ohne jegliche Libraries erldeigen.
Frank E. schrieb: > Es gibt ja im Netz zahlreiche Beispiele, für Arduinos mit Webinterface, > z.B. Relaissteuerungen. Die Doku zum zu verwendenden Webinterface wäre interessant. > All diesen Beispielen ist gemeinsam, dass bei Betätigung eines Buttons > ein Submit erfolgt und die gesamte Site neu vom Arduino geladen wird. Weil dass die einfachste methode ist, welche keine javascriptkentnisse erfordert. > Sobald aber z.B. Icons zum Einsatz kommen (habe ich ausprobiert mit > Base64-codierten embedded GIF und SVG), Und wenn du die einfach normal auf dem arduino Speicherst ubd die Relative URL angibst? Data urls verhindern cacheing und verbrauchen ca. 3 mal mehr speicher Pro element (bei base64) als nötig. > um mittels unsichtbarem iFrame permanent Informationen nachzuladen Das ist längst veraltet. Danach kam XMLHttpRequest (AJAX) und nun ist WebSocket aktuell. > JQuery durchaus bekannt, aber die erfordern Libs, die statisch für den > Arduino zu groß sind So wenig platz im Arduino? Gott sei Dank!
Frank E. schrieb: > Sobald aber z.B. Icons zum Einsatz kommen (habe ich ausprobiert mit > Base64-codierten embedded GIF und SVG), wird die Ladezeit so lang, dass > man das Auffrischen der Site deutlichst bemerkt. Wie lieferst du die Bilder aus? sind die in die HTML Seite direkt eingebettet oder muss der Browser die jeweilige Resource mit einem weiteren GET anfordern? Wenn letzteres: erlaub dem Browser ganz einfach dass er die Bilder cachen darf und schon ist das Problem gelöst.
Karl H. schrieb: > Wie lieferst du die Bilder aus? > sind die in die HTML Seite direkt eingebettet oder muss der Browser die > jeweilige Resource mit einem weiteren GET anfordern? > Wenn letzteres: erlaub dem Browser ganz einfach dass er die Bilder > cachen darf und schon ist das Problem gelöst. Die Bilder sind im HTML-Code eingebettet, deshalb ja auch Base64-codiert. Cachen kann ich m.W.(lass mich aber gerne belehren) nicht nur für Bilder einstellen, sondern nur ganz oder garnicht. Das macht aber Schwierigkeiten, wenn sich sonst etwas auf der Website ändert.
Frank E. schrieb: > Karl H. schrieb: > >> Wie lieferst du die Bilder aus? >> sind die in die HTML Seite direkt eingebettet oder muss der Browser die >> jeweilige Resource mit einem weiteren GET anfordern? >> Wenn letzteres: erlaub dem Browser ganz einfach dass er die Bilder >> cachen darf und schon ist das Problem gelöst. > > Die Bilder sind im HTML-Code eingebettet, deshalb ja auch > Base64-codiert. Und da haben wir schon das Problem. BIst du derjenige, der sich seit Tagen standhaft weigert auszuwerten, welche Resource vom Browser angefordert wird? (Ich red mir ja nicht umsonst den Mund fusselig, dass du da nicht drum herumkommst). > Cachen kann ich m.W.(lass mich aber gerne belehren) > nicht nur für Bilder einstellen, sondern nur ganz oder garnicht. Ja und? Wenn der Browser Bilder getrennt anfordert, dann kann er sie auch cachen. > Das > macht aber Schwierigkeiten, wenn sich sonst etwas auf der Website > ändert. Das betrifft nicht das Bild an sich. Das ändert sich nicht. An der HTML Seite kannst du ändern so viel du willst. Bau in deine HTML Seite Bilder so ein, wie man das schon in den Urzeiten von HTML gemacht hat, sorg dafür dass dein Server die entsprechenden GETs richtig behandelt, und du hast ein Problem weniger.
Daniel A. schrieb: >> um mittels unsichtbarem iFrame permanent Informationen nachzuladen > > Das ist längst veraltet. Danach kam XMLHttpRequest (AJAX) und nun ist > WebSocket aktuell. Das weiss ich selber, aber kennst du überhaupt einen Arduino UNO? Mit 2k RAM und 32k ROM? Für die von dir genannten Techniken muss auch der Server mitspielen, was so nicht geht, weil es ihn eigentlich nicht gibt. Ich finde es immer toll, wenn Leute ihren Senf dazugeben, ohne richtig zu lesen oder gar nachzudenken, hauptsache irgendwas geschrieben, um zu zeigen, wie schlau sie sind. Sollte ich dir unrecht tun, bitte ich um Entschuldigung, bitte aber gleichzeitig um technische Aufklärung.
vn nn schrieb: > Ajax lässt sich auch ohne jegliche Libraries erldeigen. Wie? Bitre ein Beispiel oder einen Link. Bitte Bedenken: Der Arduino ist der Server, mit 2kRAM und 32K ROM, die bereits teilweise vom Programmcode und als Puffer für die Ethernet-Schittstelle belegt sind.
Frank E. schrieb: > Wie? Bitre ein Beispiel oder einen Link. Das sind ein paar Zeilen Javascript (das entweder direkt mit der HTML-Datei ausgeliefert oder von ihr "includiert", d.h. als weiterer GET-Zugriff vom Webserver geliefert wird). Zwar heißt der Dreh- und Angelpunkt vom ganzen XMLHttpRequest, aber nichts und niemand zwingt einen dazu, hier XML zu verwenden. Der Webserver kann auch einfach nur einen simplen String à la "Hallo" ausliefern, und das Javascript genau diese Zeichenfolge aus dem XMLHttpRequest-Objekt extrahieren und z.B. in einen div-Container reinschreiben. http://wiki.selfhtml.org/wiki/XMLHttpRequest Das Beispiel "kompletter Code" gibt die empfangenen Daten per "alert" als Messagebox aus. Der Webserver muss mit dem GET-Request auf "daten.txt" natürlich etwas anfangen können, aber da reicht es halt wirklich, wenn da "huhu" oder was auch immer drinsteht. Mehr steckt wirklich nicht dahinter. Du müsstest in Deinem HMTL-Code also nur zwei Dinge einbauen, einerseits die paar Zeilen Javascript, und andererseits zur Anzeige der Dich interessierenden Dinge kein Frame, sondern z.B. einen div-Container, dem Du passenderweise auch noch eine Element-ID verpasst, so daß Du in der onreadystate-Funktion leicht auf dieses Element zugreifen und den Dich interessierenden Text einfügen kannst. Möchtest Du das zyklisch machen, musst Du nur einen Timer aufziehen und die open-Funktion des XMLHttpRequest-Objektes davon aufrufen lassen.
Rufus Τ. F. schrieb: > Der Webserver muss mit dem GET-Request auf "daten.txt" natürlich etwas > anfangen können, Wenn sein Server mit einem GET Request was anfangen könnte, dann würde sich dieses Problem erst mal gar nicht stellen. Denn Bilder cachen ging bei Web Browsern von anfang an. Sonst wär das Web nicht dort wo es heute wäre, wenn immer alle Bilder erneut übertragen werden müssten. Nur leider sind die meisten Arduino Web Server Beispiele, die ich bisher gesehen habe, dergestalt, dass sie eben NICHT auswerten, was der Browser mit einem GET anfordert sondern einfach immer so tun, als ob der Browser index.htm angefordert hätte. Und dann setzt halt meistens der Arduino-Weiss_nicht_weiter-Zyklus ein. Solange dem geneigten Möchtegern-Programmierer nicht jemand haarklein vorbetet, wie man einzelne char zu einem String zusammensetzt und den dann vergleicht (um den GET zu erkennen), bzw aus dem String die angeforderte URL extrahiert um zu entscheiden was der Server zu liefern hat, solange kommt er nicht weiter. Denn einen eigenen Web Server bauen, das war schon immer sein Traum. Nur das er dafür auch programmieren muss, das hat er nicht bedacht. Und nur mit dem Beispiel, in dem er ein paar Fix-Texte umändert, ist es dann eben nicht getan.
Frank E. schrieb: > Mit 2k RAM und 32k ROM? Für die von dir genannten Techniken muss auch > der Server mitspielen, was so nicht geht, weil es ihn eigentlich nicht > gibt. OK, stimmt, 2K ram sind für ordentliches tcp eigentlich schon zu wenig. Aber den Server muss es geben, sonst könnte der Browser die Seite nicht Anfordern. Bei AJAX sendet der Browser meistens einen GET request (ausser man will post oder head, etc.). Dies unterscheidet sich nicht von einem Request, wie er beim laden der Seite über den Browser kommt. Ausserdem: Da der Server nicht bekannt ist, kann ich auch nicht wissen, was dieser kann. > Das weiss ich selber, aber kennst du überhaupt einen Arduino UNO? Nein, aber ich weiss sehr viel über Webentwicklung, und kenne ALLE beim abruf einer Webseite Involvierten Protokolle. Ich arbeite sogar an einem eigenen Webserver für UCs (noch nicht fertig): https://github.com/Daniel-Abrecht/DPA-UCS Frank E. schrieb: > Ich finde es immer toll, wenn Leute ihren Senf dazugeben, ohne richtig > zu lesen oder gar nachzudenken, hauptsache irgendwas geschrieben, um zu > zeigen, wie schlau sie sind. Ich Lese, Denke und Antworte. Wenn dir das nicht passt, dann frage einfach nicht. Rufus Τ. F. schrieb: > Möchtest Du das zyklisch machen, musst Du nur einen Timer aufziehen und > die open-Funktion des XMLHttpRequest-Objektes davon aufrufen lassen. Die JS funktion dafür heisst setInterval
Daniel A. schrieb: > Ich Lese, Denke und Antworte. Wenn dir das nicht passt, dann frage > einfach nicht. Naja ... ich suche eben eine Lösung, die auf dem kleinen Ding läuft. Dass dies in der Welt von Apache und Co. ganz anders ist, ist mir schon klar ... Werde demnächst mal Versuche mit einem Websocket machen. TCP-Sockets sind mit aus "normalen" Programiersprachen schon geläufig.
Karl H. schrieb: > Nur leider sind die meisten Arduino Web Server Beispiele, die ich bisher > gesehen habe, dergestalt, dass sie eben NICHT auswerten, was der Browser > mit einem GET anfordert sondern einfach immer so tun, als ob der Browser > index.htm angefordert hätte. Oh. Ach Du Scheiße.
Rufus Τ. F. schrieb: > Karl H. schrieb: >> Nur leider sind die meisten Arduino Web Server Beispiele, die ich bisher >> gesehen habe, dergestalt, dass sie eben NICHT auswerten, was der Browser >> mit einem GET anfordert sondern einfach immer so tun, als ob der Browser >> index.htm angefordert hätte. > > Oh. Ach Du Scheiße. Genau. Für eine einzelne HTML Seite mit ein paar fixen Texten reicht das. Schliesslich ist es ja nur ein Demo-Beispiel. Leider verwechseln das dann eben viele mit einem fix&fertigen Web Server. Und dann beginnt das Drama.
Karl H. schrieb: > Leider verwechseln das dann eben viele mit einem fix&fertigen Web > Server. Und dann beginnt das Drama. https://www.arduino.cc/en/Tutorial/WebServer Hier ist die bewusste Stelle
1 | ...
|
2 | void loop() { |
3 | // listen for incoming clients
|
4 | EthernetClient client = server.available(); |
5 | if (client) { |
6 | Serial.println("new client"); |
7 | // an http request ends with a blank line
|
8 | boolean currentLineIsBlank = true; |
9 | while (client.connected()) { |
10 | if (client.available()) { |
11 | char c = client.read(); |
12 | Serial.write(c); |
13 | // if you've gotten to the end of the line (received a newline
|
14 | // character) and the line is blank, the http request has ended,
|
15 | // so you can send a reply
|
16 | if (c == '\n' && currentLineIsBlank) { |
17 | // send a standard http response header
|
18 | client.println("HTTP/1.1 200 OK"); |
Sobald eine einzelne Leerzeile vom Browser beisammen ist, wir dauf Biegen und Brechen mit immer der gleichen HTML Antwort geantwortet. Egal was der Browser will, er kriegt immer 'index.htm'
Frank E. schrieb: > Werde demnächst mal Versuche mit einem Websocket machen. TCP-Sockets > sind mit aus "normalen" Programiersprachen schon geläufig. Websocket und HTTP basieren auf TCP. Für eine Persistente TCP verbindung ist ein Retransmission cache zwingend Notwendig. Bei 2K ram, also 2048 bytes, minus 1500 bytes die zwingend für 1 Ethernet frame benötkgt werden, bleiben dafür noch 548 bytes, das ist zu wenig. Damit ist TCP und WebSocket auf einem Arduino UNO unmöglich.
Karl H. schrieb: > Karl H. schrieb: > >> Leider verwechseln das dann eben viele mit einem fix&fertigen Web >> Server. Und dann beginnt das Drama. > > https://www.arduino.cc/en/Tutorial/WebServer > > Hier ist die bewusste Stelle... Ach du sch... Wenn das so ein Sch... ist, was will der TS dann mit iframes? Die werden doch per GET und ihrer jeweiligen src URI geladen. Ein Webserver, der die Request-URI nicht auswertet kann, kann auch keine iframes.
Daniel A. schrieb: > Bei 2K ram, also 2048 bytes, minus 1500 bytes die zwingend für 1 > Ethernet frame benötkgt werden, bleiben dafür noch 548 bytes, das ist > zu wenig. Ich habe gerade dashier durchgelesen: https://www.arduino.cc/en/Main/ArduinoEthernetShield Der tcp stack ist auf dem ethernet shield, welcher "16K internal buffer" hat. Damit sind die 2K ram des Arduino UNO wieder bei weitem Ausreichend für WebSocket verbindungen. Ich werd mir mal die Arduino IDE herunterladen.
Angehängte Dateien:
Karl Heinz (kbuchegg) (Moderator) >Nur leider sind die meisten Arduino Web Server Beispiele, die ich bisher >gesehen habe, dergestalt, dass sie eben NICHT auswerten, was der Browser >mit einem GET anfordert sondern einfach immer so tun, als ob der Browser >index.htm angefordert hätte. Naja, eigentlich hängt es im wesentlichen von den Fähigkeiten des Suchmaschinenbenutzers ab. Die Arduino-Welt ist groß und es gibt für nahezu jedes Problem eine Lösung. Für die Bearbeitung der GET Anforderung gibt es die Textfinder-Library: http://playground.arduino.cc/Code/TextFinder Dort ist auch gleich der Download-Link für ein Webserver-Beispiel. Angehängt ist die HTML-Seite meines Arduino Webservers, bei der es mir gar nicht so sehr um den Webserver ging, sondern die Frage "wie berechne ich in Echtzeit eine SVG-Grafik". Wenn ich Zeit habe, möchte ich die Achsen des Grafen ein wenig verbessern und eventuell Balkendiagramme und andere Anzeigeinstrumente dazu basteln.
>Der tcp stack ist auf dem ethernet shield, welcher "16K internal buffer" >hat. Damit sind die 2K ram des Arduino UNO wieder bei weitem Ausreichend >für WebSocket verbindungen. Ich werd mir mal die Arduino IDE >herunterladen. Auf dem Ethernet-Shield ist auch ein SD-Karten Slot. Damit lassen sich scheinbar auch umfangreichere Sachen machen: https://github.com/ovidiucp/TinyWebServer
Ich habe da nochmal drüber nachgedacht und bin der Meinung, das ursprüngliche Konzept wird wahrscheinlich funktionieren. Ich werde das am WE real ausprobieren! Übrigens, ob iFrames nun veraltet sind oder nicht, ist in dem Falle völlig banane, es geht um eine einfache und resourcenschonende Lösung auf einem _MIKRO_-Controller. Tabellen sind auch veraltet und werden trotzdem noch genutzt. Zurück zum Thema: Auch die einfachsten Versionen des Arduino-"Servers" können GET-Statments analysieren, darüber wird ja schliesslich bestimmt, ob und was geschaltet werden soll. Also kann man die Regel aufstellen: Wenn keine (bekannten) Paramteren gefunden werden, dann die ganze Seite ausliefern, wenn (bekannte) Paramter gefunden werden, dann nur einen Datenstring (der dann im iFrame landet). Von dort werden im Browser per Javascript (Einzeiler-Funktionen) Daten entnommen und zur Aktualisierung der Darstellung verwendet (z.B. Icons per innerHTML austauschen). Browserseitig lässt sich das rel. einfach durch Verwendung der "target"- Option (Name des iFrames) im Form-Element bewerkstelligen ...
Frank E. schrieb: > Also kann man die Regel aufstellen: Wenn keine (bekannten) Paramteren > gefunden werden, dann die ganze Seite ausliefern, wenn (bekannte) > Paramter gefunden werden, dann nur einen Datenstring (der dann im iFrame > landet). Von dort werden im Browser per Javascript > (Einzeiler-Funktionen) Daten entnommen und zur Aktualisierung der > Darstellung verwendet (z.B. Icons per innerHTML austauschen). Dann kannst Du den Frame aber auch einfach weglassen. Nur weil Frames veraltet sind, muss man sie nicht verwenden, auch wenn Retro cool und angesagt ist.
Wenn du jetzt aber XMLHttpRequest statt den IFrames nutzt, kannst du sogar auf Verbindungsfehler reagieren und die Anfrage erneut senden usw. Der Aufwand ist auf dem Webserver der gleiche und im Javascript sind es wohl auch ungefähr gleich viele Zeilen... Und dabei rede ich jetzt nicht von der Verwendung irgendwelcher Libs... Davon ab, funktioniert XMLHttpRequest auch in jedem Browser ohne Probleme... Bei dem Zugriff zwischen den Frames, können dir die Sicherheitseinstellungen der Browser schnell mal in die Suppe spucken - falls das hier relevant ist.
Michael R. schrieb: > Davon ab, funktioniert XMLHttpRequest auch in jedem Browser ohne > Probleme... Bei dem Zugriff zwischen den Frames, können dir die > Sicherheitseinstellungen der Browser schnell mal in die Suppe spucken - > falls das hier relevant ist. so wie ich das sehe ist hier relevant das der op seine "lösung" umsetzt und nichts anderes. dass ajax auch ohne jquery und Konsorten geht sollte man nach 10 sekunden google heraus gefunden haben und dass die Aussage "ist zwar veraltet aber wird noch verwendet also warum nich" eine self fulfilling prophecy ist ist wohl auch klar. aber hier gehts nicht darum heraus zu finden wie der richtige weg ist sondern darum wie der op seine idee ans laufen bekommt ungeachtet ob sie gut ist oder nicht
Rufus Τ. F. schrieb: > Frank E. schrieb: >> Also kann man die Regel aufstellen: Wenn keine (bekannten) Paramteren >> gefunden werden, dann die ganze Seite ausliefern, wenn (bekannte) >> Paramter gefunden werden, dann nur einen Datenstring (der dann im iFrame >> landet). Von dort werden im Browser per Javascript >> (Einzeiler-Funktionen) Daten entnommen und zur Aktualisierung der >> Darstellung verwendet (z.B. Icons per innerHTML austauschen). > > Dann kannst Du den Frame aber auch einfach weglassen. Nur weil Frames > veraltet sind, muss man sie nicht verwenden, auch wenn Retro cool und > angesagt ist. nö nö nö nö nöh - um mit Maulwurfn zu sprechen. Es geht ja darum, das Nachladen der gesamten Seite zu verhindern. Also muss man entweder iFrames benutzen oder XMLHTTPRequests. Gegen letzteres bin ich ja nicht grundsätzlich, habe da aber derzeit noch Bedenken, ob das mit dem Arduino Uno möglich ist. Bei iFrames bin ich mir fast sicher, dass es geht ...
Michael R. schrieb: > Davon ab, funktioniert XMLHttpRequest auch in jedem Browser ohne > Probleme... Bei dem Zugriff zwischen den Frames, können dir die > Sicherheitseinstellungen der Browser schnell mal in die Suppe spucken - > falls das hier relevant ist. Ich glaube, das spielt nur bei Frames aus anderen Domains eine Rolle, ist hier nicht relevant.
Frank E. schrieb: > Es geht ja darum, das Nachladen der gesamten Seite zu verhindern. Also > muss man entweder iFrames benutzen oder XMLHTTPRequests. Ich denke du machst es dir immer noch viel zu kompliziert. Wenn es nur darum geht, das ständige Laden von ein paar Bildern (die sich nicht verändern) zu verhindern, dann reicht es seit 20 Jahren im IMG Tag einfach die URL des Bildes anzugeben anstatt eine Daten-URL zu benutzen
1 | <html>
|
2 | <body>
|
3 | |
4 | <img src="smiley.gif"> |
5 | |
6 | </body>
|
7 | </html>
|
der Browser schickt einen neuen GET Request um smiley.gif zu kriegen, cacht das bei sich lokal, und wenn die Seite erneut aufgebaut wird, holt er sich das Bild aus seinem Cache. Gibst du im IMG Tag auch noch eine Größenangabe an, dann bauen viele Browser die Seite auch gleich so auf, dass sie für das Bild einen entsprechend grossen Platzhalter vorsehen. Die Seite wird mit dem noch fehlenden Bild angezeigt und der Browser sorgt selbst dafür, dass die fehlenden Bilder noch ergänzt werden. Entweder aus dem Cache oder indem er sie beim Server anfordert. Nix gegen Ajax und diverse Requests. Das hat alles seine Berechtigung. Aber um ein paar gleichbleibende Bilder zu verwalten ist das maximalkompliziert mit Kanonen auf Spatzen geschossen. Alles was dein Server dazu können muss ist aus dem Request den er kriegt
1 | GET smiley.gif |
den Dateinamen zu extrahieren und dann eben eine andere HTTP Antwort
dafür generieren, in der die Bilddaten enthalten sind.
Das hat dann auch noch den Vorteil, dass dasselbe Icon(Bild) an vielen
Stellen in der Web-Seite vorkommen kann, OHNE dass der Browser dann
jedesmal eine neue Komminikation anleiert. Er verwendet einfach das Bild
das er schon hat, an allen diesen Stellen. Und das soll ja bei
Web-Steuerungen gar nicht so selten sein, dass man zb für
Releaiszustände ein/aus dann auch immer dieselben Bilder benutzt.
Damit
> (habe ich ausprobiert mit Base64-codierten embedded GIF und SVG),
hast du dir nur selbst ins Knie geschossen. Denn hier kann weder Browser
noch Server irgendwas zu deinem Vorteil optimieren. Das mag zwar einfach
in deinen jetzigen Server Code integrierbar gewesen sein, war aber
kontraproduktiv.
Maximal schickt man in der Antwort, in der das Bild ausgeliefert wird,
noch eine max-age Angabe mit, damit das Bild nicht ewig im Cache
rumgammelt, aber mehr ist nicht notwendig, um bei Folge-Abfragen den
Seitenaufbau (im Hinblick auf fixe Bilder) zu beschleunigen.
Die Auswertung des GET im Server ist aber notwendig. Egal welche Technik
dann letzten Endes zum Einsatz kommt.
Frank E. schrieb: > Gegen letzteres bin ich ja nicht grundsätzlich, habe da aber derzeit > noch Bedenken, ob das mit dem Arduino Uno möglich ist. Bei iFrames bin > ich mir fast sicher, dass es geht ... Der Arduino weiß überhaupt nichts davon, ob da Frames oder XMLHttpRequest verwendet werden; wenn der in der Lage ist, aufgrund des GET-Requests unterschiedliche Daten auszuliefern (was er sowohl für den Fall der Verwendung von Frames muss, um die "Hauptseite" vom Frameinhalt zu unterscheiden, als auch für den XMLHttpRequest-Fall), dann kann beides verwendet werden. Im Falle des XMLHttpRequests können aber die zu liefernden Daten auf das wesentliche reduziert werden und müssen nicht die syntaktischen Anforderungen an den Inhalt eines Frames erfüllen. Obendrein müssen die Daten des Frames nicht mehr eigens geparst werden, um herauszufinden, was davon wie zu interpretieren ist, sondern die können dem XMLHttpRequest bereits mundgerecht vorverdaut geliefert werden. Die einzige Voraussetzung ist, daß der Webserver des Arduinos das Argument des GET-Requests auswertet -- wie gesagt, das muss er auch im Frame-Fall.
>> Ajax lässt sich auch ohne jegliche Libraries erldeigen. > Wie? Bitre ein Beispiel oder einen Link. Siehe Wikipedia. Oder guck von meiner Homepage ab:
1 | /* Load navigation HTML fragment into the destination element |
2 | id = id of the destination div |
3 | url = url of the navigation HTML fragment |
4 | */ |
5 | function navi_load(id,url) {
|
6 | var destination=document.getElementById(id); |
7 | try {
|
8 | // Send HTTP request (IE requires ActiveX, all other require XMLHttpRequest) |
9 | // Konqueror does not work with POST request. |
10 | var request = window.XMLHttpRequest ? new XMLHttpRequest() : new ActiveXObject("MSXML2.XMLHTTP.3.0");
|
11 | request.open("GET", url, true);
|
12 | request.send(null); |
13 | // wait for the result |
14 | var counter=0; |
15 | var timer = function() {
|
16 | if (request.readyState == 4) {
|
17 | // show the result |
18 | destination.innerHTML=request.responseText; |
19 | } |
20 | else if (++counter>50) {
|
21 | // report timeout and cancel the request |
22 | destination.innerHTML="Ich kann die Navigation nicht laden, timeout"; |
23 | request.abort(); |
24 | } |
25 | else {
|
26 | // continue waiting |
27 | window.setTimeout(timer,100); |
28 | } |
29 | } |
30 | window.setTimeout(timer,100); |
31 | } |
32 | catch (e) {
|
33 | destination.innerHTML="Ich kann die Navigation nicht laden"; |
34 | } |
35 | } |
Ich verwende dieses Stück Code, um das Navigationsmenü in meine Seiten
einzubetten. So muss ich nicht die ganze Navigation in jede einzelne
HTML Seite manuell reinkopieren und ich brauche auch keien Frames.
Ich benutze es so: Links oben in jeder Seite gibt es einen leeren div
für die Navigation:
<div id="navi"></div>
Dieses Div fülle ich aus, indem ich die Javascript Funktion aufrufe:
navi_load("navi","navigation.html")>
Die Datei navigation.html enthält das gewüschte HTML Fragment. Zum
Beispiel:
1 | <ul> |
2 | <li> Link 1... |
3 | <li> Link 2... |
4 | <li> Link 3... |
5 | </ul> |
Das Prinzip lässit sich auch auf Daten im JSON Format anwenden, die anschließend per Javascript ausgewertet werden.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.