(http://up.picr.de/23526416ot.png)
Tut das denn not?
- colorpicker - brauch ich nicht
- fbcalllist - brauch ich nicht
- knob - brauch ich nicht
- readings(Group|History) - brauch ich nicht
- sortable = ???
- uzsu = ???
Kann man solchen Kram nicht "nur dann laden, wenn er auch wirklich gebraucht wird" und nicht zwingend?
Sehr gerne.
Jetzt musst nur sagen, woran FHEMWEB es erkennen soll, ob du es brauchst.
Und das moeglichst einfach und effizient.
Liese sich das nicht in fhemweb.js lösen? Es müsste nur wissen, welche Widgets nachladbar sind.
in FW_replaceWidgets() müsste man halt vorher prüfen ob das Widget bereits registriert ist, wenn nicht, und es ist nachladbar, dann per XHR nachladen.
Gruß
Markus
Zitat von: rudolfkoenig am 27 Oktober 2015, 15:20:02
Jetzt musst nur sagen, woran FHEMWEB es erkennen soll, ob du es brauchst.
Gegenfrage: Warum muss FHEMWEB das überhaupt selbst erkennen?
Wenn ein Benutzer einen knob haben will, soll er das Skript in das entsprechende Attribut der Webinstanz eintragen. Genau wie ich das für den codemirror oder für das autocompleteoff auch mache. Genau dafür wurde dieses Attribut doch eingeführt.
Auf Verdacht einfach mal alles zu laden, was VIELLEICHT gebraucht werden könnte, halte ich jedenfalls für die fragwürdigste aller möglichen Lösungen.
ZitatGegenfrage: Warum muss FHEMWEB das überhaupt selbst erkennen?
Damit Module knob/colorpicker/etc ohne Benutzer-Interaktion anbieten koennen.
Zitat von: betateilchen am 27 Oktober 2015, 16:52:18
Warum?
Damit es sofort funktioniert ohne erst in die Doku schauen zu müssen, was man noch machen muss um ein Modul vernünftig zum laufen zu bekommen. Reduziert den Frustfaktor bei Newbies ungemein ;-)
Mich als Nicht-Newbie frustiert der gesamte Overhead, der da produziert wird. Und dieser Frust ist dauerhaft, im Gegensatz zu dem Frust der Newbies, der sich im Laufe des Lernprozesses durchaus reduziert.
Warum kann man in FHEMWEB nicht modulseitig eine Standardliste solcher Skripte im Attribut "JavaScripts" hinterlegen und ich kann dann die Skripte, die ich nicht brauche, einfach aus der Liste rausschmeißen, wenn ich das möchte?
das sollte auf jeden Fall automatisch gehen ohne das ein anwender noch etwas konfigurieren muss.
nur laden wenn gebraucht müsste eigentlich möglich sein.
andererseits sollte das laden aber auch nicht wirklich problematisch sein wenn das cachen funktioniert.
wo genau siehst du frustrierenden overhead? lässt sich der in zahlen ausdrücken?
Designvorschlag:
Jedes Modul registriert seine AddOns selber :-)
Zitat von: justme1968 am 27 Oktober 2015, 17:48:15
lässt sich der in zahlen ausdrücken?
42
Zitat von: Wuppi68 am 27 Oktober 2015, 17:49:55
Jedes Modul registriert seine AddOns selber :-)
Im Prinzip eine gute Idee, aber nicht zielführend. Beispiel colorpicker: Nur weil ein Modul den anbietet, heißt das noch lange nicht, dass ich als Benutzer den auch nutzen will.
Noch schlimmer die fbcalllist - die braucht echt nur eine Minderheit und auch die Anzahl möglicher Module, die darauf aufsetzen, ist furchtbar überschaubar. Aber trotzdem wird das Script grundsätzlich geladen.
Zitat von: betateilchen am 27 Oktober 2015, 18:19:04
Noch schlimmer die fbcalllist - die braucht echt nur eine Minderheit und auch die Anzahl möglicher Module, die darauf aufsetzen, ist furchtbar überschaubar. Aber trotzdem wird das Script grundsätzlich geladen.
Hätte ich auch gerne anders gemacht. ;-)
Ich habe gerade mal geschaut, inwiefern man umkompliziert die Skripte nachladen kann. Das Problem ist, dass man nicht mit Sicherheit kann welche Skripte nachgeladen werden müssen.
fhemweb_fbcalllist.js, fhemweb_uzsu.js, fhemweb_knob.js, ... lassen sich im FW_replaceWidgets() erkennen, wenn als 1. Value die entsprechenden Widgetnamen stehen, bei fhemweb_readingsGroup.js funktioniert das nicht.
Man kann aber nicht erkennen innerhalb von FW_replaceWidgets(), ob das erste Argument für ein Kommando/Attribut ein Widget ist, oder nur einfach ein normaler Wert für die Dropdown List ist.
Einfacher Versuch:
function
FW_replaceWidgets(parent)
{
parent.find("div.fhemWidget").each(function() {
var dev=$(this).attr("dev");
var cmd=$(this).attr("cmd");
var rd=$(this).attr("reading");
var params = cmd.split(" ");
var type=$(this).attr("type");
if( type == undefined ) type = "set";
var args = $(this).attr("arg").split(",");
loadScript("pgm2/fhemweb_"+args[0]+".js", function () {
FW_replaceWidget(this, dev, args,
$(this).attr("current"), rd, params[0], params.slice(1),
function(arg) {
FW_cmd(FW_root+"?cmd="+type+" "+dev+
(params[0]=="state" ? "":" "+params[0])+" "+arg+"&XHR=1");
});
});
});
}
Führt aktuell aber auch zu:
fhemweb.js:215 19:03:27.426 Loading script /fhem/pgm2/fhemweb_on.js
fhemweb.js:215 19:03:27.432 Loading script /fhem/pgm2/fhemweb_slider.js
fhemweb.js:215 19:03:27.433 Loading script /fhem/pgm2/fhemweb_colorpicker.js
fhemweb.js:215 19:03:27.436 Loading script /fhem/pgm2/fhemweb_audio.js
fhemweb.js:215 19:03:27.438 Loading script /fhem/pgm2/fhemweb_forward.js
fhemweb.js:215 19:03:27.439 Loading script /fhem/pgm2/fhemweb_readings.js
fhemweb.js:215 19:03:27.441 Loading script /fhem/pgm2/fhemweb_1.js
fhemweb.js:215 19:03:27.444 Loading script /fhem/pgm2/fhemweb_component.jsViele Grüße
Markus
Zitat von: justme1968 am 27 Oktober 2015, 17:48:15
lässt sich der in zahlen ausdrücken?
(http://forum.fhem.de/index.php?action=dlattach;topic=43080.0;attach=39372;image)
Allerdings mit Komprimierung bei der Übertragung...
Als relativer newbie kann ich nur bestätigen, dass es hilft, wenn zumindest FHEMWeb "out-of-the-box" direkt funktioniert und auch Dinge wie colorpicker laufen (auch wenn ich speziell das nicht benutze). Mir ist klar, dass wir kein plug-and-play-System ;) anstreben, aber die Einarbeitungshürden höher zu setzen, sollte nicht das Ziel sein. Ich bin eher ein Fan von Vereinfachung, denn wir haben auch viele Nicht-IT-Leute und profitieren auch von der Breite der Benutzerbasis.
Generell wäre es gut zu wissen, wie gross der overhead ist der erzeugt wird (Speicher vor allem?), damit eine Basis existiert ob es ein Problem gibt, dass gelöst werden sollte? Bei mir sind es 478k (nur js) im pgm2-Verzeichnis und die am Anfang genannten machen keine 40k aus.
Johannes
Was auch zu bedenken ist: ich kenne keine einfache Methode, die mit loadScript nachgeladenen Module zu erneuern, ohne den kompletten Cache zu entfernen. Fuer diese Dateien funktioniert Shift-Ctrl-R nicht.
Wie waere mit einem JavaScriptExclude Attribut?
readingsGroup.js ist noch nicht auf das neue api umgestellt. deshalb geht das automatisch erkennen nicht. hier wird auch der html code komplett auf perl seite erzeugt. d.h. das ist kein widget und für das nachladen müsste man sich einen anderen indikator überlegen.
anhand der zahlen oben ist die frage nach dem overhead aber schon wichtig. die files sind klein. lassen sich gut komprimieren und sollten wenn das caching funktioniert nur minimal ins gewicht fallen.
ich vermute mal das es andere stellen gibt an denen sich mit weniger aufwand mehr optimieren lässt.
ein exclude attribut wäre vermutlich mit dem kleinsten aufwand verbunden.
Für mich ist völlig egal, wie groß so eine Datei ist, mir geht es einfach um die Anzahl an sich.
Zitat von: rudolfkoenig am 27 Oktober 2015, 19:17:02
Wie waere mit einem JavaScriptExclude Attribut?
Immer mehr Attribute machen die Sache auch nicht besser.
Nimm das vorhandene Attribut JavaScript und werte darin aus, ob vor einem scriptname ein + (laden) oder ein - (nicht laden) steht. Aus Kompatibilitätsgründen könnte man "ohne Vorzeichen" als + werten.
Die zusätzlich geladenen Codemirror-Module lassen sich jetzt über das codemirrorParam Attribut steuern.
default's:
{
"matchBrackets":true,
"autoRefresh":true,
"search":true,
"comment":true,
"autocomplete":true,
"autoCloseBrackets":false
}
Im Wiki kann nun nachgelesen werden durch welchen Paramter welches Modul geladen wird, oder welcher Parameter aktiviert werden muss um ein spezielles Modul zu laden / Funktion zu aktivieren.
http://www.fhemwiki.de/wiki/Konfiguration#Syntaxhervorhebung (http://www.fhemwiki.de/wiki/Konfiguration#Syntaxhervorhebung)
Zitat von: betateilchen am 27 Oktober 2015, 19:41:28
Nimm das vorhandene Attribut JavaScript und werte darin aus, ob vor einem scriptname ein + (laden) oder ein - (nicht laden) steht. Aus Kompatibilitätsgründen könnte man "ohne Vorzeichen" als + werten.
Kann man durchaus so machen. Nur hast du dann immer die Arbeit das Attribut erneut zur pflegen, sobald irgend einer ein neues Widget/Javascript eincheckt ;-) Damit liegt der Frustfaktor wieder bei dir.
Aber ich hätte wenigstens eine Möglichkeit, den Frust relativ einfach wieder loszuwerden :)
Fuer Frust-Abbau implementiert:
attr WEB JavaScripts -fhemweb_fbcalllist.js -fhemweb_readingsGroup.js -fhemweb_readingsHistory.js -fhemweb_colorpicker.js -fhemweb_knob.js -fhemweb_sortable.js -fhemweb_uzsu.js
mal sehen wann es den ersten post gibt weil jemand vergessen hat das er mal was deaktiviert hat. :)
Zitat von: rudolfkoenig am 28 Oktober 2015, 13:51:22
Fuer Frust-Abbau implementiert:
funktioniert super, danke :)