mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik ajax auf nucleo, mehrere Browser?


Autor: pegel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
ich habe ein funktionierendes ajax das ich gern parallel von mehreren 
Browsern bedienen würde.
Mit js kann ich zyklisch die ganze Seite neu laden um die Änderungen zu 
sehen. Läuft auch bis jetzt so.
Kann sein das ich das noch nicht verstanden habe, aber gibt es eine 
Möglichkeit die Seite bzw. das geänderte Element nur bei Änderung einer 
Variable im Controller neu zu laden?

Die nächste Idee wäre eine zyklische GET Abfrage einer Zeitvariablen vom 
Controller die nur bei Änderung die Tags neu lädt.

Gibt es noch eine bessere Möglichkeit?

Danke.

Autor: Johnny B. (johnnyb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
pegel schrieb:
> Mit js kann ich zyklisch die ganze Seite neu laden um die Änderungen zu
> sehen. Läuft auch bis jetzt so.
> Kann sein das ich das noch nicht verstanden habe, aber gibt es eine
> Möglichkeit die Seite bzw. das geänderte Element nur bei Änderung einer
> Variable im Controller neu zu laden?

Heutzutage lädt man die Seite nur noch einmal komplett, danach macht man 
nur noch partielle Updates auf den geänderten Elementen.
AJAX und js sind schon mal gute Stichworte. Um die Arbeit mit js zu 
erleichtern, kann ich jQuery empfehlen.
https://jquery.com/

> Die nächste Idee wäre eine zyklische GET Abfrage einer Zeitvariablen vom
> Controller die nur bei Änderung die Tags neu lädt.

Wenn die Daten umfangreich sind, würde ich in einer ersten Abfrage nur 
ein Flag oder eine Art Versionsnummer der Daten abfragen, ob etwas 
geändert hat. Wenn ja, dann kannst Du die kompletten Daten runterladen 
und die geänderten Elemente dann auf der Website aktualisieren (mit js 
oder jQuery).
Wenn es nur ein paar Kilobyte Daten sind und es keine Mobile-Anwendung 
ist, würde ich immer gleich die kompletten Daten nachladen und im 
Browser verarbeiten.

: Bearbeitet durch User
Autor: Toni Tester (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es gibt auch Push-Technologien für Ajax. Suchbegriffe hierfür wären 
Reverse-Ajax und Comet.
Ob das sinnvoll ist, hängt von mehreren Faktoren ab, z. B. 
Aktualisierungshäufigkeit, Menge der Daten, Stabilität der 
Netzwerkverbindung etc. Auch gibt es zahlreiche Frameworks und 
Implementierungen; hier hängt es natürlich davon ab, welches Framework 
du aktuell einsetzt, um den Implementierungsaufwand möglichst gering zu 
halten.

Autor: pegel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Johnny B. schrieb:
> Wenn die Daten umfangreich sind, würde ich in einer ersten Abfrage nur
> ein Flag oder eine Art Versionsnummer der Daten abfragen,

Danke. Das habe ich mir so vorgenommen mit einem Zeitstempel abzufragen.
jQuery hatte ich probiert, schien aber noch mehr Datenverkehr zu 
erzeugen, dashalb habe ich es dann wieder verworfen.

Toni Tester schrieb:
> Es gibt auch Push-Technologien für Ajax

Werde ich mir ansehen.

Ich hatte gehofft das ich das laden irgendwie vom Server anstossen und 
an den Browser senden kann. jQuery scheint der Sache nahe zu kommen.

Es scheint mir das beste einen Zeitstempel der letzten Änderung 
abzufragen.

Danke euch.

Autor: Johnny B. (johnnyb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
pegel schrieb:
> jQuery hatte ich probiert, schien aber noch mehr Datenverkehr zu
> erzeugen

Also das jQuery selbst muss natürlich zu Beginn (erster Seitenaufruf) 
mal geladen werden. Aber das sind ja in der aktuellen Version 3.1.1 nur 
schlappe 87kB und wie gesagt, nur einmalig zu laden. Anschliessend ist 
es im Cache vom Browser.
jQuery ist nur ein JavaScript-Framework um die Manipulation von 
Elementen im DOM zu vereinfachen, damit man sich nicht so viele Gedanken 
machen muss, wie wenn man nur pures JavaScript verwendet. Und darin sind 
auch gewisse Unterschiede von den Browsern berücksichtigt, damit es 
überall läuft.
Es kann daher eigentlich nicht sein, dass Du noch zusätzlichen 
Datenverkehr hast.

Edit: Falls die 87kB noch zu gross sind, kannst Du es mit GZip 
komprimieren, welches der Browser selbst entpacken kann. Dann wären es 
noch 29kB.

: Bearbeitet durch User
Autor: Joachim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi pegel,

ich kenn mich mit den Nucleo nicht aus, aber im Web-Umfeld kommen für 
dein Problem meist zwei Lösungsansätze in Frage:

1.) Long-Polling:
Wird auch vom Client angestoßen und baut eine Verbindung zum Server auf. 
Hat der Server keine Daten, wird die Verbindung so lange offen gehalten, 
bis Daten zur Verfügung stehen. Dann werden die Daten an den Client 
übertragen, die Verbindung wird geschlossen und der Client baut sofort 
wieder eine neue Verbindung auf.

2.) WebSockets:
Neben der üblichen HTTP Verbindung kann der Browser zum Web-Server eine 
WebSocket Verbindung aufbauen. Das ist ein Bidirektionaler Datenkanal, 
der ständig offen ist und du somit in Realtime Daten vom Server an den 
Browser senden kannst.

Wenn beides auf dem Nucleo nicht machbar ist, bleibt nur:

3.) Polling
Der Browser fragt in regelmäßigen Intervallen den Server nach neuen 
Daten.
Das machst du aber nicht in dem du die ganze Seite neu lädst, sondern 
mit einem Ajax-Aufruf aus dem JavaScript heraus. Das kannst du ganz 
leicht mit ein paar Zeilen JavaScript-Code und "xmlhttprequest" selber 
machen und brauchst kein jQuery dafür.

Wichtig zu wissen wäre, ob du sparsam mit dem Datenverkehr umgehen 
musst. Wenn nein, kannst du alle 1 Sekunden einfach die jeweils 
aktuellen Daten vom Server abrufen. Wenn nein, mach das Intervall größer 
und übertrage vom Server nur dann Daten, wenn sie sich geändert haben. 
Dazu brauchst du wie schon erwähnt einen Timestamp, Hash, Datensatz-ID 
oder ähnliches, an dem du erkennen kannst, dass sich die Daten seit dem 
letzten Aufruf verändert haben.

Gruß Joachim

Autor: Joachim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ach noch was zum drüber Nachdenken:

Problem ist generell, dass ein HTTP Aufruf immer vom Client gestartet 
wird und vom Server sofort beantwortet wird. Damit ist der 
Datenaustausch abgeschlossen. Der Server hat bei HTTP keinerlei 
Möglichkeit, Daten direkt an den Client zu senden.

Wenn deine Anforderung also ist, Daten die sich am Server ändern sofort 
im Client zu sehen, dann ist HTTP der falsche Weg. Über Polling und 
Long-Polling (Comet) gibt es zwar "Krücken" um das Problem zu umgehen, 
man kauft sich aber auch immer gewisse Nachteile mit ein.

WebSocket ist die offizielle Variante um zwischen Browser und Web-Server 
neben dem HTTP Request/Response auch eine dauerhafte bidirektionale 
real-time Datenverbindung aufzubauen. Allerdings weiß ich nicht wie 
einfach man das auf einem Nucleo implementieren kann.

Wenn es wirklich in Echtzeit sein soll, dann wäre eine Variante auch 
noch eine "echte" Anwendung (Windows, Linux, Android, iOS) zu 
programmieren, die eine TCP Socket-Verbindung zum Nucleo aufbaut und 
über diesen Kanal in Echtzeit Daten austauscht.

Gruß Joachim

Autor: hust (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
nimm websocket

der handshake ist recht einfach zu implementieren und läuft auf einem 
cortex  genau so schnell wie 0815 http

dann baust dir passende events und kannst in beide richtungen 
senden/empfangen

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.