Kleines Problem bei FHEMWEB / HTTPSRV

viegener · 16 Mai 2015, 18:10:20

Hi,
wenn man eine HTTPSRV-Definition nutzt (wie zum Beispiel

define tablet_ui HTTPSRV tablet ./tablet.www Tablet Frontend

Wird im FHEMWEB ja dankenswerterweise der Link auf diesen Eintrag eingeblendet, in diesem Fall also
http://<server>:8083/fhem/tablet

Allerdings fehlt diesem Link der abschliessende Slash und damit funktionieren dann zum Beispiel das hier verwendete Tablet UI nicht. Der Slash kann auch nicht in der Definition mit angegeben werden, da dann an anderer Stelle beim Zerlegen des Pfades Probleme entstehen.

Der Fix ist eigentlich ganz einfach:, dazu muss im Modul FHEMWeb in der sub FW_roomOverview()

Code Auswählen


  ########################
  # Show FW Extensions in the menu
  if(defined($data{FWEXT})) {
    my $cnt = 0;
    foreach my $k (sort keys %{$data{FWEXT}}) {
      my $h = $data{FWEXT}{$k};
      next if($h !~ m/HASH/ || !$h->{LINK} || !$h->{NAME});
      next if($FW_hiddenroom{$h->{NAME}});
      push(@list1, $h->{NAME});
      push(@list2, $FW_ME ."/".$h->{LINK});

in der letzten Zeile des abgebildeten Blocks (bei mir 1202) der Slash angefügt werden:

Code Auswählen


      push(@list2, $FW_ME ."/".$h->{LINK}."/");

Dann wird ein url erzeugt, der im Raum von httpsrv liegt und von diesem bearbeitet wird (es wird dann ja index.html angezogen).

Wäre schön, wenn das übernommen werden könnte ...

TFTC (Thanks for the code)

Johannes

rudolfkoenig · 17 Mai 2015, 09:56:24

FWEXT LINK wird von mehreren Modulen (ich habe 9 gezaehlt) verwendet, und diese haben sich an die aktuelle Schreibweise angepasst. Bevor FHEMWEB geaendert wird, muessten alle Autoren dieser Module bestaetigen, dass eine Aenderung gewuenscht ist.

Wenn mit HTTPSRV ein Problem besteht, dann bin ich der Ansicht, dass es da geloest werden muss, und da braucht man mehr als Info als "an anderer Stelle beim Zerlegen des Pfades Probleme entstehen".

viegener · 20 Mai 2015, 17:40:09

Zitat von: rudolfkoenig am 17 Mai 2015, 09:56:24
FWEXT LINK wird von mehreren Modulen (ich habe 9 gezaehlt) verwendet, und diese haben sich an die aktuelle Schreibweise angepasst. Bevor FHEMWEB geaendert wird, muessten alle Autoren dieser Module bestaetigen, dass eine Aenderung gewuenscht ist.

Akzeptiert

Zitat von: rudolfkoenig am 17 Mai 2015, 09:56:24
Wenn mit HTTPSRV ein Problem besteht, dann bin ich der Ansicht, dass es da geloest werden muss, und da braucht man mehr als Info als "an anderer Stelle beim Zerlegen des Pfades Probleme entstehen".

Klingt plausibel, ich war erstmal davon ausgegangen, dass das Problem in FHEMWEB liegt, da es sich durch eine Zeile Änderung (für mich lösen lässt), aber ich gebe zu die Metrik ist etwas fragwürdig

Ich schaue mal, ob eine Anpassung in HTTPSRV möglich wäre (am besten ohne die Verwender von HTTPSRV zu beinträchtigen). Es erfordert aber wohl etwas mehr Aufwand.

Vielleicht weiss jemand ob HTTPSRV nur für Kollektionen (sprich Pfade) eingesetzt wird?

Johannes

viegener · 21 Mai 2015, 00:14:51

OK, vielleicht ist es ja doch ganz einfach, also neuer Patch:

Wenn in 02_HTTPSRV in sub HTTPSRV_CGI

die Zeile (bei mir Zeile 119)

Code Auswählen

if($request =~ m,^(/[^/]+)(/(.*)?)?$,) {

in

Code Auswählen

if($request =~ m,^(/[^/]+/)((.*)?)?$,) {

geändert wird, geht es in meinen Szenarien ganz wunderbar. Allerdings muss natürlich eine device definition für HTTPSRV den Slash auch enthalten. Also zum Beispiel für meine Beispiel von vorher

Code Auswählen

define tablet_ui HTTPSRV tablet/ ./tablet.www

Durch die Änderung wird bei der Suche nach passenden FWEXT Link Einträgen der Slash im URL mit in $link ($1 des regexp) abgelegt. Somit wird in FHEMWEB auch der richtige URL erzeugt und es ist keine Änderung in FHEMWEB erforderlich...

Klingt für mich erstmal besser, auch wenn natürlich bestehende HTTPSRV-Definitionen dadurch betroffen sein könnten!

Gruss,
Johannes

viegener · 02 Juni 2015, 00:01:23

Zitat von: rudolfkoenig am 17 Mai 2015, 09:56:24
FWEXT LINK wird von mehreren Modulen (ich habe 9 gezaehlt) verwendet, und diese haben sich an die aktuelle Schreibweise angepasst. Bevor FHEMWEB geaendert wird, muessten alle Autoren dieser Module bestaetigen, dass eine Aenderung gewuenscht ist.

Ich versuche immer noch das Zusammenspiel zwischen FHEMWEB, HTTPSRV und Tablet UI problemlos zum Funktionieren zu bringen.

Dabei bin ich auf eine weitere Frage gestossen:

in 01_FHEMWEB in sub FW_answerCall

enthält folgenden Abschnitt:

Code Auswählen


    # pgm2 check is for jquery-ui images
    my $static = ($ext =~ m/(css|js|png|jpg)/i || $dir =~ m/^pgm2/);
    if(-r "$ldir/$file.$ext" || $static) {  # no return for FLOORPLAN
      return FW_serveSpecial($file, $ext, $ldir, ($arg =~ m/nocache/) ? 0 : 1);
    }

Warum ist hier ein ODER vor dem $static, wenn doch die Datei in diesem Fall vielleicht nicht existiert?
Nach meinem Verständnis führt das dazu, dass versucht wird nicht existente Dateien über serveSpecial zu behandeln?

Ich hatte angenommen, dass von der Intention hier statische Dateien, für die keine FWEXT-Definition existiert direkt abzuhandeln. Für nicht existente Dateien wird das aber nicht funktionieren.

Vielleicht kann mich jemand hier erleuchten, ob ich da auf dem Holzweg bin?

Gruss,
Johannes

rudolfkoenig · 02 Juni 2015, 06:54:14

Naja, ein UND wuerde noch weniger Sinn machen.

Ein Problem sind z.Bsp. die von jQuery-UI fuer manche Widgets abgerufene, aber in FHEM nicht installierte Bilder, die ohne diesen ODER in den FWEXT Modulen landen, die damit nichts anzufangen haben, und als Bild eine HTML Fehlermeldung zurueckliefern, was wiederum im Browser zu doofen Meldungen fuehrt.

viegener · 02 Juni 2015, 15:07:41

Wenn aber eine FWEXT definiert ist, geht er doch sowieso nicht in diesen Teil, da vorher auf eine Existenz einer FWEXT-Definition überprüft wird.

Code Auswählen

} elsif($dir1 && !$data{FWEXT}{"/$dir1"}) {

m.a.W.: Wenn eine FWEXT-Erweiterung für den ersten Teil des Pfades definiert ist, dann wird der Teil nicht durchlaufen.

Johannes

Dr. Boris Neubert · 06 Juni 2015, 08:58:24

Hallo,

ich habe die vorgeschlagene Änderung übernommen. Jetzt im SVN und morgen per Update.

Zitat von: viegener am 21 Mai 2015, 00:14:51
OK, vielleicht ist es ja doch ganz einfach, also neuer Patch:

Wenn in 02_HTTPSRV in sub HTTPSRV_CGI

die Zeile (bei mir Zeile 119)
Code Auswählen Erweitern
if($request =~ m,^(/[^/]+)(/(.*)?)?$,) {

in
Code Auswählen Erweitern
if($request =~ m,^(/[^/]+/)((.*)?)?$,) {

geändert wird, geht es in meinen Szenarien ganz wunderbar. Allerdings muss natürlich eine device definition für HTTPSRV den Slash auch enthalten. Also zum Beispiel für meine Beispiel von vorher

Code Auswählen Erweitern
define tablet_ui HTTPSRV tablet/ ./tablet.www

Außerdem wird in der Definition beim Infix der abschließende Slash automatisch ergänzt, wenn er fehlt. Damit sollten auch bestehende Konfigurationen weiter funktionieren. Die Doku ist entsprechend angepasst.

Ich habe minimale Tests durchgeführt. Bitte eine Rückmeldung, ob das jetzt so funktioniert.

Viele Grüße
Boris

viegener · 06 Juni 2015, 23:37:11

Hallo Boris,
leider funktioniert das tablet ui bei mir mit der Version aus SVN nur, wenn nicht auch die oben diskutierte Änderung passieren würde. Es wird nämlich Zugriffe auf css oder js-Dateien nicht mehr korrekt bearbeitet,

Ich hätte anbei aber eine zweite Variante, die komplett ohne Änderung in FHEMWEB auskommt und bei mir sauber funktioniert Es gibt dann auch keine Probleme mit Definitionen ohne /. Ich habe dazu auch aus dem tablet ui thread positive Rückmeldungen bekommen.

Zur Erklärung in addExtension wird der übergebene Parameter $link in die verschiedenen Teile für FWEXT zerlegt. Kommentare sind im Code enthalten In der eigentlichen Bearbeitung von Requests HTTPSRV_CGI wird dann versucht die Anfrage entweder ohne oder mit slash am Ende zu finden.

Sorry das dass jetzt so unerwartet aufwändig ist..

Gruss,
Johannes

wtue · 19 Juni 2015, 16:51:42

Hallo zusammen,
ich habe gestern ein update meiner FHEM Installation gemacht. Seit dem kann ich die URL zum anzeigen einer Seite mit Buttons nicht mehr aufrufen. Es erscheint oben links ein kleines Symbol auf sonst komplett weißem Hintergrund. Mit dem Update habe ich die Version

# $Id: 02_HTTPSRV.pm 8700 2015-06-06 06:54:05Z borisneubert $

aktiviert. Wenn ich die Version

# $Id: 02_HTTPSRV.pm 8163 2015-03-07 10:50:05Z borisneubert $

wieder restauriere, funktioniert alles wie gewohnt.

meine Definition:

Code Auswählen

define myJSFrontend HTTPSRV tabled /opt/fhem/tabled/ Hausübersicht
attr myJSFrontend room RSS

Auruf der URL

Code Auswählen

http://fhemhost:8083/fhem/tabled/

Die index.html im Verzeichnis tabled

Code Auswählen

[Mapi] 
{panel.html} {warntext.html}

Dr. Boris Neubert · 20 Juni 2015, 09:41:17

Hallo,

ich habe heute HTTPSRV auf Revision 8163 zurückgeführt und eingecheckt.

Grüße
Boris

viegener · 20 Juni 2015, 19:03:45

Zitat von: Dr. Boris Neubert am 20 Juni 2015, 09:41:17
Hallo,

ich habe heute HTTPSRV auf Revision 8163 zurückgeführt und eingecheckt.

Grüße
Boris

Wäre es denkbar, die verbesserte Änderung, die ich am 6.6. gepostet habe zu prüfen und zu übernehmen?
Diese sollte rückwärtskompatibel sein, aber trotzdem für Benutzer von (z.B.) tablet ui eine Verbesserung darstellen. Ich habe die Änderungen auch entsprechend dokumentiert. Wenn gewünscht kann ich das auch auf anderem Wege zur Verfügung stellen?

gruss,
Johannes

Dr. Boris Neubert · 20 Juni 2015, 20:46:05

Hallo,

prinzipiell ist es denkbar. Aber ich habe die Änderungen nicht verstanden und dann die Lust verloren, mich damit zu befassen.

Wichtig wäre mir zuerst einmal, dass die neue Version auf Abwärtskompatbilität getestet wird. Magst Du das organisieren?

Verstehen kann ich die Änderungen dann immer noch.

Viele Grüße
Boris

viegener · 21 Juni 2015, 16:12:28

Zitat von: Dr. Boris Neubert am 20 Juni 2015, 20:46:05
Wichtig wäre mir zuerst einmal, dass die neue Version auf Abwärtskompatbilität getestet wird. Magst Du das organisieren?

Kann ich gerne machen, allerdings benötige ich ein paar Anhaltspunkte wie das gemacht werden sollte. Gibt es eine Gruppe von Testern, denen man das Modul (mit den Änderungen) übergibt und die Ergebnisse einsammelt. Oder erstellt man einen Thread im Developer-Board mit den Änderungen und Aufruf zum testen?

Sorry, wenn das doof gefragt ist, aber ich habe so erstmal weder im wiki noch im Forum dazu etwas gefunden...

Achso: Bisher habe ich keine Berechtigung im Developer-Board, aber dazu kenne ich zumindest den Workflow

ich kann wenn gewünscht auch noch mehr Hintergrund zu den Änderungen geben...

viegener · 21 Juni 2015, 16:16:05

Zitat von: viegener am 21 Juni 2015, 16:12:28
Kann ich gerne machen, allerdings benötige ich ein paar Anhaltspunkte wie das gemacht werden sollte. Gibt es eine Gruppe von Testern, denen man das Modul (mit den Änderungen) übergibt und die Ergebnisse einsammelt. Oder erstellt man einen Thread im Developer-Board mit den Änderungen und Aufruf zum testen?

Oder ist das geneint, was im fhemwiki als "How to write a patch" beschrieben ist?