jquery wird wo geladen ?

[herrmannj]

Hallo,

irgendwie blicke ich den Lademechanismus von jquery gerade nicht. Irgendwie war ich der Meinungs das jquery (und ui) generell zur Verfügung steht. Tatsächlich finde ich erst mal nur in der fhemweb_multiple.js ein nachladen.

Was ist die empfohlene Vorgehensweise für module ? Dynamisch im script oder FW Web extension ?

Danke und Grüße
Jörg

[rudolfkoenig]

Ich habe zwar vor jquery auch selbst zunehmend zu benutzen (sie kam rein wegen dashboard), aber ich empfehle sie dynamisch zu laden via:

Code Auswählen Erweitern

loadScript("pgm2/jquery.min.js", function(){
...
})


[herrmannj]

danke.

Auf IOS / könnte das evtl zu problemen führen. Man könnte jquery alternativ aus dem cdn laden (dann zählt die Verbindung nicht zum fhem host).

Oder evtl doch statisch? jquery ist doch recht verbreitet.

vg
jörg

[rudolfkoenig]

Auf IOS / könnte das evtl zu problemen führen.

Kannst Du bitte Details nennen?

[herrmannj]

sorry klar:

das Thema ist sind die begrenzten Verbindungen IOS/Safari zu einem Host. Das dynamische Nachladen belegt bereits eine der beiden Verbindungen. Die andere bekommt der longpoll (wenn auch verzögert). Kommen jetzt noch images (icons) dazu hängt es von der Reihenfolge der Aufrufe ab was passiert.

vg
Jörg

[herrmannj]

Hallo Rudi,

ich sehe gerade das Du genau dieses Thema überschneidend in der fhemweb.js angepackt und gelöst hast. Gemeinerweise war das noch nicht so als ich den thread aufgemacht habe. Ich hätte mich für statisches laden ausgesprochen muss aber zugeben das ich Deine Lösung so besser finde. 

Danke und thread damit soweit closed 
Jörg
 

[rudolfkoenig]

Ich bin mit der Loesung noch nicht ganz happy, weil iOS mit seiner Verbindungs-Begrenzung im Weg steht, und deswegen temporaer longpoll unterbrochen werden muss, was vermutlich auch komische Nebeneffekte hat.

Weisst Du (oder sonstwer), ob ein Umbau von longpoll auf Websockets das Problem loesen wuerde?

[herrmannj]

auf Dauer sind websockets sicher die coolere Lösung aber afaik hat zB android erst in den ganz aktuellen Versionen websocket support, das wäre also schon ein recht weitreichender Bruch und würde zB der Verwendung von nicht brand aktuellen Android Tabletts im Weg stehen, ich halte das daher nicht für ideal (my 5cc). Leider ...

btw: der longpoll hat ohnehin einen bug in der form das der responseText in receiver nicht auf null gesetzt werden kann und damit im Dauerbetrieb ohne Seitenwechsel (zB floorplan/Tablett, webViewControl) immer weiter anwächst bist der client crasht. Dafür teste ich gerade einen patch und auch der startet den XHR (wenn er eine bestimmte Größe erreicht hat) neu weil das der einzige Weg ist den buffer zu leeren.

Insofern habe ich gerade aktuell Test zu evtl "Nebeneffekten" gemacht und bisher keine festgestellt.

vg
jörg

[rudolfkoenig]

Das Android-Probem ist mir bewusst, ich wollte longpoll nicht ersetzten, sondern websockets parallel anbieten.

Bevor ich mir aber die Arbeit mache, wuesste ich gerne, ob das fuer das bekannte iOS-FHEMWEB-longpoll Problem hilft, oder websockets auch zum Pool der XHR Verbindungen zaehlen. Dateien (.png) kann ich mit einem bestehenden longpoll-Verbindung auch nicht laden. Und sowas steht nicht auf caniuse.com

[herrmannj]

verstehe. Kann mir gut vorstellen das Dein Vorbehalt begründet ist. Vielleicht weiß es ja jemand, ansonsten erkläre ich mich bereit das die Tage zu testen. 

vg
Jörg

[herrmannj]

der code ist mehrfach problematisch (funktioniert nicht) weil:

er wird trotz async=falsch asynchron ausgeführt. Zumindest auf ff 14 und der aktuellen (28/29?) lädt die Seite weiter. Das ist doppelt problematisch weil ein unmittelbar folgender zweiter laod call schon bei script.src true bekommt und den callback direkt ausführt und in der folge am nicht definierten "$" stirbt. Theoretisch wird außerdem der erste callback aufgerufen ohne das script schon an das DOM head gebunden ist, wobei das keine Fehler auswirft.

Dieser code behebt das problem und verzichten auch auf browser Weichen:

log("Loading "+sname);
 
  if(isiOS && FW_pollConn) {
    FW_poll_op = 2;
    FW_pollConn.abort();
  }

  var xhrObj = new XMLHttpRequest();
  // open and send a synchronous request
  xhrObj.open('GET', sname, false);
  xhrObj.send('');
  var se = document.createElement('script');
  se.type = "text/javascript";
  se.text = xhrObj.responseText;
  h.appendChild(se);
  xhrObj.abort();

  if(callback) callback();
  if(isiOS &&  FW_poll_op == 2) FW_longpoll();

Der Umgang mit IOS ist auf diesen patch abgestimmt: hhttp://forum.fhem.de/index.php/topic,23774.0.html

vg
Jörg

[rudolfkoenig]

Bitte diese Diskussion auch im verlinkten Thread weiterfuehren, bzw. den Patch anpassen.