jsonConfig onload und onsave hook
-
@haus-automatisierung Hi, danke für die Rückmeldung, habe mal meinen Senf dazu gegeben :).
Aber den Hook könnte ich trotzdem gebrauchen. Wenn ich nämlich aktuell meine settings speichere, müsste der Adapter neu gestartet werden, oder besser innerhalb des Adapter kann ich eine Funktion aufrufen, die die Änderungen übernimmt. -
@dirkhe sagte in jsonConfig onload und onsave hook:
Wenn ich nämlich aktuell meine settings speichere, müsste der Adapter neu gestartet werden
Das passiert ja sowieso
@dirkhe sagte in jsonConfig onload und onsave hook:
innerhalb des Adapter kann ich eine Funktion aufrufen, die die Änderungen übernimmt.
Das wird nicht klappen, weil keine Instanz laufen muss, während man die Konfiguration bearbeitet oder speichert. Damit wird ja einfach nur ein Objekt vom Admin bearbeitet. Mehr passiert nicht. Man könnte also höchstens eine Callback-Funktion direkt in der jsonConfig mitliefern (was ja jetzt noch nicht geht).
Aber da gilt, dass das eigentlich nur für einfachere Adapter-Konfigurationen gedacht ist. Möchte man wirklich komplexe Dinge in der Instanz-Konfiguration tun, sollte man eine eigene React-Oberfläche dafür bauen (Beispiele im Adapter-Creator).
-
@haus-automatisierung aber auch in der jsonconfig gibt es ja beispiele, die zb. eine select optionsliste aus dem adapter holt, dass der dafür laufen muss, ist klar.
Ich finde ja gerade die möglichkeit der einfachen konfiguration nett.
Wenn man jetzt quasi immer noch eine javascript datei mit deployen könnte, die im admin mit geladen würde, in der man vlt kleinere prüfroutinen bauen könnte, die dann per validate auch im configjson benutzt werden können und meine besagten hooks, wäre man da sehr flexibel, ohne sich ausgiebug mit den react komponenten zu befassen.
Brauche ich komplexe Oberflächen, muß ich diesen anderen weg gehen, da bin ich bei dir.Das mit dem Adapter neustart nach speichern stimmt, ich hatte vergesen, dass beim dev-server die Instanz quasi von außen gestartet wird, diese wird beim schließen nämlich nicht restartet
-
@dirkhe Man kann für jsonConfig auch einzelne Komponenten selbst bauen und mit ausrollen. Siehe
https://github.com/ioBroker/ioBroker.admin-component-template
Beispiel dafür im Telegram-Adapter.
-
@haus-automatisierung ja, aber da bist du voll im react code zugange. Wer sicn damut auseinander setzt, der eird dann auch direkt alles machen können/wollen. Ist halt mal nicht so eben gemacht. Der sinn dss ganze prr vonig zu machen, war ja sicherlich, das ganze einfach, ohbe große Hürden zu machen, ws auch gelungen ist. Wenn jetzt mit dem adapter-creator novh do eine js datei mitgeliefert wüdde, mit den entsprechenden funktionsrümpfen, könnte jeder schnell eindteigen, ist ja für den index_m auch so.
Vielleicht schaue ich mir das mal irgendwann an, aber erstmal ist der adapter selber wichtiger für mich.
-
@dirkhe sagte in jsonConfig onload und onsave hook:
ist ja für den index_m auch so.
Naja, das ist ein komplett anderes Konstrukt mit iFrames usw. Der Nachteil an index_m / materialize war ja, dass jeder das Design mitmachen musste. Und das ist teilweise schon sehr wild, was da an (schlechtem) JavaScript Code zusammengebaut wurde. Das ist Webentwicklung wie vor 25 Jahren
Sonst bleib doch bei Materialize, wenn das für Dich einfacher ist und Du da alles machen kannst. Man hat doch alle Möglichkeiten. Jetzt wieder mit wild nachgeladenen JavaScript-Dateien zu arbeiten, wäre aus meiner Sicht kontraproduktiv. Ich bin froh, dass das endlich mal klar strukturiert ist.
-
Möcht mich da auch einklinken.
Ich hätte auch gerne ein Möglichkeit ein js file "mitzuladen". json Config bietet jetzt schon die Möglichkeit validationfunctions und auch hide/enable via functions zu steuern. Nur ist das de facto seeeehr eingeschränkt. da die ganze Funktion in ei ne Zeile muss.
Ein entsprechender Feature Request wurde mit Verweis auf custom component geschlossen.
Nur für mich gilt dassele: Derzeit kann (und will) ich mich nicht in React einarbeiten. Dazu hab ich einfach keine Zeit. Ich würde aber gerne Fehlermeldungen bereits bei der Konfig ausgeben. Nur die notwendigen Checkroutinen gehn sich nicht als einzeiler aus.
Ergo:
User bekommen die Meldungen erst via log beim Adapterstart.Das ist suboptimal. Aber wenn ich für die Validierung eines Textfeldes zuerst React lernen müsste gehts nicht anders.
Wenn beim Laden der Json Config ein "einfach" ein fix benantes js (oder alternativ ein via json config spezifiziertes) File geladen würde könnte man dessen Routinen in der json Config dort wo schon jetzt functions vorgesehen sind aufrufen ...
McM
P.S. Muss mal experimentieren ob ich z.B. Via validierungsfunction die ein inherit enthält was unterjubeln könnte ....
-
@mcm57 Da kann man bestimmt tricksen, aber das ist halt alles unschön.
Darum glaube ich ja auch, dass ein sauber vorkonfiguriertes Javascript file eine saubere Sache sind, weil da eben die Struktur vorgegeben ist. Dann braucht auch nicht jeder versuchen, auf irgendeine weise da code einzuschleusen und jeder andere, der da drauf schaut, sieht auch sofort was lost und kann ggf. helfen.Ich habe es jetzt nicht ausprobiert, aber ich vermute mal, wenn man die customcomponent einsetzen will, dass man dann das ganze compilergeraffel für react auch wieder seinem Projekt hinzufügen muss. Ist alles nicht so schlimm, macht die Sache aber wesentlich komplizierter und kann dann wieder dazu führen, dass es irgendwo nicht builded usw.
@haus-automatisierung verstehe mich nicht falsch, ich finde es auch gut, dass die Oberfläche mit standard komponenten aufgebaut ist, das hilft Usern auch, sich in den verschiedenen Adapter zurechtzufinden. Der Ansatz mit der config finde ich echt einen guten Ansatz, gerade weil man sich dann nicht mit der UI befassen muss. Ist halt zu schnell am Ende, wenn man etwas weiter machen will. Und der Schritt von config zu react ist halt riesig und schreckt ab.
Vom code her nutzte ich auch lieber typescript als javascript, weil da alles typisiert ist und weil man da besser lesbaren code schreiben kann, der dann effektiv umgesetzt wird.
-
@dirkhe Schreibe mir gerade auch einen Adapter und habe das gleiche Thema. Habe mir dann einen Workaround geschrieben das zumindestens die PW verschlüsselt werden. Ist zwar sehr unschön aber funktioniert. Das Thema haben aber leider alle und es schein ja wohl nicht schlimm zu sein!...Siehe ICal...Das ist mein PW auch sichtbar...
Vielleicht hilft es dir. Klar, der Adapter muss gestartet werden und die PW müssen dann in der Instance Config komplett neu geschrieben werden.
Gruß//Lucky
-
@lucky_esa
Danke, dein Ansatz klingt interessant.
Wenn ich das richtig lese checkst du ob im Passwort Feld irgendwas mit aes-192 drinnen steht. Wenn nein, dann nimmst du an, dass im Feld ein vom User eingegebenes Passwort steht und verschlüsselst es.OK, das Schreiben der Parameter löst einen Adapterneustart aus. Da das aber nur bei Neueingabe eines Passworts erfolgt kann man damit leben.
Und dort wo du das Pwd brauchst entschlüsselst du es wieder.
Einziger Nachteil ist wohl, dass der Code bzw. Key zum ent/verschlüsseln wohl im Adaptercode steckt - und dort doch leicht zu finden sein wird. Allerdings sieht man das Pwd zumindest mal nicht via admin Interface :-). Außerdem dürfte es wohl troubles geben wenn ein User aes-192 als Teil seines Passworts eingibt
Ich find den Ansatz aber interessant. Wirklich sicher kann man ein Passwort eh nicht verscchlüsseln. Wenn es der Adapter in Klartext braucht und decodieren kann, dann kann es jeder der Zugriff auf das System hat im Prinzip auch.
-
@lucky_esa Ist auf jeden Fall auch schon mal ein guter Ansatz, könnte ich so auch schon mal übernehmen. Wenn es dann mal einen fix gibt, wie auch immer, kann man es ja wieder ausbauen.
Danke dir schon mal für den code. -
@mcm57 sagte in jsonConfig onload und onsave hook:
Nur für mich gilt dassele: Derzeit kann (und will) ich mich nicht in React einarbeiten.
Das ist ja ein Totschlagargument. Ich weiß, dass der Sprung zu einer eigenen React-Komponente von jsonConfig relativ weit ist und man plötzlich unwesentlich mehr wissen muss. Ich habe das auch noch nicht alles durchschaut und muss mich damit noch ausführlich beschäftigen.
Das "Problem" ist, dass der Admin sich ja weiter entwickelt. Alles, was man jetzt anbietet, schleppt man jahrelang mit sich rum. Es muss genau abgewogen werden, was man den Entwicklern anbietet. Mit jsonConfig wurde ein Standard geschaffen. Je mehr Flexibilität man bekommt, desto schwieriger wird es in Zukunft alles weiterhin zu unterstützen.
Der erste möchte jetzt Funktionen um die Daten vor dem Speichern zu manipulieren. Der nächste möchte Validierung. Und der danach beschwert sich, dass man doch einfach mit HTML und CSS eine kleine Custom Component bauen können müsste. Das kann man ja beliebig so weiter spielen. Irgendwo muss die klare Grenze sein.
Und wenn es nur um das Verschlüsseln von Passwörtern in Array geht, dann kommt da hoffentlich eine Lösung.
Wo findet man denn Deinen Vorschlag, wo so eine Custom-JavaScript-Datei definiert werden könnte und wie die einzelnen Funktionen aus jsonConfig von Admin/React aufgerufen werden sollen?
-
Bezüglich eigener React Komponente und React ganz allgemein.
Mein Problem ist, dass es schon schwer genug ist sich in ioBroker an sich einzuarbeiten. Ich will mich nicht beschweren und die Sache ist eh bekannt, aber es gibt keine konsistente Dokumentation für ioBroker und die von js-controller bzw. admin angebotenen Schnittstellen. Das was man braucht erlernt man durch lesen existierender Adapter, mittels Creator angelegter Adapter oder durch den tollen Support im Forum / auf Telegramm. Oder kennts du ein Reference Manuel der Schnittstellen? Eine Dokument wo SetState, CreateObject, adapter.setTimer etc. vollständig beschrieben sind? Im adapter Source kann man das finden - aber vergleichbar mit einer Referenz wie sie public Libraries anbieten ist das nicht.
Ich betone - ist keine Beschwerde. Doku-Schreiben liegt mir auch nicht. Und alle die hier arbeiten tun das (m.W. nach) freiwillig und gratis. Und ich kann mit dem Ist Stand leben.
Um nun React zu lernen würde ich mir eine Anleitung wünschen die in Verbindung mit allgemeinen React Anleitungen im Netz die ersten Schritte in ioBroker schult. React Kurse via Google sind nett - aber da fehlt natürlich jede Schnittstelle zu ioBroker. Ich möchte keine Webseite entwicklen. Und jede Feinheit von React braucht man auch nicht am Anfang. Aber mit try and error versuchen eine Config Seite zu erstellen - das mach ich wenn nichts mehr an einem Code zu tun ist. Derzeit versteh ich nicht mal Ansatzweise was ich tun müsste um eine eigene Komponente zu schreiben. Außerdem brauch ich (derzeit) grafisch nichts anderes als jsonConfig eh anbietet. Es geht mir nur um (meiner Ansicht nach kleine) Details.
Bezüglich meiner Anregung:
siehe https://github.com/ioBroker/ioBroker.admin/issues/1802
Bezüglich wie die einzelnen Funktionen aufgerufen werden können:
Ich habe mich nur auf jene Funktionen bezogen die derzeit schon in Admin existieren. Das sind im Prinzip die Schnittstellen zu den Attributen hide, validate, defaultfunction. Hier kann man derzeit schon eine javascript Function in jsonconfig schreiben - allerdings durch json auf einen Einzeiler begrenzt. Hier könnte man schon jetzt ohne Änderung den Aufruf einer Funktion angeben. Nur müsste die irgendwie aus einem externen File in den Kontext von jsonConfig geladen werden.
Ich sehe beim Support von externen Skripten weniger potenzielle Probleme für die Zukunft als im Bereich customComponent bei der ja das Ganze Verhalten incl. optischer Darstellung ins Gesamtkonzept passen muss. Aber ev. seh ich das auch falsch mangels React Können / Erfahrung.
Zu deiner Anmerkungsliste:
Der erste möchte jetzt Funktionen um die Daten vor dem Speichern zu manipulieren.
Das gibt es derzeit noch nicht. Ein genereller Hook hier wär ev. sinnvoll. Frage ist nur wie man mit Fehlersituationen (insb. Validierungsfehlern) da umgehen kann.
Der nächste möchte Validierung.
Die gibt es ja schon. Problem ist nur, dass derzeit nur Einzeiler hier möglich sind und das erschwert die Lesbarkeit / Entwicklung enorm.
Und der danach beschwert sich, dass man doch einfach mit HTML und CSS eine kleine Custom Component bauen können müsste.
Das betrifft im Gegensatz zu den anderen Punkten eindeutig die grafische Gestaltung. Und dass für alle grafischen Gestaltungen die Basis = React verwendet werden sollte, da bin ich bei dir.
McM
-
@mcm57 sagte in jsonConfig onload und onsave hook:
aber es gibt keine konsistente Dokumentation für ioBroker und die von js-controller bzw. admin angebotenen Schnittstellen
Ich hatte mal angefangen, das für mich zusammen zu schreiben. Gibts hier: https://iobroker.readthedocs.io/de/latest/bestpractice/adapterdev.html
Aber an der offiziellen Dokumentation fehlt es wirklich. Ich hatte da ja vor mich mit einzubringen und viel zu schreiben. Nur fehlt mir dafür auch komplett die Zeit gerade. Alles anders gelaufen als geplant.
@mcm57 sagte in jsonConfig onload und onsave hook:
Das gibt es derzeit noch nicht. Ein genereller Hook hier wär ev. sinnvoll.
Ja, nur dass dieser Hook eben entweder im Client ausgeführt werden muss oder im Admin-Adapter, weil die zu konfigurierende Instanz ja gerade gar nicht laufen muss. Daher finde ich die Trennung aktuell schon gut. Am Ende schreibt der Admin ja nur ein Objekt. Und es ist klar getrennt, welcher Code im Admin ausgeführt wird, und welcher in der eigenen Adapter-Instanz.
@mcm57 sagte in jsonConfig onload und onsave hook:
Die gibt es ja schon.
Jein - wenn man die Daten gegen einen JSON-Response von einem Dienst prüfen möchte, geht das z.B. nicht. Außer man macht wirklich fancy Sachen in dem Oneliner.
-
Ja, nur dass dieser Hook eben entweder im Client ausgeführt werden muss oder im Admin-Adapter, weil die zu konfigurierende Instanz ja gerade gar nicht laufen muss.Also der react Client läuft ja auch im Client/Browser. Wenn da dann noch ein zusätzliches script mitläuft, sollte das kein Problem sein. Das mit der Instanz ist richtig, aber in der jsonConfig ist das aber eh vorgesehen. via "sendto" oder "selectSendTo". Wenn die Instanz nicht läuft, gibt es da auch keine Daten. Das ist aber auch ok.
Ich sehe das halt genauso wie @mcm57, so ein Einzeiler macht keinen echten Spass und vernünftig lesen kann man das auch nichtm, gerade auch, wenn es im JSON eingebettet ist. Da kann man besser eine Funktion hinterlegen, die man dann in einem externen Javascript definiert.
Der erste möchte jetzt Funktionen um die Daten vor dem Speichern zu manipulieren. Der nächste möchte Validierung. Und der danach beschwert sich, dass man doch einfach mit HTML und CSS eine kleine Custom Component bauen können müsste. Das kann man ja beliebig so weiter spielen. Irgendwo muss die klare Grenze sein.Nochmal, der Ansatz mit der jsonConfig ist echt gut und das hilft, auch Leuten, die noch weniger mit Webprogrammierung zu tun haben. Und genau das mit der kleinen CustomComponent würde ich hier auch nicht sehen.
So wie ich es verstanden habe, macht es ja Sinn, die react UI zu pushen. Das schafft man aber nicht, wenn es nur react komplett gibt. Dann gibt es halt hier die jsonConfig, mit der man dann aber schnell auch kleinere Sachen nicht machen kann. Also werden dann viele doch wieder auf die admin_m zurückgreifen. Die Spanne darf halt nicht zu groß sein. Und wenn dann ein Entwickler doch vieles mit der jsonConfig gemacht hat und auch mit dem JS nicht mehr weiterkommt, ist er vlt auch eher bereit sich in react einzuarbeiten.
-
@dirkhe sagte in jsonConfig onload und onsave hook:
Also werden dann viele doch wieder auf die admin_m zurückgreifen.
Und das ist doch auch völlig ok. Wobei "viele" relativ ist. Ich habe mittlerweile sehr viele Adapter auf jsonConfig umgestellt und konnte 99% direkt mit jsonConfig umsetzen.
Man hat jetzt schon super viele Möglichkeiten:
- index_m / Materialize mit eigenem JS und CSS wie man Lust hat
- jsonConfig mit dem Admin 5
- jsonConfig + Custom Components (React)
- komplett eigene React UI
Ich würde es mir auch nicht antun, da jetzt noch mehr Möglichkeiten zu schaffen. Für Einsteiger sieht man jetzt schon nicht mehr durch, welches der "richtige" Weg ist und kann an bestehenden Adaptern nicht mitarbeiten, weil man jsonConfig oder index_m das erste mal sieht.
Wenn ihr das wirklich möchtet, dann geht doch etwas in Vorleistung und erstellt ein Konzept, wo genau die zusätzliche js-Datei definiert wird und wie diese aufgebaut sein muss, damit es keine Konflikte mit anderen Scripts gibt. Eine Sammlung von globalen Funktionen ist da ja nicht der Hit.
-
@haus-automatisierung ich schaue mir das mal an, was und wie man das am besten machen könnte. Ich habe da jetzt nicht meine hauptprio drauf und muß mir dann das mit dem react mal anschauen
