[visu plugin] Unterstützung von Widgets ohne zugehöriges Plugin - Bitte um Feedback about smarthome HOT 7 CLOSED

Variante 3:
Das Widget-delivery raus aus dem visu Plugin in ein eigenes und dann über Config : include_widgets = { freewidget1, freewidget2}
Die können dann beim Widget-Plugin liegen. Die Plugin Widgets könnten dann weiterhin abgegrast werden

from smarthome.

Die Trennung von Widget Handling und Visu Plugin finde ich nicht sinnvoll, da die Widgets nur zusammen mit der Visu funktionieren.

Wenn in der Zukunft eine andere Visu unterstützt werden sollte, werden dafür auch die Widgets anders aussehen und die Auslieferung dieser Widgets wird auch anders funktionieren. Dann könnte es ein anderes Visu Plugin geben, das die Visu und die Widgets für diese Visu unterstützt.

from smarthome.

Das visu-Plugin ist doch eher so gedacht, dass es eine generelle Schnittstelle sein soll, die ueber einen Treiber in der VISU (z.B. fuer smarthome) mit der VISU kommuniziert. Meiner Meinung nach sollte das visu-Plugin nicht an die eigentliche VISU gekoppelt sein, sondern nur allgemeine Funktionen bereitstellen. Auch ich wuerde die Widgets nicht im visu-Plugin ablegen.

Auch das generieren von Seiten (habe ich bisher noch nicht verwendet und weiss daher auch nicht, wie das funktioniert) sehe ich eher nicht als Core-Funktionalitaet von SmartHome an. Es waere eher eine zusaetzliche Funktionalitaet oder ein Tool mit dem man sich das vereinfachen kann. Vermutlich stoesst diese Ansicht aber auf Widerstand, da ich schon Sachen gesehen habe, die ziemlich stark an die VISU gekoppelt sind (z.B. sv_widget). Ist vielleicht auch ein anderes Thema.

Trotzdem wuerde ich Widgets komplett unabhaengig vom Plugin machen. Weder vom VISU- noch von anderen Plugins. Die Widgets sollten lediglich auf Items arbeiten. Mit welchen Plugins diese bereitgestellt werden, muss das Widget eigentlich nicht wissen. Mit diesem Ansatz koennte man auch Widgets verwenden, die auch mit anderen Plugins verwendet werden koennen. So richtig sehe ich den Anwendungsfall naemlich noch nicht, dass Widgets von Plugins abhaengen.

Von daher wuerde ich Widgets auch in ein eigenes Verzeichnis auslagen und dort strukturieren. Z.B.

• smarthome
  • plugins
  • lib
  • ...
  • widgets
    • common (allgemeines?
    • plugin_xyz (nach Plugins?)
    • jalousie (nach Themen?)
    • switches (nach Funktionen?)
    • ...

from smarthome.

Hallo ohinkel,
so war das plugin vieleicht mal gedacht. Darauf weist auch class_name = WebSocket in der plugin.conf hin. Davon hat sich das das Plugin aber durch die Entwicklung von Marcus bereits weit entfernt. Es generiert schon seit Jahren Seiten spezifisch für die smartVISU. Das von Dir angesprochene sv_widget ist im visu Plugin implementiert.

Die Widgets unabhängig von der Visu zu machen halte ich für eine gute, aber schwer umzusetzende, Idee. Die Widgets bestimmen ja die Art der Darstellung in der Visu. Die aktuellen Widgets sind html code und stützen sich noch dazu sehr stark auf der in smartVISU verwendeten Template Engine ab. Die Widgets sind ohne smartVISU nicht einsetzbar.

from smarthome.

Ich würde nach wie vor die Trennung der Funkionalität bevorzugen. Der Code kann dabei in einem Verzeichnis liegen, aber zwei Plugins. Am liebsten wären mir zwei Verzeichnisse. Die beiden Funktionen machen ganz unterschiedliche Dinge und funktionieren auch unabhängig von einander. Der eine Teil bietet eine WebSocket Schnittstelle an, der andere Teil kopiert HTML Fragmente. Nach dem Prinzip "separation of concerns" gehören die Teile getrennt. Denn nur dann lassen sie sich später leichter kopieren und umbauen.

SmartHomeNG ist nicht an ein Produkt gekoppelt, auch nicht an eine GUI, es ist ein metagateway das unabhängig ist und Dinge miteinander verbindet(z.B. Telefonanlage mit Weboberfläche und der Alarmanlage)
Daher sollte die smartVisu keine besondere Rolle einnehmen. Zudem ist die Zukunft der smartVisu nach wie vor ungewiss.

Da SmartHomeNG ein metagateway ist, implementiert es die Schnittstellen zur anderen Produkten, auch zu VISUs und nicht umgekehrt. Die starke Kopplung an smartVisu wäre fatal. Das visu Plugin ist nur für die smartVisu, die nächste Visu bekommt ein eigenes Plugin und wird auch anders kommunizieren. Daher dürfen die sv_widgets nicht im TOP Verzeichnis von SmartHomeNG abgelegt werden. Eine andere Visu kann nichts mit den Widgets anfangen. Die diversen Plugin-Verzeichnisse als Ablage für widgets sind schon eigentlich zu viel.

Die Struktur von @ohinckel ist ganz gut, ich würde sie nur nicht auf der TOP Ebene sehen.

Hier mein Vorschlag:

• smarthome
  • lib
  • bin
  • plugins
  • smartvisu_socket
  • smartvisu_widgets
    • widgets
    • common (allgemeines?
    • plugin_xyz (nach Plugins?)
    • jalousie (nach Themen?)
    • switches (nach Funktionen?)

Wenn wir ein Thema angehen dann richtig und sollten jetzt die ganzen Verzeichnisse und Widgets aufräumen.

from smarthome.

@cstrassburg:
Ok, mit der Trennung der Funktionalität kann ich mich anfreunden. Ist aber ein etwas größerer Umbau, da ich dann sauber zwischen WebSocket und smartVISU unterscheiden werde.

Du hattest eine Trennung in:

• smartvisu_socket
• smartvisu_widgets

vorgeschlagen. Wenn nur die Widgets ausgelagert würden, würde im bisherigen visu Plugin das generieren von smartVISU Seiten verbleiben. Ich würde das dann etwas größer umbauen und das generieren der Seiten auch in das smartvisu Plugin übernehmen. Also eher so:

• websocket
• smartvisu

Dann hat man auch die Möglichkeit für andere Visus entweder auf dem websocket plugin oder einem neuen Kommunikations-Plugin aufzusetzen und die Visu spezifische Unterstützung in ein xxvisu Plugin zu packen.

Das smartVISU Plugin würde dann:

• Visu Seiten generieren (die item Attribute **sv_**xxx auswerten)
• generelle Widgets in die Visu ausliefern (aus einer Struktur ähnlich der von ohinkel vorgeschlagenen)
• Widgets aus anderen Plugins in die Visu ausliefern (aus dem Plugin Unterverzeichnis sv_widgets)

Widgets aus anderen Plugins würde ich aus Gründen der Handhabbarkeit nicht in das smartvisu Plugin integrieren, sondern sie (wie ich es bisher implementiert habe) in der Verzeichnisstruktur des jeweiligen Plugins speichern. Das macht es für den Entwickler und den Anwender einfacher.

Der Entwickler hat alles zu seinem Plugin ()in seiner Hoheit) in einem Verzeichnis zusammen. Der Anwender kann einfacher Plugins zu installieren, da er nur eine Verzeichnisstruktur in seine smarthomeNG Installation kopieren muss.

Wenn eine zukünftige Visu auch Widgets (oder ein ähnliches Konstrukt) unterstützt, können diese von den Plugin Entwicklern analog mit ihren Plugins in einem Unterverzeichnis xx_widgets, mit ausgeliefert werden, falls ein entsprechendes Plugin für die Visu xx das unterstützt.

Hier wäre mein Vorschlag (auch in Hinblick auf die Unterstützung weiterer Visus)

smarthome
    - lib
    - bin
    - plugins
        - websocket
        - smartvisu
            - widgets
                - common (allgemeines?
                - jalousie (nach Themen?)
                - switches (nach Funktionen?)
        - xxvisu            (zukünftige Unterstützung einer weiteren Visu)
            - ...

        - plugin_xyz
            - sv_widgets    (falls der Entwickler Widgets zur verfügung stallt)
            - xx_widgets    (evtl. in Zukunft für ein Plugin xxvisu)

from smarthome.

"Unterstützung von Widgets ohne zugehöriges Plugin" has been implemented in visu_smartvisu. This plugin can have a sv_widgets subdirectory too.

from smarthome.