Hallo Zusammen,
dieses Thema ist aus diesem Thema Konfiguration: Symcon vs. Home Assistant - #6 von kris entstanden. @paresy ist wie immer sehr offen für Vorschläge und Ideen.
Es geht darum das die Art wie das Konfigurations-Form für die Modul Entwicklung, nach meiner Meinung und auch von anderen, funktioniert, deutlich Luft nach oben hat.
Ich hatte es schon in dem oben verlinkten Thema meine ersten schnell runter geschriebenen Ideen gepostet.
Aktuell basiert die Programmierung der Konfigurations UI auf einem Generischen Model. Die Oberfläche wird mit JSON beschrieben.
Die Oberfläche zu beschreiben, Orientiert sich ja Grundsätzlich an anderen Techniken, im Dotnet Umfeld ist es XAML (ein MS XML Dialekt) oder im Android Umfeld wurde/wird es in XML durchgeführt.
JSON ist soweit für mich fein. Es ist leichtgewichtig und bietet alle möglichkeiten.
Das was aber nicht so schön und intuitiv ist ist die Art wie das Frontend (Form) mit dem Backend (Module.php) von statten geht. Bei komplexeren Benutzer-Erfragungen mehr oder minder ein ständiges de-serialisieren der JSON dann das Manipulieren des PHP Arrays und zurück Serialisieren damit die UI nur die Möglichkeiten dem Benutzer präsentiert die auch Sinn machen. Das ist schon sehr abstrakt und es ist viel Try and Error hierfür nötig.
Hier um erstmal paar Punkte um die Diskussion zu Starten. Ich nehme hier, da ich damit vertraut bin und als nicht Informatiker mir das seinerzeit in kürzester Zeit beigebracht habe, das Microsoft XAML (Wird in WPF (Windows Desktop Programme), MAUI (Cross Plattform Programme) und WinUI (Das neue Windows Desktop Framework) genutzt)
-
Die Möglichkeit schaffen, das die UI über eine API zu Manipulieren ist:
-
Die einzelnen Elemente bekommen eine ID. Sprich man Deklariert einen Button oder Text Eingabe Feld mit einer ID. Z.B. „btn1“, btnEntscheidung24". Wie jetzt auch kann man dann z.B. von einem Button dann eine Methode der module.php eintragen. „onClick“: „“ oder „onChange“ etc. Sprich der Button ruft die Methode in der module.php auf. Man kann dort in der Methode mit neuen APIs dann z.B. vom UI Element z.B. txtBox25 die Visibility auf true setzen und gibt. z.B. der Methode true zurück damit Symcon weißt das die UI neu gerendert werden muss. Symcon ist dann dafür verantwortlich die JSON dahin zu manipulieren die txtBox25 sichtbar setzen und die UI neu gerendert wird.
-
Über eine Spezielle Syntax die Möglichkeit schaffen solche Aktionen direkt in der JSON zu definieren. z.B. „onClick“: „txtBox55->Visibility->false“ so das man für die üblichen Situationen, User entscheidet sich für Option A daraus resultiert das bestimmte Elemente aus bzw. eingeblendet werden. Oder z.B. „onTextChange“: „TextBoxText->labelUserInput->Text“ was die Eingabe eines Textes in einem Label wieder spiegelt (ist jetzt nicht immer Sinnvoll, soll nur zeigen was man machen könnte).
Properties der Element die Manipuliert werden sollten:- ColorForeground
- ColorBackground
- IsActive
- Visibility
- Text
- SelectedItem (über Index)
Events von Elementen die Feuer können (es sind die die es schon gibt, nur um eine Punkt zu haben wo man eventuell Erweiterungsvorschläge ranhängen könnte):
- onClick
2 .onSelected
-
-
WYSIWYG Editor. Entweder als VSCode Erweiterung oder nächster Punkt
-
Entwicklungsumgebung direkt in der Console. Ist sicherlich ein Brocken. Aber IPSView, Logik Pläne und der Script Editor zeigen das es absolut möglich wäre. Es soll ja nicht die VS Code Möglichkeit (oder andere IDE’s) entfernen. Das hier wäre auch eher ein langfristiges Projekt. Direkt aus der Console Git commits und einreichen in den Symcon Store wäre dann sicherlich der letzte Step um es Komplett zu machen. Hat den Vorteil, man entwickelt wo Symcon läuft und in Symcon. Hierdurch ergeben sich auch neue Möglichkeiten in dem man über eine Entwicklungs-Runtime vernünftig Debugen kann und man hat die Renderlogik für die Forms auch zur Verfügung für den WYSIWYG Ansatz. Auch die Renderlogik für die Kachel Visu ist dort.
Das Ziel muss ganz klar darin liegen, dinge die immer wieder gemacht werden müssen, zu entfernen. JSON Deserialisieren, php array manipulieren und zurück Serialisieren ist zwar absolut Flexibel und Generisch ABER auch absolut EDV zu Fuß. Die Konfigurations UI, in welchem System der Welt auch immer, ist die wichtigste UI. Denn Konfigurations Fehler bedingt dadurch, dass Benutzer einfach Falsche dinge eintragen können führt zu Fehlern und zu Unzufriedenheiten. Es sollte somit Über ID’s für Symcon absolut möglich sein die JSON zu Deserialisieren, die Änderungen über die neue API oder über die „JSON Logic“ anzupassen und das vom Modul Entwickler zu abstrahieren.
Ich habe mich noch nicht mit der Kachel SDK großartig beschäftigt. Habe da aber Ähnlichkeiten (statt JSON ist es HTML, aber das Deserialisieren und Serialisieren Prinzip ähnlich) gesehen wo man das auch dahingehen ändern könnte und vereinheitlichen. In der Form ist ein Button ein Button wie dieser in Symcon üblich aussieht. In HTML gibt es, bin ich der Meinung kein CSS Tag für einen Button der so aussieht wie die Nativen Button in der Kachel Visu.
So ich würde mich sehr freuen über eine Produktive Diskussion. Denn wenn Entwickler so wenig Aufwand haben um so mehr Module wird es geben. Ich träume von einem Modul wo es ausschließlich um Logiken geht, ABER es wird viele „wenn das“ „dann aber nicht dass“, dafür aber „das“, einzustellen aber da habe ich jetzt schon Kopfschmerzen nur alle das sichtbar unsichtbar schalten von den Abfragen. Ich möchte aber auch nicht zig JSON Dateien vorhalten und das womöglich direkt im Quellcode, für alle X Fälle.
Ich denke @da8ter hat hier auch noch Ideen da er ja stärker in dem HTML SDK steckt. Ich nenne Ihn hier stellvertretend, da wir beiden fast zeitgleich jeweils unsere ersten Module erstellt hatten. Sprich wir sind da recht frisch ran gegangen und haben nicht soviel den Werdegang wie es zum Aktuell Stand des SDK gekommen ist. Außerdem sind wir beiden keine Informatiker und Repräsentieren die Mehrheit der Community User.
So denn
BlackOrca