Assistent?

[Tom Bombadil]

Wäre auch ein interessanter Ansatz, der sich halbwegs realistisch umsetzen ließe. Müsste man halt automatisiert die bestehenden Infos aus den Widgets, so wie sie für die Doku genutzt werden, in ein XML schreiben lassen.

Ja, die ganze Nummer relativiert sich durch die obigen Ausführungen. Für die gewünschte Item-Liste aus shNG könnte man das XML in einem einfachen Plugin erstellen (Export in Datei, auf die der Editor z.B. per SMB zugreifen kann). Wahrscheinlich könnte das gleiche Plugin auch noch gleich die sV-Widgets mit abfrühstücken.
/tom

Nachtrag: Das hier aus der Notepad++ Doku könnte einem allerdings bei den Items auf die Füße fallen:

Punctuation might work for auto-completion; however, if you want to use the parameter hints, you should not use punctuation in the keyword name.

[AndreK]

Guten Abend in die Runde,

auch von meiner Seite besten Dank an all diejenigen die die SmartVisu weiter vorantreiben.

Super Job

Zum Thema Assistent habe ich heute mal ein wenig probiert, vielleicht kann ich an dieser Stelle auch was beitragen.

Ich habe ein "kleines" Plugin geformt welches die *.html-Dateien im widget Ordner scannt.
Es werden alle Zeilen mit "@param" gelesen und diese der Zeile mit "{% macro" zugeordnet. Diese Informationen landen in einem dict.

Das dict mit allen Macros wird an das Web-IF des Plugin übermittelt.

Im Web-IF wird wie im Logic-Editor (dort habe ich vieles via Cut&Paste übernommen) die AutoComplete-Funktion verwendet.
Sobald ein Widget-Name eingegeben wird und die die Zeile nicht mit einer Klammer beendet wurde wird ein Tooltip mit den Informationen aus den HTML-Dateien angezeigt.
Der jeweils aktuelle Paramter (in Abhängigkeit der verwendeten Kommas) wird jeweils farblich markiert und die Beschreibung aus der HTML-Datei des Widgets angezeigt.

Die jeweiligen Eingaben werden dann jeweils durch AutoComplete mit den übertragenen Items vorgeschlagen. Eine Eingrenzung auf Datentypen erfolgt nicht, da ich im Moment keine eindeutigen Hinweise in den Widgets finde was für ein Datentyp benötigt wird und wie dieser eindeutig den Datentypen in shNG zugeordnet werden kann

Wenn die Klammer geschlossen wird verschwindet der Tooltip wieder.

Ich hab mal ein paar Screenshots angehängt (das sind keine Foto-Montagen, das läuft so)

Wäre das eine eventuelle Alternative als "Assistent" ?

Ich stell das mal zur Diskussion so in den Raum

Gruss Andre


Picture1.jpg picture2.jpg Picture3.jpg Picture4.jpg

[henfri]

Wow, Klasse.

Kann man damit auch bestehende widgets editieren?
Das ist auch immer ein Fall in dem man Komma zählt ( und wo der trick, sich die Definition aus der Dokumentation zu kopieren nicht funktioniert)


Danke für deinen Einsatz!

[PatrikG]

Nachtrag: Das hier aus der Notepad++ Doku könnte einem allerdings bei den Items auf die Füße fallen:

Da kannst du umgehen indem du als Keyword nur den Funktionsnamen ohne Objektklasse notierst, wie in meinem Beispiel weiter oben nur checkbox, anstatt basic.checkbox. Das Wort basic habe ich nur aus optischen Gründen als retVal angeben.

[Onkelandy]

Da kannst du umgehen indem du als Keyword nur den Funktionsnamen ohne Objektklasse notierst, wie in meinem Beispiel weiter oben nur checkbox, anstatt basic.checkbox. Das Wort basic habe ich nur aus optischen Gründen als retVal angeben.

Er meinte wohl bei den ITEMS, wo ja die hierarchie durch "." getrennt ist.

AndreK Danke für den schnellen Lösungsvorschlag. Sieht schon gut aus! Allerdings dürfen wir nicht vergessen, dass die SmartVISU solche Features unabhängig vom Backend anbieten sollte, also eigenständig. Daher kam von Tom wohl die Idee mit den Items als XML. Würde das mit deinem Ansatz hinhauen, oder basiert da irgendwas auf dem admin Interface und Python?

Die Sache mit dem item type könnte man jedenfalls in die Widgets einbauen, zB in Klammer hinter item angeben, ob's bool, num, dict, etc. sein muss. Wäre ohnehin eine nette Zusatzinfo.

[AndreK]

Hallo Onkelandy,

im Moment werden die Widget-HTML´s mit einem Python-Plugin für shng gescannt. Das könnte man genauso gut via PHP machen.
Das Plugin liefert dann auch die Items aus shNG - ebenfalls Python.

Der Rest ist JS/CSS im Web-Interface, das liese sich auch ohne weiteres in die smartVISU integrieren.

Es wird aber aus meiner Sicht nicht ausbleiben, die Beschreibung der Params nach festgelegten Konventionen zu beschreiben (z.B. ein Qualifier für Beschreibungen die über mehrere Zeilen gehen). Eine weitere Hürde sind dann noch Doppelbeschreibungen für item und item[?], die müsste erkennbar sein, was zusammengehört.

z.B. Bei basic.color :

* @param {item[?]} an item for the red value in RGB model or hue in HSL and HSV model, or single item containing list of all color values
* @param {item=} an item for the green value in RGB model or saturation in HSL and HSV model
* @param {item=} an item for the blue value in RGB model or lightness in HSL model / brightness in HSB model (to let blank if first item contains list of all values)

{% macro color(id, item_r_h, item_g_s, item_b_l_v, min, max, steps, colors, style, colormodel) %}

Gruss Andre

[wvhn]

Hallo AndreK,

danke für den guten Beitrag! Das sieht schonmal sehr vielversprechend aus.

Eine Beschreibung des Docstrings einschließlich der Bedeutung der Notation findet sich im Wiki.
Wir haben nach bestem Wissen alle Docstrings der Widgets bearbeitet und mit dem Templatechecker überprüft. Das sollte zumindest eine erste gute Basis sein.

Gruß Wolfram

[Onkelandy]

Mein Vorschlag wäre, hinter das item in den HTMLs in Klammer die möglichen Types anzugeben. Wenn mehrere erlaubt sind, mit Komma als Liste.
Das Auslesen der HTMLs wird übrigens auch in der Datei twig_functions für die Docu gemacht. Da könnte man den Code sicher wiederverwenden. Magst dir das mal ansehen, AndreK ?

[AndreK]

Hallo Onkelandy , hallo wvhn ,

ich schau mir das mal an (eigentlich den ganzen Tag schon immer wieder). Sieht gut aus, besten Dank für den Tipp mit

twig_functions

Damit kann man, wie die Doku, alles via Twig ermitteln. Der Tipp ist die halbe Miete :-)
(Ich verwende nicht den Code sondern einfach die Funktion : "twig_docu"

Somit gibt es dann auch kein Problem mit "Konventionen" - alles wird, wie in der Doku, interpretiert.

Ich verfolge im Moment den Ansatz den Widget-Assistenten als Widget zu erstellen. Ist zwar paradox macht aber vielleich doch Sinn.

Aktuell wird das "Assistant-Widget" in meinen Pages in einer eigenen Seite aufgerufen. Das Widget benötigt ein Item mit den "Items" des Backends (als Array).
(Das Array fülle ich im Moment mit einer Logik beim Start von shNG - kein weiteres Plugin im Back-End notwendig).
Das Item kann dann von anderen backends dann entsprechend bedient werden.
Autocomplete erfolgt nun mit allen Item-Namen und allen Widget-Namen.

Screenshots kann ich eventuell morgen liefern.

Folgende Fragen sind von meiner Seite offen :

- Wo würdet ihr den Assistenten ansiedeln ?
- als Widget in den eigenen Pages
- als Widget in der Doku
- als Widget auf den Config-Seiten

Man könnte das "Master-Item" für die Items eventuell in der Config eintragen, dann wäre kein Item mehr beim Widget anzugeben ?

Im Moment habe ich die js-Verweise auf CodeMirror in der "/base/root.html" eingetragen, gibt es hier eine Alternative ?

Ich tue mit echt schwer mit den CSS-Einträge für CodeMirror und für den Tooltip unter den Bedingungen der CSS's von SmartVISU, hier wäre Hilfe von Jemanden der sich mit sowas auskennt echt super :-)

Das alles hier zur weiteren Diskussion.

Viele Grüsse

Andre

[henfri]

Hallo Andre,

das klingt super.
Ich tendiere dazu den Assistenten in der Doku zu den Widgets verfügbar zu machen. Dann hat man die Beispiele und den Assistenten an ein einem Ort.
Allerdings ist es natürlich auch möglich die Doku und den Assistenten (wenn er woanders ist) in unterschiedlichen Tabs offen zu haben.
Aber man hat ja ohnehin schon weitere Fenster (notepad um das Ergebnis in die html zu kopieren, ein weiteres Browser Fenster für das Ergebnis) offen.... Da stört jedes weitere Fenster, finde ich.

Ein Gedanke in dem Kontext noch: Wäre nicht auch eine quasi-live Vorschau möglich? Wenn die geschweifte Klammer geschlossen wird, wird das Widget unter dem Editier-Feld/Textfeld gerendert (möglichst ohne page-Reload; aber vielleicht ist hierfür ein reload nötig, dann ginge es vielleicht in einem Frame?)
Das wäre dann schon fast die eierlegendewollmilchsau.

Gruß,
Hendrik

[Onkelandy]

Das klingt tatsächlich sehr cool! Docu finde ich auch den richtigen Platz. Aber wenn's eh ein Widget ist, kann man sich das dann ja überall hinein kopieren, oder?
In der Config das "Uber Item" zu definieren, fände ich gut. Das sollte dann etwaige Attribute im Widget überschreiben.
Kannst du den Code auf Github stellen und einen PR für die smartvisu erstellen? Dann könnten wir das mal testen.
Gerne auch die Logik für shng dazu.

[wvhn]

Hallo AndreK,

das hört sich toll an. Ich würde den "Template Constructor" (?) in den Config-Seiten als Listeneintrag im Menü über dem Template Checker anordnen. Da gehört er logischerweise hin, weil da alles ist, was man zum Aufbauen einer Visu benötigt. Toll wäre es, wenn man ihn nach und nach als Popup in die Dokuseiten einbauen könnte. Dann könnte man beim Lesen der Doku gleich seinen eigenen Code erstellen.

Dann würde ich vom Anwender erwarten, dass er eine "masteritem.yaml" in das Rootverzeichnis seiner Seiten (pages/<YOURPAGES>) legt. Das wäre zwecks Kompatibilität zu openHAB und Co. sinnvoll. Deren Anwender können die yaml händisch erstellen, oder jemand steuert dann einmal ein Skript bei, das das erledigt.

Aufruf js in in der Root.html finde ich nicht so günstig. Das muss dann in der quad_root.html auch gemacht werden. Das kann ich mir aber nochmal ansehen.

Zwecks css kannst Du Dich an den Dokuseiten orientieren. Dort wird zur Darstellung des Codes mit Google prettify gearbeitet. Deine zusätzlichen css-Befehle kannst Du erstmal in die visu.css packen, bis alles passt. Das bauen wir dann gemeinsam um.

Kannst Du Dir beim Testen auch die Widgets vom Quad-Design ansehen? Die sind ziemlich aufwändig in der Parametrierung.

Danke und Gruß
Wolfram

[Onkelandy]

Ich hatte vor langer Zeit mit smai diskutiert, ob man JS Files und Co nicht irgendwo außerhalb der root nachladen könne - im Sinne eines Dropins für Header. Die Idee fand er gut, allerdings war das technisch wohl nicht so ganz trivial. Da müssten wir also eine global gute Lösung dafür finden. Vorerst zum Testen finde ich das in der root.html schon passend. Im quad_root muss man nix machen, da das ja auf root.html aufbaut.

Die Idee damals war übrigens, CSS und JS für das Quad Design nur in der quad_root zu hinterlegen, damit das nicht geladen wird, wenn das Design nicht genutzt wird. Neue Baustelle

[Tom Bombadil]

Die Idee damals war übrigens, CSS und JS für das Quad Design nur in der quad_root zu hinterlegen, damit das nicht geladen wird, wenn das Design nicht genutzt wird. Neue Baustelle

Ömmm, das ist doch drin? Verzeichnis /css und /js im jeweiligen Pages-Verzeichnis werden doch nur automatisch geladen, wenn die Seite aktiv ist, oder? Hatte dazu auch vor Ewigkeiten einen Chat mit Stefan, er hat das dann irgendwann eingebaut ...
/tom

[Onkelandy]

Ömmm, das ist doch drin? Verzeichnis /css und /js im jeweiligen Pages-Verzeichnis werden doch nur automatisch geladen, wenn die Seite aktiv ist, oder? Hatte dazu auch vor Ewigkeiten einen Chat mit Stefan, er hat das dann irgendwann eingebaut ...
/tom

Das ist ein bisschen was anderes. Es ginge um was Übergreifenderes wie eben das Quad Design. Das File liegt im base Ordner ebenso wie das css. Und Letzteres sollte man zB in quad_root.html laden können.