Nur mal so ein Gedanke / Frage an die Profis

[Tom Bombadil]

Hallo,

ich stoße in letzter Zeit immer häufiger auf Stellen in der Visu, an denen eine direkte Item-Abfrage über die Visu/TWIG wünschenswert wäre, insbesondere über {%IF item = "xx" %}-Abfragen:

• wenn dies, dann zeige den einen Wert, sonst einen anderen Wert (statusabhängige Anzeige),
• wenn dies, dann Button mit nachgeschaltetem Popup anzeigen, sonst nichts (z.B. Alarme),
• Buttonleisten mit Initialisierung des derzeit 'aktiven' Buttons (z.B. aktuellen AV-Receiver-Eingang) anzeigen,
• etc etc etc (bin wirklich häufig darauf gestoßen).

Ähnliche Anfragen von anderen Forumsteilnehmern, die hiermit lösbar wären, gibt es haufenweise.

Nachdem ich mich nun wochenlang als 'nicht (mehr) Programmierer' in das Zusammenspiel Visu/TWIG/php/JS eingelesen und auch fast alle Sources des Visu durchgewälzt habe, glaube ich, zumindest ein grundlegendes Verständnis für die Ausgangssituation zu haben.

Bevor ich nun viel Arbeit in etwas hineinstecke, das am Ende vielleicht gar nicht funktioniert, möchte ich die grundsätzliche Machbarkeit einer beim Lesen aufgekommenen Idee hinterfragen.

Ideenkette:

• TWIG kennt globale Variablen, die in {%IF%} verwendet werden können,
• TWIG kann durch php-Extensions erweitert werden,
• TWIG ist in php geschrieben,
• ein php-Listener könnte eine autonome Verbindung zu sh.py aufbauen,
• sh.py kann diesen Listener unabhängig mit Items und deren Werten füttern, wie schon bei allen anderen Plugins (Visu, Eibd, .....)

Das Ergebnis wäre, dass alle sh.py-items als globale Variablen in TWIG zur Verfügung stehen würden.

Erforderlich wäre das Schreiben der TWIG-Extension und eines JSON-Listeners für sh.py, beides in php.



Meine Frage: Machbar oder nicht? Übersehe ich etwas?



Danke für jeden hilfreichen Input!

/tom

[Apollo]

Hallo,

das wird so nicht funktionieren, oder wäre eine absolute Krücke und überhaupt nicht sinnvoll.

TWIG rendert HTML Seiten, Werte werden von smatVISU über einen Websocket abgerufen.

Das eine passiert am Server, das andere am Client.

Selbst wenn am Server der aktuelle Wert zur Verfügung stände, das Template (HTML) darauf rücksicht nehmen würde, wie soll denn dann eine Wertänderung passiern? Das ist strukturell nicht zu machen.

Die Frage ist eher, was soll denn am Client mit dem Wert erreicht werden. Und dafür ein Widget erstellt, fertig

Gruss

[Orion]

Hallo,

ich will da auch mal meinen bescheidenen Hut in den Ring werfen. Nachdem ich da mit dem UZSU Widget lange gelernt hatte wäre ich an dem Punkt angekommen bei den speziellen Themen wo man diese Fähigkeiten braucht das wirklich in einem Widget und mit der dort präferierten JS Lösung baut. Da geht dort, dort hat man die Möglichkeiten (auch den Zugriff auf die Items).

Grüße

Michel

[Tom Bombadil]

Hallo Martin & Michel,

danke für Eure Antworten und die Argumente.

das wird so nicht funktionieren, oder wäre eine absolute Krücke und überhaupt nicht sinnvoll.

Du machst mir ja richtig Mut, die Sache anzugehen!

TWIG rendert HTML Seiten, Werte werden von smatVISU über einen Websocket abgerufen.

Ja, so ist der aktuelle Zustand („det hamwa imma so jemacht“). TWIG schreibt derzeit einen Platzhalter in Form von „---“ an die Stelle, an der später durch JS der entsprechende item-Wert eingesetzt wird. Das hat mich ja erst zu dem Schluss gebracht, dass TWIG die sh.py items tatsächlich nicht zu kennen scheint.

Allerdings ist TWIG nach meinem Verständnis eine ausgewachsene Template Engine und kann deutlich mehr als das, was die Visu bisher verwendet (bitte korrigieren, falls ich da falsch liege).

Template Engines sollen doch dazu dienen, Platzhalter durch Inhalte zu ersetzen, um eine fertige Ausgabe zu erzeugen („Rendering“). Quellen für diese Inhalte können dabei Dateien, Datenbanken oder Streams sein, je nachdem. Warum sollte die Template Engine also nicht einen Stream verarbeiten und statt „---“ den echten Wert benutzen bzw. sich diesen in einer Variable „merken“, um bei Bedarf darauf zurückgreifen zu können?

Selbst wenn am Server der aktuelle Wert zur Verfügung stände, das Template (HTML) darauf rücksicht nehmen würde, wie soll denn dann eine Wertänderung passiern? Das ist strukturell nicht zu machen.

Ja, das ist ein gutes Argument und seit längerer Zeit der Hauptpunkt, der mir Kopfzerbrechen bereitet. Evtl. könnte man bei Veränderung bestimmter Items den Neuaufbau der Seite triggern - da bin ich aber noch nicht zu einer Lösung gekommen. Kommt Zeit, kommt Rat.

Nachdem ich da mit dem UZSU Widget lange gelernt hatte wäre ich an dem Punkt angekommen bei den speziellen Themen wo man diese Fähigkeiten braucht das wirklich in einem Widget und mit der dort präferierten JS Lösung baut.

Du schreibst ja selbst, dass diese „Fähigkeit“ bei „speziellen Themen“ durchaus gebraucht wird. Ich gebe zu – die Anwendungfälle, die mir derzeit vorschweben, haben auch mit der eher starr/statisch aufgebauten Standard-smartVISU nichts zu tun.

HTML per JS im Hintergrund zusammenzuwursteln, um eine entsprechende Anzeige im Browser zu realisieren, halte ich persönlich aber für eine eher ungünstige Lösung. Das ist extrem intransparent, ganz besonders für Einsteiger.

Ganz ehrlich: Dass man über die index.hmtl weitere html-Dateien einbinden kann, die dann über Makros und deren Parameter HTML-Widgets einbinden, in die über Einbettungen und zusätzliche .js-Dateien dann JS-Code eingebunden wird, in dem dann wiederum HTML als Ausgabe „zusammenflickt“ wird – es hat eine Weile gedauert, das als Einsteiger zu verstehen. Und richtig schick wird’s, wenn es dann noch zu JS-Kollisionen kommt (siehe Beispiel UZSU vs. PinPad-Eingabe).

Hier mal ein beliebiges Beispiel aus der UZSU (die ich von der Anwenderseite her genial finde und mehrfach in meiner Visu benutze, ganz vielen Dank für Deine Arbeit!!!). So ein Heidenaufwand, um am Ende durch die Hintertür ein "bisschen" HTML zu generieren?

template += "<tr id='uzsuNumberOfRow" + numberOfRow + "'>";
// jetzt beginnen die spalten in der reihenfolge value, time /rrule, active, delete button
template += "<td><input type='number' data-clear-btn='false' pattern='[0-9]*' style = 'width:40px' id='uzsuEntryValue" + numberOfRow + "'<\/td>";
// time
template += "<td><input type='time' data-clear-btn='true' style = 'width:350px' id='uzsuEntryTime" + numberOfRow +"'>";
// rrule
// hier wird nur der textstring übernommen. prüfungen erfolgen keine !
template += "<input type='text' data-clear-btn='true' style = 'width:350px' id='uzsuEntryRrule" + numberOfRow +"'><\/td>";
// active
template += "<td><form><fieldset data-role='controlgroup' data-type='horizontal' data-mini='true'> " +
        "<input type='checkbox' id='uzsuEntryActive" + numberOfRow + "'> <label for='uzsuEntryActive" + numberOfRow + "'>Act<\/label>" +
        "<\/fieldset><\/form><\/td>";
// del button
template += "<td> <button id='uzsuDelTableRow" + numberOfRow + "' data-mini='true'>Del<\/button><\/td>";
// tabelle reihen abschliessen
template += "<\/tr>";

Hinzu kommt, dass mir nach wie vor nicht klar ist, wie Du den Wert eines konkreten Items per JS abfragst. Nicht alle Elemente der Visu haben eine Eigenschaft „Value“, die man nutzen könnte.

Vielleicht habe ich da auch was die ganze Zeit übersehen - was wäre denn das JS-Gegenstück für ein konkretes Beispiel wie

io.write('ventilation.booster_mode’, 1);?

io.read('ventilation.booster_mode’) ist es nicht, denn io.read ist zumindest für sh.py in der Schnittstelle nicht implementiert.

Wie eingangs schon geschrieben: Die Zeiten der aktiven beruflichen Programmierung liegen lange, lange hinter mir. Damals war kompakter, lesbarer und einfach verständlicher / transparenter Code gefragt. Vielleicht ist ja diese verteilte Verarbeitung „Client (JS) / Server (php/TWIG)“ aktuell State-of-the-Art. Wenn das so ist, lasse ich mich diesbezüglich gern eines Besseren belehren.

Aber ein echtes technisches Gegenargument, warum das Anlegen/Verarbeiten von sh.py-Items in TWIG nicht geht, habe ich bisher nicht gelesen.

/tom

[Apollo]

Ja, das UZSU Widget ist auch noch nicht im Release.

Und Ja: io.read ist bei smarthome.py nicht implementiert und das hat auch seinen Grund .

Du kannst gerne versuchen die Konzepte umzustellen wünsch dir viel Erfolg dabei.

Bin da nun raus.

Gruss

[bmx]

Moin Tom,

laß doch einfach den ganzen Twig Kram weg und mache das rein in JS auf der Clientseite....

(Da gäbe es dann auch twig.js: The Templating Engine for the Client-Side).

Gruß,
Bernd

[Tom Bombadil]

Moin Bernd,

danke - ja, das ist auch ein durchaus denkbarer Ansatz. Ich könnte mich sogar an den Gedanken gewöhnen, HTML wie in der UZSU aus JS heraus zu generieren. Aber das löst nicht das Grundproblem - man kommt nicht ohne weiteres an die Werte ran:

Und Ja: io.read ist bei smarthome.py nicht implementiert und das hat auch seinen Grund .

Genau den Grund verstehe ich nicht. Bin vermutlich der Ochse, der es einfach nicht über den Berg schafft ...

/tom