Diskussion: SDK Verbesserung Konfigurations-Form

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:

    1. 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.

    2. Ü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:

      1. ColorForeground
      2. ColorBackground
      3. IsActive
      4. Visibility
      5. Text
      6. 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):

      1. 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 :slight_smile:
BlackOrca

1 „Gefällt mir“

Manipulation per API können wir schon seit einiger Zeit per UpdateFormField. Da kannst du beliebige Parameter deiner Felder zur Laufzeit aktualisieren.

Der Editor wäre schon ein großer Happen. Ich sehe das nicht als fester Bestandteil der Konsole, dafür ist der Entwickleranteil dann doch zu gering. Aber ich könnte mir das als eigenes Modul vorstellen.

Ich will mich jetzt nicht groß einbringen wie oder was man wie anders machen kann; dafür komme ich zu gut mit den aktuellen Techniken aus (sprich ich weiß wann ich über Indexes oder Namen on the Fly was, wo, wie ansprechen kann).

Was aber sicherlich eine Verbesserung wäre, wenn es ein JSON Validator Schema gibt, welches man in VSC einbinden kann.
Michael

1 „Gefällt mir“

Hallo @Dr.Niels ,
danke für diesen Hinweis den ich tatsächlich nicht kannte.
Bei der Modul Entwicklung bin ich vorgegangen wie hier empfohlen. Gucke die Video, gucke dir auch die Symcon Module die auf GitHub sind an. Leider habe ich nur die Beispiele gesehen wo man das ganze Json gehühner macht.
Das ist leider auch so ein Thema die Doku (undankbares Thema ich weiß, aber es sind zu wenig ganzheitliche Tutorials)

Ja ein „IDE Modul“ hört sich auf jeden Fall sinnvoll, da losgelöst von der Hauptentwicklung :ok_hand:

Praktische wäre für die Formulare ein Editor so wie beim alten Webfront mit den Seitenteilen etc. Wenn die Formulare mal etwas umfangreicher werden steht man da teilweise vor seinem Code wie der Ochs vorm Berg.

1 „Gefällt mir“

Wäre schön, ich denke das ist das Henne-Ei Problem. Die Hürde ein Modul zu entwickeln sind schon arg groß.

Aus meiner Sicht, als absoluter Nichtentwickler; mir ist teilweise die Doku zu dünn und die Beispiele zu gering.

Ich bin derzeit dran, für meine Daikin Brauchwasserpumpe ein Modul zu schreiben. Jetzt wird es provokativ, bitte seht mir es nach, bin gerade leicht genervt…

Das [1] auslesen der Anlage war einfacher und schneller! als jetzt ein passendes Modul zu schreiben. Zur Zeit hänge ich an sowas banalen wie einem Buffer. Das ist einfach sehr ärgerlich.

Dafür ist aber die Lernkurve arg steil :wink:

[1] natürlich undokumentiert und so überhaupt nicht vorgesehen, da ich mich an das Bussystem des Displays hänge…

1 „Gefällt mir“

Ich glaube ich hatte mit der Funktion mal gespielt. Ich glaube die Veränderungen die man damit vornimmt werden nicht in die json übernommen. Das muss man dann wieder selber machen…
Deswegen hier der Wunsch das sowas von symcon gemacht werden sollte. Der Name und des property was verändert wird ist symcon bekannt somit weniger das Problem. Eventuell die Funktion UpdateFormField um ein bool persisted hinzufügen um symcon anzuweisen das in die json zu serialisieren.

Gruß
BlackOrca

Keine Funktion sollte in der Lage sein den Quellcode des Moduls zur Laufzeit zu modifizieren O.o Aber vielleicht verstehe ich dich auch falsch. Magst du deinen Anwendungsfall ausführen?

Wenn die Sichtbarkeit von irgendwelchen Eigenschaften oder dergleichen abhängt, dann müsstest du es in der GetConfigurationForm entsprechend auswerten. Bei Anpassungen mit offenem Formular kommt UpdateFormField zum Einsatz, also z.B. als Reaktion auf das Drücken eines Buttons.

Eine Json ist kein Quellcode im engeren Sinne für mich. Und darin soll ja die Optimierung der dev ux sein.
Es ist so, der User entscheidet sich durch eine Auswahl für Konfurations Art A: dann schalte ich mit FormFieldUpdate, alle elemente in der Sichtbar die hierfür notwendig sind und alle unsichtbar die nicht in dem Kontext notwendig sind.
Wenn dann der User das speichert dann wird die Form wieder mit allen Elementen wie in der json ursprünglich angezeigt. Also auch Elemente die für den gespeicherten Kontext ja ausgeblendet waren.
Sprich dafür müsste ich die Json wieder manipulieren.

@parsey hatte nach Ideen zur optimierung gefragt und das wäre mein Ansatz.
Wenn man etwas mit FormFieldUpdate anpasst, dann wird es durch symcon auch in die Json übernommen. So muss man nicht json deserialisieren, php array manipulieren und anschließend zurück serialisieren. Wenn ich den Quellcode von einigen Modulen sehe wo ganze json im Quellcode (php) liegen damit der Entwickler sich u.a. Besser zurecht findet.
Das sind solche Dinge die potentiellen Entwickler abschrecken. Zeremonien die mehr oder minder immer gleich sind sollten in Hochsprachen nicht nötig sein sondern vom Framework zumindestens als Option in den Hintergrund versetzt werden. Dafür kann man Dinge überschreiben oder irgendwo ein true mit übergeben.

Gruß BlackOrca

Ich glaube du möchtest das in der GetConfigurationForm unterbringen und nicht einfach die lokal gespeicherte form.json zur Laufzeit modifizieren, da war mein Verständnisfehler (glaube ich zumindest, dass du das so wolltest). Wir haben definitiv noch ein Ticket offen um Entwicklern eine Helferfunktion an die Hand zu geben um in GetConfigurationForm analog zu UpdateFormField Felder zu aktualisieren.

Prinzipiell sind deine Worte definitiv nicht auf taube Ohren gestoßen. Wir wissen noch nicht in welche Richtung es geht, es hat aber definitiv ein paar Diskussionen bei uns angeregt :wink:

Da freue ich mich das wir erhört worden sind.
Ich meine zwar wirklich in meiner Naivität das die Form.json zur konfigurationslaufzeit geändert wird (nicht wenn das Modul im Hintergrund einfach seine normale Arbeit vollführt) aber am Ende sind wir für alle helper functions dankbar die uns mehr auf das eigentliche konzentrieren lassen und wir uns nicht ständig die Form im Kopf durchzugehen um es in einem array zu manipulieren.

Wie gesagt. Vielleicht kann man mit der ideen dies dann auch fur die Interaktion mit der module.html gleichsetzen.

Gruß
BlackOrca

Was ja niemals so funktionieren kann. Weil die Form.json ja für alle Instanzen von diesem Modul benutzt wird.
Also Daten/Einstellungen einer Instanz kannst du nie direkt zurück in den Quellcode aller Instanzen schreiben.
Michael