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.
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.
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 !?
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.
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.
New Feature: Plugins
New Plugin: colorChooser (based on farbtastic)
Das unwichtigere (auch wenn's MatthiasS unbedingt wollte... ) ist der Farbwähler, selbstverständlich nicht als RGB sondern als HSL
(Vom verwendeten "Widget" gäbe es auch noch eine Beta Version 2.0 die canvas statt fixer Bilder nutzt und daher skalierbar wäre. Den IE Nutzern will ich die aber erst mal ersparen...)
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...
Außerdem können Plugins mit dem Paket mitgeliefert werden (oder von extra Plugin-Autoren als eigene Pakete bereit gestellt werden)
(Die Custom-Widgets in der structure_custom.js dagegen sind kleine, leichtgewichtige Widgets die für lokale Anpassungen geeignet sind - wie der Design-Switcher, der keine Bedeutung für die Allgemeinheit hat).
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 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...
@Netzkind
Noch mal zu dem Thema GA Auswahl im Editor. Momentan scheint sich der Editor wirklich noch komplett auf die eibga.conf zu verlassen und nicht, was in der Visu XML tatsächlich eingetragen ist.
Diese GA ist nicht in der eibga.conf angelegt. Wenn ich nun dieses Widget mit dem Editor bearbeiten will, zeigt er mir eine unvollständige Maske mit fehlender Adresse.
Sollte er nicht zumindest die GA anzeigen, auch wenn er keine weiteren Infos wie z.B. die Bezeichnung aus der eibga.conf holen kann!?
Gut, LCN würde ich jetzt schon vergessen, weil das ist ungefähr so relevant wie hierzulande X10; ich glaube selbst der FS20-Schrott hat 1000% mehr Marktdurchdringung
(obwohl das mal interessant wäre: FS20 vs. KNX in Stückzahlen im EFH, brr, ich fürchte, ich wills nicht wissen! bin schon ruhig )
Aber im Kern 100% d'accord: KNX ist nicht die einzige Wahrheit, spätestens bei der Mediensteuerung ist nunmal ziemlich Schluss (ausser man kann, will&muss sich durchs Knie usw..)
-> Das kann, muss & wird direkt passieren müssen (wie auch immer, ob über die iFrame-"Notlösung" die ich aus Faulheit - und als gebranntes Kind - erstmal präferiere oder "nativ/direkt")
eine allzugrosse Abhängigkeit von KNX-only (DPT) sollte man IMHO auch im Editor vermeiden, KNX ist nur eines von vielen möglichen, wo sich die Visu ihr Futter holt.
Richtig. Daneben fallen mir spontan noch die (für mich relevanten) Logik-Engine, xPL und OPC UA ein. Daneben wollen die ganzen FS20, LON, LCN, ... auch nicht vergessen sein.
Zumindest das Authentication war gemeint, ja
Das runde Gesamtkonzept dafür (Anwenderfreundlich, kein generve mit paranoia-Security aber eben trotzdem sicher) ist im Kopf aber auch noch im Beta-Stadium.
Ich denke ich werde morgen nochmal ein Package machen, wo man das vielleicht ein bisschen elaboriert.
@luigi: jep, das ist auf der Liste aber aktuell ein "halbabsichtlicher Bug" (weil das das passiert war mir vorher klar, nur entweder, wenn man jetzt einsteigt: kommt man ohne config raus->viel mehr gefummel als Konsole&eine Frage..)
Nebenbei: was heute im Telefonat mit Nils noch hochkam: eine allzugrosse Abhängigkeit von KNX-only (DPT) sollte man IMHO auch im Editor vermeiden, KNX ist nur eines von vielen möglichen, wo sich die Visu ihr Futter holt.
Andererseits muss ich das aber gleich selber verteidigen Der KNX hat seine sinnvollen Spezifikas wie z.B. bei einem Dimmer (Schalten,Schaltstatus,Dimmen,Dimmwert,Dimmwertsta tus - um nur ein Beispiel zu nennen) - die man dort auch abbilden sollte. Schon alleine weil die Leute das verstehen.
Für einen FS20-Dimmer (oder einen falsch verstandenen KNX-Dimmer) wirds dann halt ein zweites Widget geben müssen.. Dimmwert->Ende. Status obliegt hier Kommisar Zufall
Du kannst dich direkt auf die Konsole einklinken (entweder Putty oder ähnliches)
und
apt-get update
apt-get install cometvisu
Die Visu_config.xml muss später noch in ein anderes Verzeichniss, damit die Abfrage nicht mehr kommt. bzw eine benutzerdefinierte config nicht überschrieben wird. im Moment ist das noch notwendig, da die config.xml vom Grundgerüst her noch nicht auf dem Release Stand ist.
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.
) ist der Farbwähler, selbstverständlich nicht als RGB sondern als HSL 
Einen Kommentar schreiben: