FHEMWEB Widgets

rudolfkoenig · 19 September 2017, 14:17:17

Da mir einerseits die Anzahl der automatisch aber sinnlos geladenen .js Dateien langsam zu viel wird, andererseits auch nicht im Weg stehen will, wenn weitere Widgets erstellt werden (siehe diesen Beitrag), moechte ich Folgendes zur Diskussion stellen:

- es werden keine fhemweb_*.js Dateien implizit von FHEMWEB geladen
- fhemweb.js laedt, falls noetig, die fhemweb_.js Datei. Der Dateiname wird abgeleitet einerseits von der Liste der verfuegbaren fhemweb_*.js Dateien, was FHEMWEB in <body> als data-availableJs Attribut reinschreibt, andererseit vom benoetigten widget-Namen (bis auf dem ersten - im Widget-Namen). Einmalige Ausnahme: fuer alles was mit uzsu anfaengt, wird fhemweb_uzsu.js geladen.
- die fhemweb_*.js Dateien muessen ab sofort einen Abschnitt enthalten in der Form:

Code Auswählen

/*
=pod

=begin html
<li>if the modifier is of the form ":uzsuSelect,val1,val2,...",
...
</li>
=end html

=begin html_DE
<li>Ist der Modifier ":uzsuSelect,val1,val2,...", dann ist es
...
</li>
=end html_DE

=cut
*/

was jeweils Doku fuer den widgetOverride Abschnitt von 01_FHEMWEB.pm enthaelt.
Die Logik fuers Zusammenkleben muss in FHEM/98_help.pm, contrib/commandref_*.pm und evtl. contrib/pre-commit implementiert werden, die Aenderung der contrib/* Dateien wuerde ich uebernehmen.

Sieht jemand ein Problem mit dieser Umbau?

betateilchen · 19 September 2017, 14:37:06

Zitat von: rudolfkoenig am 19 September 2017, 14:17:17
Da mir einerseits die Anzahl der automatisch aber sinnlos geladenen .js Dateien langsam zu viel wird

Oh kniet mit mir, dies seltne Glück zu preisen!
Halleluja!

Markus Bloch · 19 September 2017, 14:41:21

Habe ich generell kein Problem mit.

Ich würde in diesem Zuge vorschlagen die Widget-Doku in FHEMWEB als reine Auflistung zu machen und nicht immer diesen Satz "if the modifier is of the form ..." mitzuschleppen.

Einfach die Widget-Syntax und dahinter die Beschreibung.

also Beispiel:

Code Auswählen

=begin html
<li><b><code>:uzsuSelect,val1,val2,...,valN</code> - shows a button bar with a button per value where multiple values can be selected. The result is a comma separated list of all selected values.
</li>
=end html

Zitat von: betateilchen am 19 September 2017, 14:37:06
Oh kniet mit mir, dies seltne Glück zu preisen!
Halleluja!

@betateilchen: Es geschehen noch Wunder. Man muss nur dran glauben.

Ellert · 19 September 2017, 17:08:59

Es muss dann eine fhemweb_*.js pro Widget geben, sehe ich das richtig?

rudolfkoenig · 19 September 2017, 18:41:29

ZitatOh kniet mit mir, dies seltne Glück zu preisen!

Da die Umstellung doch komplizierter ist, als ich dachte, moechte ich bitten die zwei angehaengten Dateien zu testen.
fhem.cfg.demo scheint zu funktionieren, ein FLOORPLAN demo auch.

@justme1968: kannst du bitte die folgenden Zeilen:

Code Auswählen

   $data{FWEXT}{"readingsGroup"}{SCRIPT} = "fhemweb_readingsGroup.js";
   $data{FWEXT}{"readingsHistory"}{SCRIPT} = "fhemweb_readingsHistory.js";

in den jeweiligen Modul_Initialize() einfuegen, dann kann ich sie in FHEMWEB.pm loeschen.

ZitatEs muss dann eine fhemweb_*.js pro Widget geben, sehe ich das richtig?

Nicht unbedingt, man kann auch mehrere in einem zusammenfassen, wenn alle Modifier mit dem gleichen Praefix anfangen, und durch ein Bindestrich getrennt sind. In dem verlinkten Fall koennte man die Modifier in icon-label, icon-switch und icon-selectRadio umbenennen, und alles in fhemweb_icon.js implementieren/dokumentieren.

Markus Bloch · 19 September 2017, 18:55:35

Zitat von: rudolfkoenig am 19 September 2017, 18:41:29
@justme1968: kannst du bitte die folgenden Zeilen:
Code Auswählen Erweitern
$data{FWEXT}{"readingsGroup"}{SCRIPT} = "fhemweb_readingsGroup.js"; $data{FWEXT}{"readingsHistory"}{SCRIPT} = "fhemweb_readingsHistory.js";
in den jeweiligen Modul_Initialize() einfuegen, dann kann ich sie in FHEMWEB.pm loeschen.

Das gilt dann wahrscheinlich auch für FB_CALLLIST, da ich dort ebenfalls das Frontend mit fhemweb_fbcalllist.js ergänze.

Dr. Boris Neubert · 19 September 2017, 19:26:00

Habe heute morgen gelesen, dass es wohl einen Mechanismus gibt, dass der Browser Javascript-Module nach Bedarf lade. Bei Chrome sei dies Standard, bei Firefox und Safari müsse man es aktivieren. Wollte diese Info hier reinwerfen, habe aber keine Ahnung, wie das funktioniert.

Grüße
Boris

rudolfkoenig · 19 September 2017, 20:20:26

@Markus: fbcalllist definiert eine createFn Funktion, das kann ich bei Bedarf laden, ich erkenne es an dem Widget-Modifier. Die readings* Dateien definieren jeweils eine updateLine Funktion, diese kann ich nicht automatisch laden, da ich nicht weiss, wann.

@Boris: ein bisschen mehr Details brauche ich schon. JavaScript Dateien kann man via JavaScript natuerlich laden (siehe loadScript() in fhemweb.js, fuegt ein <script> Tag zu <head> hinzu), aber autmatisch ist das nicht. Ich wuesste auch nicht, woran ein Browser erkennen soll, dass er was laden muss.

Dr. Boris Neubert · 19 September 2017, 21:19:08

Heise schreibt:

Das jüngste Chrome-Update auf Version 61
bringt eine Menge Tuning vor allem für Entwick-
ler mit. Als erster Browser setzt Chrome nun
standardmäßig das mit ECMAScript 6 einge-
führte Modulsystem um: Statt komplette Java -
Script-Dateien importieren zu müssen, lassen
sich benötigte Funktionen aus Modulen nachla-
den. Der Code bleibt so besser gekapselt, dop-
pelter Code lässt sich vermeiden. Firefox und
Edge können JavaScript-Module zwar grund-
sätzlich auch ausführen – diese Option ist aber
in den Voreinstellungen ausgeschaltet.

Markus Bloch · 19 September 2017, 21:39:50

Damit würde ich vorsichtig sein, da die ECMAScript-Spezifikation auf mobilen Geräten nicht durchgängig unterstützt wird. Das habe ich bereits leidlich bei der FHEM Statistik erfahren müssen, als ich ECMAScript-Features nutzen wollte, die auf dem PC problemlos funktionieren, aber auf Tablet/Smartphone nicht.

Gruß
Markus

justme1968 · 20 September 2017, 00:22:14

@rudi: ich habe die FWEXT SCRIPT zeilen für readingsGroup und readingsHistory eingecheckt. das ist aber noch nicht die ganze lösung. der js code für beide wird damit dann ja immer noch auf jeder seite geladen auch wenn es weder eine readingsGroup noch eine readingsHistory auf der seite gibt.

ich habe auf die schnelle versucht für beide jeweils eine leere createFn einzubauen. das reicht aber nicht weil beide noch nicht auf die neuen widgets umgestellt sind und den html code noch auf perl seite erzeugen. ohne fhemwidget wird aber FW_replaceWidget nicht aufgerufen und der code nicht geladen.

ich habe gerade noch keine idee wie man das erst mal beheben kann. die readingsGroup auf fhemwidget umzustellen ist eine grössere sache da einiges an informationen aus der perl seite gebraucht wird um den html code zu erzeugen.

ein zweites problem habe ich mit den uzsu widgets: bei uzsuTimerEntry und uszu kann man in der widget definition per setList oder widgetOverride angeben welches widget neben der eigentlichen timer auswahl zusätzlich für die auswahl des ziel zustandes verwendet werden soll:

Code Auswählen

define uzsuEntry dummy
attr uzsuEntry room uzsu 
attr uzsuEntry setList state:uzsuTimerEntry,colorpicker,HUE,0,1,255
attr uzsuEntry webCmd state

aktuell prüfe ich dort im code ob es in FW_widgets eine createFn für das widget gibt und rufe diese auf. das funktioniert natürlich nicht wenn der js code noch nicht geladen ist.

hier wäre es hilfreich wenn der code aus fhemweb.js zum nachladen aus FW_replaceWidget extrahiert und in eine eigene auch von aussen verwendbare routine gesteckt wird. ich komme aber diese woche nicht mehr dazu etwas zu testen und vorzuschlagen da ich erst mal die jeweilige createFn selber auf asynchron umbauen muss.

Ellert · 20 September 2017, 00:43:03

Ich habe getestet und es funktioniert, soweit es die von mir beizusteuernden Icon-Widgets betrifft.

Die Widgets werden allerdings deutlich langsamer aufgebaut.

rudolfkoenig · 23 September 2017, 13:15:34

Zitatdie readingsGroup auf fhemwidget umzustellen ist eine grössere sache da einiges an informationen aus der perl seite gebraucht wird um den html code zu erzeugen.

Dann bleibt es erstmal so. Es ist besser nur 2 statt 8 Dateien zu laden, und die beiden auch nur dann, wenn man readingsGroup und readingsHistory nutzt.

Zitathier wäre es hilfreich wenn der code aus fhemweb.js zum nachladen aus FW_replaceWidget extrahiert und in eine eigene auch von aussen verwendbare routine gesteckt wird.

Habs gemacht, und die neue fhemweb.js hier angehaengt. Die Function ist

Code Auswählen

FW_callCreateFn(elName, devName, vArr, currVal, set, params, cmd, finishFn)
Rueckgabewert gibt es keins, finishFn wird mit (widgetName, newElement) aufgerufen, beide koennen aber null sein, den Fallback mit select oder <a> habe ich nicht eingebaut, da ich unsicher war, ob du das brauchst. Die anderen Parameter landen beim createFn.

justme1968 · 24 September 2017, 21:04:30

danke. das schaut gut aus. ich hoffe ich komme diese woche dazu es einzubauen.

rudolfkoenig · 02 Oktober 2017, 13:50:05

Zitatdanke. das schaut gut aus. ich hoffe ich komme diese woche dazu es einzubauen.

Ping

justme1968 · 02 Oktober 2017, 15:33:03

pong

ich habe eine version vom fhemweb_uzsu.js die mit deiner neuen FW_callCreateFn zu funktionieren scheint.

die frage ist jetzt nur ob ich im code noch einen fallback auf die alte version vorsehe oder wir das einchecken so koordinieren das alles an einem tag (z.b. morgen) eingecheckt wird.

rudolfkoenig · 02 Oktober 2017, 16:00:02

Ich bin fuer Koordinieren und kein Fallback.
Sag mir hier Bescheid, nachdem du es eingecheckt hast.

justme1968 · 02 Oktober 2017, 16:10:01

bescheid...

hab es eben eingecheckt

Markus Bloch · 02 Oktober 2017, 16:11:39

Muss dann auch heute Abend noch die geänderten fhemweb_*.js Dateien mit integrierter Commandref-Doku vorhanden sein?

Gruß
Markus

rudolfkoenig · 02 Oktober 2017, 17:02:00

Habe meine Aenderungen jetzt auch eingecheckt.

Ich werde die Doku morgen selbst in die einzelnen fhemweb_*.js Dateien rueberkopieren, aus 01_FHEMWEB.pm loeschen und commandref_join.pl anpassen.

Bleibt dann noch help.pm uebrig.

justme1968 · 02 Oktober 2017, 18:17:27

@rudi: ich glaube in fhemweb.js zeile 1079 fehlt noch ein var vor newEl.

Benni · 03 Oktober 2017, 09:42:17

Ist das folgendes "Problem" (s.a. Screenshot)?

Ausgabe in der Entwicklerkonsole im Chrome:

Code Auswählen


fhemweb.js:1079 Uncaught ReferenceError: newEl is not defined
    at FW_replaceWidget (fhemweb.js:1079)
    at FW_detailSelect (fhemweb.js:1034)
    at HTMLSelectElement.<anonymous> (fhemweb.js:105)
    at Function.each (jquery.min.js:2)
    at m.fn.init.each (jquery.min.js:2)
    at HTMLDocument.FW_jqueryReadyFn (fhemweb.js:104)
    at j (jquery.min.js:2)
    at Object.fireWith [as resolveWith] (jquery.min.js:2)
    at Function.ready (jquery.min.js:2)
    at HTMLDocument.J (jquery.min.js:2)

Zitat von: justme1968 am 03 Oktober 2017, 09:43:24
ja. var davor schreiben behebt es.

Funktioniert!

justme1968 · 03 Oktober 2017, 09:43:24

ja. var davor schreiben behebt es.

rudolfkoenig · 03 Oktober 2017, 12:50:27

Habe die Doku umgebaut, und die geaenderten fhemweb_*.js Dateien eingecheckt.
Diese Aenderung ist eine Ausnahme, ich will die Verantwortung fuer diese Dateien damit nicht uebernehmen, nur das Verschieben der Doku vereinfachen.

Die Verlagerung der Doku ist generisch, und passiert mit der Zeile

Code Auswählen


was in aehnlicher Form auch von anderen Modulen verwendet werden kann.

Verbliebene Probleme:
*** EN www/pgm2/fhemweb_colorpicker.js: No document text found
*** EN www/pgm2/fhemweb_fbcalllist.js: No document text found
*** EN www/pgm2/fhemweb_readingsGroup.js: No document text found
*** EN www/pgm2/fhemweb_readingsHistory.js: No document text found
*** EN www/pgm2/fhemweb_weekprofile.js: No document text found

Wenn ich es richtig verstehe, muesste fhemweb_readings*.js umbenannt werden, und die anderen dokumentiert werden.
Da eine Umbenennung von dem FHEM update Mechanismus nicht ohne Weiteres unterstuetzt wird, muesste ich in contrib/fhemupdate.control.fhem zwei MOV Zeilen einfuegen, nachdem die Umbenennung erfolgt ist.

Damit die Fehlermeldungen solange nicht alle nerven, habe ich diese Pruefungen deaktiviert.

Patchvorschlag fuer 98_help.pm:

Code Auswählen

Index: FHEM/98_help.pm
===================================================================
--- FHEM/98_help.pm    (revision 15175)
+++ FHEM/98_help.pm    (working copy)
@@ -184,6 +184,15 @@
         $skip = 1;
      } elsif(!$skip) {
         $output .= "$l\n";
+        if($l =~ m,INSERT_DOC_FROM: ([^ ]+)/([^ /]+) ,) {
+          my ($dir, $re) = ($1, $2);
+          if(opendir(DH, $dir)) {
+            foreach my $file (grep { m/^$2$/ } readdir(DH)) {
+              $output .= cref_search("$dir/$file", $lang);
+            }
+            closedir(DH);
+          }
+        }
      }
    }
    return $output;

justme1968 · 03 Oktober 2017, 13:58:11

ich habe die colorpicker doku eben eingecheckt. dabei ist mir aufgefallen:
- vielleicht wäre es sinnvoll die einzelnen abschnitte mit jeweils einer zwischenüberschrift zu versehenen?
das würde es übersichtlicher machen und auch erlauben für die unterschiedlichen widgets zusätzlichen
erklärenden text vor oder hinter die jeweilige liste zu setzen.
- das würde auch helfen wenn nicht beide sprachen gibt. die formatierung der meldung in diesem fall
ist auch noch nicht korrekt. der link zeigt auch noch ins leere.
- ich habe am ende des colorpicker blocks noch einen hinweis auf das wiki gesetzt. die formatierung ist
aber nicht optimal da es aktuell nur eine lange bullet liste ist. s.o.
- der readingsGroup und readingsHistory js code beinhaltet aktuell keine widgets die sich mit widgetOverride
nutzen lässt sondern nur coder der intern verwendet wird. d.h. wenn es keine doku gibt ist das ok.
das gleiche gilt für fbcalllist und weekprofile. in allen fällen ist es eher code der zur darstellung in der raum
(oder detail) ansicht nötig ist. das gleiche wird demnächst für ein webcam device der fall sein. d.h. es gibt js code
der geladen werden muss wenn ein device verwendet wird ohne das es etwas mit widgets oder widgetOverride zu
tun hat. das mit dem umbenennen ist deshalb glaube ich zumindest aktuell auch nicht nötig.

- der : am anfang der zeilen ist eigentlich redundant
- die formatierung der parameter ist nicht überwall einheitlich. manche einträge verwenden <...>, andere lassen die eckigen klammern weg
- im einleitenden text fehlt noch ein s hinter modifiers: Following is the list of known modifiers

rudolfkoenig · 03 Oktober 2017, 17:47:48

Zitat- vielleicht wäre es sinnvoll die einzelnen abschnitte mit jeweils einer zwischenüberschrift zu versehenen?

Bin unsicher, bei meinen "einzelnen" Widgets wuerde es komisch ausschauen. Habe aber nichts dagegen, falls du bei Colorpicker oder UZSU sowas machst.

Zitatdas mit dem umbenennen ist deshalb glaube ich zumindest aktuell auch nicht nötig.

Und wann soll ich eine Warnung bei nicht vorhandenen Doku ausgeben?

Zitat- der : am anfang der zeilen ist eigentlich redundant
- die formatierung der parameter ist nicht überwall einheitlich. manche einträge verwenden <...>, andere lassen die eckigen klammern weg
- im einleitenden text fehlt noch ein s hinter modifiers: Following is the list of known modifiers

Danke, habe es in meinen Dateien angepasst.

justme1968 · 03 Oktober 2017, 17:57:15

ZitatBin unsicher, bei meinen "einzelnen" Widgets wuerde es komisch ausschauen. Habe aber nichts dagegen, falls du bei Colorpicker oder UZSU sowas machst.

so lange das <ul>...</ul> von comandref_join erzeugt wird kann man dazwischen nicht viel machen. wenn die jeweilige doku selber die listen auf und zu macht und commandref_join dann einfach alles aneinander hängt. wäre das flexibler.

Code Auswählen

Und wann soll ich eine Warnung bei nicht vorhandenen Doku ausgeben?
das problem ist das es nicht nur zwei sondern drei zustände gibt die unterschieden werden müssen:
- doku da
- doku nicht nötig
- keine doku da

wenn für 2. ein leeres =pod/=cut oder =begin html/=end html ok ist könnte man es so machen.

hattest du das mit den unschönen und falschen link bei nicht vorhander deutschen doku gesehen?

rudolfkoenig · 03 Oktober 2017, 18:23:55

Zitatso lange das <ul>...</ul> von comandref_join erzeugt wird kann man dazwischen nicht viel machen.

Das verstehe ich nicht. Ich sehe keine von commandref erzeugten <ul>'s und selbst wenn, muesste man doch dazwischen was machen koennen.

Zitatwenn für 2. ein leeres =pod/=cut oder =begin html/=end html ok ist könnte man es so machen.

Waere fuer mich ok.

Zitathattest du das mit den unschönen und falschen link bei nicht vorhander deutschen doku gesehen?

Nein, ich sehe nur keine Doku, siehe Anhang. Habs mit commandref_join.pl und help (gepatchte Variante) probiert.

rudolfkoenig · 03 Oktober 2017, 18:26:54

Zitatunschönen und falschen link

Unschoen finde ich es nicht, falsch ja: es heisst href und nicht hef

justme1968 · 03 Oktober 2017, 18:46:57

ja... die <ul> werden nicht von commandref_join erzeugt sondern stehen in 01_FHEMWEB um die  zeile.

naja... nicht viel machen heisst man keine zwischenüberschrift auf höhe der bullets (ohne bullet) erzeugen.

readings.*js habe ich mit leerem =pod/=cut eingecheckt das scheint zu funktionieren.

mein link war falsch. seltsamer weise hat safari trotzdem einen anklickbaren link draus gemacht. aber den habe ich garnicht gemeint

ich hatte in zeile 177 das !$jsFile aus dem if raus genommen um die meldungen in der ausgabe zu bekommen.

und in zeile 178 ebenso. weil sonst bei fehlender deutschen doku der link auf die englische fehlt.

aber dann kommt so etwas wie auf meinem screenshot dabei raus.

wenn das garnicht beabsichtig dann ist das natürlich nicht relevant.

Ellert · 03 Oktober 2017, 20:00:09

@justme1968
Würdest Du die Doku zu uzsuDropDown anpassen, die Parameter val1,val2,... funktionieren ja nicht, weil eine feste Liste vorgegeben ist.

justme1968 · 03 Oktober 2017, 20:11:21

nö

aber ich hab es repariert

man kann die liste jetzt wie eigentlich vorgesehen angeben.

gruss
andre

zap · 04 Oktober 2017, 10:46:31

Bei mir wird das Slider Widget nicht mehr dargestellt. Kann das etwas mit dem dynamischen Laden der .js Dateien zu tun haben?

Betrifft bei mir ca. 10 Devices (Thermostaten).

rudolfkoenig · 04 Oktober 2017, 11:02:57

Klar. Brauche aber einen Testfall, um es mit sicherheit zu sagen.

zap · 04 Oktober 2017, 12:30:42

Korrigiere mich. Anscheinend wird überhaupt kein Widget mehr angezeigt

Betrifft auch Togglebuttons usw.

Ich habe mal das getestet:

Code Auswählen


define d2 dummy
attr d2 webCmd state
attr d2 setList state:slider,0,1,10

und das

Code Auswählen


define d2 HMCCUDEV mydev
attr d2 webCmd control
attr d2 widgetOverride control:slider,0,1,10

ok, letzteres wirst Du vermutlich nicht nachvollziehen können. Jedenfalls hat das alles bis vor 3 Wochen funktioniert. Dann bin ich in Urlaub gefahren und habe anschließend unvorsichtigerweise ein Update gemacht ...

rudolfkoenig · 04 Oktober 2017, 13:11:35

Ich habe dein dummy Beispiel getestet, bei mir tut es, siehe Anhang.
Hast du alles auf dem aktuellen Stand (insb. 01_FHEMWEB.pm und fhemweb.js)?
Verwendest du ueberhaupt FHEMWEB?

Verwendest du Bitdefender?

rudolfkoenig · 04 Oktober 2017, 13:26:49

Zitatund in zeile 178 ebenso. weil sonst bei fehlender deutschen doku der link auf die englische fehlt.

aber dann kommt so etwas wie auf meinem screenshot dabei raus.

Das wuerde ich zunaechst noch auskommentiert lassen, und ich bitte die Teilnehmer beide Sprachen zu pflegen

Ellert · 04 Oktober 2017, 14:05:16

@justme1968:

Zitatso lange das <ul>...</ul> von comandref_join erzeugt wird kann man dazwischen nicht viel machen. wenn die jeweilige doku selber die listen auf und zu macht und commandref_join dann einfach alles aneinander hängt. wäre das flexibler.

Man kommt aus dem ul-Tag heraus mit

Code Auswählen


<!--<ul>-->
</ul>
ausgerückter Kommentar
<ul>
<!--</ul>-->

commandref_join zählt die kommentierten Tags mit, Html interpretiert sie aber nicht.

Ich hoffe das bleibt so.

justme1968 · 04 Oktober 2017, 14:42:57

ja klar geht das. aber nur so lange sich an commandref_join in dieser hinsicht nichts ändert.

wenn rudi das zusichert habe ich kein problem damit.

Ellert · 04 Oktober 2017, 16:53:25

@rudolfkoenig:
Ich würde jetzt gern einige Widgets nach /pgm2 einchecken, habe ich die Erlaubnis dazu? Siehe https://forum.fhem.de/index.php/topic,75696.0.html

zum Thema: Text aus dem ul-Tag auszurücken

Wird die Möglichkeit es wie folgt zu machen dauerhaft Bestand haben?

Zitat

</ul>
ausgerückter Kommentar
<ul>

rudolfkoenig · 04 Oktober 2017, 17:28:06

ZitatIch würde jetzt gern einige Widgets nach /pgm2 einchecken, habe ich die Erlaubnis dazu?

Ja, das war Sinn der ganzen Uebung hier.

ZitatWird die Möglichkeit es wie folgt zu machen dauerhaft Bestand haben?

Das ist nicht die feine Art, und gefaellt mir nicht wirklich, also: nein. Wieso kann man die Doku nicht innerhalb der <ul> durchfuehren?
Wenn triftige Gruende dagegen sprechen, dann waere es besser die Doku von FHEMWEB zu loesen, und in einem komplett anderen Abschnitt zu verlegen.

Ellert · 04 Oktober 2017, 18:21:52

Ich wollte nicht ohne zu fragen einchecken.

ZitatWieso kann man die Doku nicht innerhalb der <ul> durchfuehren?

Zwingend notwendig ist es nicht, jedoch hätte man die Möglichkeit zu einer Gruppe von Widgets einleitend Dinge zu formulieren, die allen Widgets der Gruppe gemeinsam sind und das in der richtigen Struktur.

Eine nicht ausgerückte Einleitung könnte leicht zum vorherigen Widget gerechnet werden, siehe Anlage.

ZitatWenn triftige Gruende dagegen sprechen, dann waere es besser die Doku von FHEMWEB zu loesen, und in einem komplett anderen Abschnitt zu verlegen.

Das die Widgets unter widgetOverride zu finden sind hat sicherlich historische Gründe.
Meiner Meinung nach sind sie dort schwer zu finden.
Inzwischen können die Widgets auch über andere Attribute (setList, eventMap) and Readings gebunden werden.
Das würde für einen extra Abschnitt sprechen, mit Erwähnung im Inhaltsverzeichnis.

Die Frage ist allerdings, ob das hohe Priorität haben sollte.

Markus Bloch · 04 Oktober 2017, 18:31:07

Ansonsten mach die Einleitung kursiv, dann hebt es sich ab.

Gruß
Markus

zap · 05 Oktober 2017, 08:30:11

Zitat von: rudolfkoenig am 04 Oktober 2017, 13:11:35
Ich habe dein dummy Beispiel getestet, bei mir tut es, siehe Anhang.
Hast du alles auf dem aktuellen Stand (insb. 01_FHEMWEB.pm und fhemweb.js)?

update check sagt "Nothing to do"

Zitat
Verwendest du ueberhaupt FHEMWEB?

Ja.

Zitat
Verwendest du Bitdefender?

Nein.

Versuche mit unterschiedlichen Browsern und Löschen von Cache usw. hat alles nichts gebracht. Ich vermute, dass meine FHEM Installation irgendwie zerhauen ist. Habe eine korrupte Datei bei Tablet UI gefunden. Nicht auszuschließen, dass die SD-Karte meines Raspis den Geist aufgibt. Werde mal einige Verzeichnisse aus einem Backup wieder herstellen.

betateilchen · 10 Oktober 2017, 12:19:04

Zitat von: rudolfkoenig am 03 Oktober 2017, 12:50:27
Patchvorschlag fuer 98_help.pm:

mit dem morgigen Update verfügbar.