Wenn dies dein erster Besuch hier ist, lies bitte zuerst die Hilfe - Häufig gestellte Fragen durch. Du musst dich vermutlich registrieren, bevor du Beiträge verfassen kannst. Klicke oben auf 'Registrieren', um den Registrierungsprozess zu starten. Du kannst auch jetzt schon Beiträge lesen. Suche dir einfach das Forum aus, das dich am meisten interessiert.
Sollen wir eine neue Ebene "meta" einfügen und dort die plugins, mappings und stylings drunter kopieren? Oder ist das egal?
Auch dafür, damit wird die Sache denke ich übersichtlicher und man hat die Dinge, die sehr statisch sind nicht immer "im Weg", mit der Gefahr sie unbeabsichtigt zu ändern.
Gerade habe zwei neue Dinge in's SVN geladen:[INDENT]New Feature: Plugins
New Plugin: colorChooser (based on farbtastic)
Die Detailsichtung muss ich aber auf Sonntag verschieben (es ist 3, morgen FFM..)
Das für die CometVisu wesentlich wichtigere sind die Plugins. Das sind aufwändige Widgets, etc. die mehr Ressourcen nutzen als man jemanden als unnötigen Overhead zumuten möchte. Der colorChooser bringt so eine eigene extra JavaScript Datei, eine CSS und ein paar Bilder mit...
klingt jedenfalls veradammt gut!
Ich weiss nicht, obs eine Rolle spielt, aber schaden tut es bestimmt nicht, wenn der Client nur verwendete Widgets (JS,...) laden muss.
Die Frage, die sich mir nun stellt:
Die visu_config.xml wird auf der obersten Ebene nun immer unübersichtlicher. Sollen wir eine neue Ebene "meta" einfügen und dort die ..
eigentlich habe ich dazu keine echte Meinung: der Anwender darf,soll&muss davon eh nichts sehen -> ergo IMHO eine reine Design-Entscheidung der Entwickler.
Wäre es vielleicht sinnvoll, den Plugins hier noch einen anderen Namen zu geben!? Z.B. Power-Widget, Complex-Widget oder so was in der Art. Sonst könnte es später in den Support-Diskussionen um das Wiregate evt. leicht zu Verwechslungen kommen, ob denn nun ein WG-Plugin oder ein Visu-Plugin gemeint ist !?
Die visu_config.xml wird auf der obersten Ebene nun immer unübersichtlicher. Sollen wir eine neue Ebene "meta" einfügen und dort die plugins, mappings und stylings drunter kopieren? Oder ist das egal?
Und da wir gerade bei der Syntax der visu_config.xml sind, gibt es hier noch Verbesserungsvorschläge? Noch können die Syntax beliebig ändern, da die Nutzerbasis klein genug ist. Nach der öffentlichen Beta wird's schwieriger...
Mir schmeckts nicht so gut die Plugins in die Konfiguration mit aufzunehmen.
Vorrangigst: damit kann der Editor nur die "Plugins" kennen welche der User schon in seiner Konfig verwendet hat (= mehr Konfigurationsaufwand für den User, sei es über die Shell oder - was noch zu implementieren wäre - im Editor).
In meinem Kopf formt sich grade ein etwas anderer Ansatz, ich werf den einfach mal hier rein:
jedes Widget liegt in einer eigenen JS-Datei mit Dateiname = prefix + Widgetname (bspw. "widget_page.js", "widget_colorchooser.js").
Für den normalen Visu-Betrieb lädt die Visu für jedes unique widget das sie im XML findet die entsprechende JS-Datei die all das nachlädt was sie braucht. Das sollte rein performancemäßig keinen wirklich großen Unterschied machen, zumal im Idealfall das Browsercaching greift - und es sowieso nur beim Laden der Seite eine Rolle spielt.
Dafür ist jedes Widget gekapselt, und neue Widgets einfügen ist drag&drop.
Für den Editor-Betrieb gibt es ein PHP-Skript (o.ä.) welches über das widget-Verzeichnis läuft und eine Liste aller verfügbaren Widgets erzeugt, damit im Editor die Auswahl aller Widgets bereitsteht. Auch hier kein Performanceproblem da auch wieder nur zum Ladezeitpunkt wichtig - und die zusätzliche "Serverlast" durch das Skript wäre nur im Editor vorhanden, der ja sowieso nicht täglich zum Einsatz kommen braucht.
Wäre es vielleicht sinnvoll, den Plugins hier noch einen anderen Namen zu geben!? Z.B. Power-Widget, Complex-Widget oder so was in der Art. Sonst könnte es später in den Support-Diskussionen um das Wiregate evt. leicht zu Verwechslungen kommen, ob denn nun ein WG-Plugin oder ein Visu-Plugin gemeint ist !?
Hm, guter Punkt - ich bin sehr für klare Namen, damit es keine unnötigen Verwechslungen gibt.
Das Problem ist hier, dass es nun wirkliche Plugins sind (was die WG-Plugins eigentlich nicht sind, das sind nämlich nur ein paar Skripte).
D.h. entweder fällt uns hier noch ein wirklich guter Name ein ein, oder wir gehen das Risiko des Verwechselns ein (da wir ja im Hinterkopf haben, dass a) die WG Plugins durch Nils Logik-Engine abgelöst werden soll und b) die CometVisu ja nicht WG spezifisch ist).
Sollten wir die Plugins umbenennen wollen, dann hätte ich als Vorschlag für die Runde "Extension".
Mir schmeckts nicht so gut die Plugins in die Konfiguration mit aufzunehmen.
Vorrangigst: damit kann der Editor nur die "Plugins" kennen welche der User schon in seiner Konfig verwendet hat (= mehr Konfigurationsaufwand für den User, sei es über die Shell oder - was noch zu implementieren wäre - im Editor).
Das ist ein Thema, das ich in einer PHP abegfrühstückt sehe, die einfach alle Unterverzeichnisse des plugins-Verzeichnisses dem Editor übergibt (und der darf im Zweifel sogar alle Plugins laden).
Frei nach dem Motto, dass der normale Modus so schlank wie möglich sein soll, der Editor dagegen gerne auf PHP zurückgreifen darf und ggf. auch höhere Laufzeitkosten verursacht.
In meinem Kopf formt sich grade ein etwas anderer Ansatz, ich werf den einfach mal hier rein:
jedes Widget liegt in einer eigenen JS-Datei mit Dateiname = prefix + Widgetname (bspw. "widget_page.js", "widget_colorchooser.js").
Für den normalen Visu-Betrieb lädt die Visu für jedes unique widget das sie im XML findet die entsprechende JS-Datei die all das nachlädt was sie braucht. Das sollte rein performancemäßig keinen wirklich großen Unterschied machen, zumal im Idealfall das Browsercaching greift - und es sowieso nur beim Laden der Seite eine Rolle spielt.
Dafür ist jedes Widget gekapselt, und neue Widgets einfügen ist drag&drop.
Für den Editor-Betrieb gibt es ein PHP-Skript (o.ä.) welches über das widget-Verzeichnis läuft und eine Liste aller verfügbaren Widgets erzeugt, damit im Editor die Auswahl aller Widgets bereitsteht. Auch hier kein Performanceproblem da auch wieder nur zum Ladezeitpunkt wichtig - und die zusätzliche "Serverlast" durch das Skript wäre nur im Editor vorhanden, der ja sowieso nicht täglich zum Einsatz kommen braucht.
Den gänigen JavaScript-Performance-Anleitungen zufolge sollte man tunlichst vermeiden, viele kleine JavaScript Dateien zu laden und statt dessen lieber eine große zu nehmen. (Das hat eigentlich auch eine Auswirkung auf das Package, dass genau diesen Schritt machen sollte - aber das können wir gerne auf eine späte Beta verschieben)
Ansonsten sieht das sehr nach der PHP-für-Plugin-Lösung aus (nur noch einen Schritt weiter).
Meine Meinung, warum es nicht schädlich ist, die normalen Widgets alle in einer normalen JS Datei zu lassen und immer zu laden, ist dass das nur bisschen RAM für etwas ungenutzten JS-Code braucht. Das sonstige Laufzeit-Verhalten wird in keiner Weise beeinträchtigt (nicht einmal der Namespace der vom JS-Interpreter jedes mal neu durchsucht werden muss, da im Objekt gekapselt).
Die Plugins könnten durch zusätzliche JS- und CSS-Dateien dagegen etwas(!) Overhead erzeugen. Aber der Hauptvorteil ist, dass die als Paket in einem eigenen Verzeichnis liegen. Da stelle ich mir dann so Pakete/Plugins wie eine komplette Mediensteuerung vor...
Mal schaun, was die weiteren Meinungen denn so sagen.
TS2, B.IQ, DALI, WireGate für 1wire so wie Server für Logik und als KNX Visu die CometVisu auf HomeCockpit Minor. - Bitte keine PNs, Fragen gehören in das Forum, damit jeder was von den Antworten hat!
Den gänigen JavaScript-Performance-Anleitungen zufolge sollte man tunlichst vermeiden, viele kleine JavaScript Dateien zu laden und statt dessen lieber eine große zu nehmen. (Das hat eigentlich auch eine Auswirkung auf das Package, dass genau diesen Schritt machen sollte - aber das können wir gerne auf eine späte Beta verschieben)
diese Argumentation kenne ich nur im Zusammenhang mit Web-Performance, wobei es darum geht dass ein User im Laufe eines Webseitenbesuches praktisch dauernd neue Seiten öffnet und dabei der Browser jedes mal eine Menge requests an den Server schicken muss, und sei es nur um sie mit 304 (not modified) beantwortet zu bekommen. Da der Browser auch noch eingebaute Limits hat wie viele Anfragen er pro Server parallel abschickt sollte man hier lieber mit wenigen Dateien arbeiten.
Das Szenario bei der Visu ist aber ein anderes wenn man davon ausgeht, dass die Visu einmal geöffnet wird und dann lange offen bleibt. Denn da spielt das Laden der vielen kleinen Dateien keine so große Rolle.
Mein Hauptpunkt war aber, dass ich es ungeschickt finde die explizite Ladeanweisung für Plugins in die Konfiguration mit aufzunehmen.
stimmt, hab ich im SVN jetzt noch mit 171 behoben, und das "Einblenden" auch für den Editor eingefügt. Danke!
Zusätzlich kann man jetzt im Editor auch eine GA eingeben die nicht in der Liste ist.
Das Design dafür ist momentan noch grausam ... ich hab aber auch das Gefühl dass es im usability-Thread im Moment ein wenig stockt, davon würde ich mir noch mehr Input wünschen (auch für diese Art der Elemente).
So, die Trunk-Demo ist jetzt auch wirklich die aktuelle SVN-Version
Aber im FF hab ich damit:
[...]
Hab gerade mal was hochgeladen (ungetestet...) das da hoffentlich hilft. (Wenn keine Verbindung besteht, versucht er auch kein abort() mehr)
TS2, B.IQ, DALI, WireGate für 1wire so wie Server für Logik und als KNX Visu die CometVisu auf HomeCockpit Minor. - Bitte keine PNs, Fragen gehören in das Forum, damit jeder was von den Antworten hat!
diese Argumentation kenne ich nur im Zusammenhang mit Web-Performance, wobei es darum geht dass ein User im Laufe eines Webseitenbesuches praktisch dauernd neue Seiten öffnet und dabei der Browser jedes mal eine Menge requests an den Server schicken muss, und sei es nur um sie mit 304 (not modified) beantwortet zu bekommen. Da der Browser auch noch eingebaute Limits hat wie viele Anfragen er pro Server parallel abschickt sollte man hier lieber mit wenigen Dateien arbeiten.
Stimmt, dass uns das nicht so stark beißt.
Wie ist denn der Lage bei einem Smartphone-User (der Worst-Case öfters mal die Verbindung aufbaut, da mal schnell nach dem Status geschaut werden soll, und außerdem eine langsame Verbindung, da der gerade mit grenzwertigem GSM auf der Berghütte sitzt)? (Mangels Smartphone kann ich das nicht beantworten...)
Mein Hauptpunkt war aber, dass ich es ungeschickt finde die explizite Ladeanweisung für Plugins in die Konfiguration mit aufzunehmen.
Na wenn dass Deine Sorge ist: wie wäre es statt explizitem mit implizitem Laden?
D.h. wenn die templateengine ein Widget nicht kennt, könnte die ja probieren dieses als Plugin zu laden (diese Vorgehen habe ich nicht getestet, kann mir aber vorstellen, dass das funktionieren könnte).
Man verliert nur die Möglichkeit für dieses Plugin globale Einstellungen zu machen (aktuell nicht implementiert - und vermutlich auch nicht wirklich wichtig, da man ja die Widget spezifischen Einstellungen noch hat)
TS2, B.IQ, DALI, WireGate für 1wire so wie Server für Logik und als KNX Visu die CometVisu auf HomeCockpit Minor. - Bitte keine PNs, Fragen gehören in das Forum, damit jeder was von den Antworten hat!
Mit "Plugin" hab ich jetzt nicht soviel Schmerz, weil der Anwender davon im Normalfall ja nichts mitbekommen wird. Visu release x wird Funktion Y haben, der Rest ist eher entwicklergespräch und da werden wir schon unterscheiden können
Man kann ja im öffentlichen Sprech ein bisschen darauf achten und das deutlich mit Visu oder js "prefixen"..
r172:
- im Chromium gehen die Edit-Dropdowns jetzt seit dem letzten Update nur noch "irgendwann"
- im FF geht kein Ok mehr -> hat aber evtl. damit zu tun:
- Die normale Visu sagt im FF jetzt zwar keine JS-Fehler mehr, aber es steht nur noch loading da ?
Evtl. hab ich das irgendwas an der config.xml versaut?
- Die normale Visu sagt im FF jetzt zwar keine JS-Fehler mehr, aber es steht nur noch loading da ?
Evtl. hab ich das irgendwas an der config.xml versaut?
Ich hab irgendwo im Kopf dass bei xml alle Attribute und tags lowercase sein sollen. Soweit richtig. Das Plugin für den Farbwähler ist aber camelcase - deswegen kommt es dann zu Problemen beim Benutzen des Plugins.
Wahrscheinlich am besten das Verzeichnis plugins/colorChooser, den plugins-Eintrag in der XML und den Namen des Plugins in plugins/colorChooser/structure_plugin.js auf lowercase umzustellen - denn ich würde annehmen dass die DOMDocument-lib von PHP uns die Tags immer wieder auf lowercase stellen wird.
Wir verarbeiten personenbezogene Daten über die Nutzer unserer Website mithilfe von Cookies und anderen Technologien, um unsere Dienste bereitzustellen. Weitere Informationen findest Du in unserer Datenschutzerklärung.
Indem Du unten auf "ICH stimme zu" klickst, stimmst Du unserer Datenschutzerklärung und unseren persönlichen Datenverarbeitungs- und Cookie-Praktiken zu, wie darin beschrieben. Du erkennst außerdem an, dass dieses Forum möglicherweise außerhalb Deines Landes gehostet wird und bist damit einverstanden, dass Deine Daten in dem Land, in dem dieses Forum gehostet wird, gesammelt, gespeichert und verarbeitet werden.
Kommentar