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