Anbei einige Ansätze die wir über die letzten Monate gesammelt haben. Wenn Fragen zu den einzelnen Punkten bestehen, beantworten wir diese gerne. Gerne bauen wir auch noch Ausnahmen ein, wenn diese erforderlich sind.
Ja, das Tracken wir zur Zeit hier: IP-Symcon Community Forum
Und ja, wir werden alle Module auf diese Best Practises (irgendwann Richtlinien) überprüfen.
iv Ein Modul darf niemals Abhängigkeiten aus einer anderen Bibliothek erfordern.
Kann ich zwar grundsätzlich nachvollziehen aber wie soll dies z.B. im Fall von IPSI möglich sein? Ich baue ja nicht die gesamten Funktion existierender Module noch mal nach und packe diese in ein Modul. Das IPSI Modul wird in der Grundfunktion auch ohne andere Module funktionieren. Wenn ich aber später den gesamten Funktionsumfang nutzten will, z.B. Sonos, dann sind andere Module von Notwendigkeit. Diese werden geprüft ob diese vorhanden sind wenn ja steht die erweiterte Funktionalität zur Verfügung wenn nein lässt sich der Teil dann auch nicht bedienen.
Ich wüste jetzt auch nicht wie man das anders lösen sollte oder was war da genau mit Abhängigkeiten aus einer anderen Bibliotheken gemeint?
Das war damit auch nicht gemeint. Es geht darum, dass du kein include von PHP Dateien aus einer anderen Bibliothek machst und dadurch das Modul kaputt ist, solange die andere Bibliothek fehlt. Deine Bibliothek mit Modulen muss in Sich geschlossen sein. Es darf aber, wenn andere Bibliotheken vorhanden sind, gerne erweiterte Möglichkeiten bieten.
Ich habe den Absatz mal erweitert
Ein Modul darf niemals Abhängigkeiten aus einer anderen Bibliothek erfordern, sodass das Modul (ohne diese Bibliothek) „kaputt“ ist (z.B. ein include auf eine benötigte PHP Datei). Eine Bibliothek muss immer in sich geschlossen und funktionsfähig sein. Optionale Funktionen können durch zusätzlich installierte Bibliotheken freigeschaltet werden. (Randfall: Ein Modul kann ohne sinvolle Funktion sein, solange keine anderen installierten Bibliotheken vorhanden sind. Sie muss aber darauf Hinweisen und trotzdem fehlerfrei installierbar sein. Sobald weitere unterstützte Bibliothken installiert werden, erweitert sich der Funktionsumfang)
Ah ok, dann ist das klar. Funktionieren tut das ja auch ohne andere Module nur bestimmte Funktionen lassen sich halt nur nutzten wenn weitere Module installiert sind. Aber hier bekommt der Nutzer dann auch eine Ansage das das Modul nicht installiert ist bzw. gefunden wurde.
Das Homekit Modul von Kai funktioniert alleine gar nicht, aber es ist auch nicht ‚defekt‘.
Weil hier dann mein Modul des Websocket als Splitter fehlt.
Sollte somit also auch OK sein?
Michael
Ja. Er sollte aber die vor einem RequireParent überprüfen ob dein Modul vorhanden ist und falls nicht den Status auf einen Fehlercode setzen. Es muss sichergestellt sein, dass die Instanz niemals durch fehlende Abhängigkeiten nicht erstellt werden kann. (=Der toll InstanceInterface Fehler)
danke für die Hinweise.
Aber ich glaube das HomeKit Modul muss allgemein dann noch etwas überarbeitet werden.
Trotz das paresy mir mit den Best Practice zur PHP-Modul Erstellung Arbeit bereitet, freue ich mich daüber, dann hat man einen Leitfaden und wird gezwungen alles richtig zu machen. Gerade ich werde dadurch bestimmt noch einiges über IPS lernen.
@Nall Chan: Hm. Das mit dem I/O ist eine gute F rage. Evtl. könnte man „Abhängigkeiten“ einbauen. Jedoch ist das Auflösen von Abhängigkeiten, sobald bestimmte Versionen erfordert werden ein sehr schwer berechenbares Problem…
Was heißt am Anfang?
Du weißt ja wann du diese Funktionen aufrufen willst und das passiert ja eigentlich nicht beim starten von IPS.
Außer du rufst sie im Create (geht eh nicht) oder in ApplyChanges auf (z.B. Anmelden an Hardware etc).
Dort wäre somit der erste Punkt zum prüfen auf KR_Ready.
Andere Funktionen wie RequestAction oder andere Public Methoden werden ja nicht beim starten ausgeführt.
Michael
Ich habe das Dokument so verstanden, dass ich in den zwei Methoden immer auf KR_READY prüfen soll. Mit am Anfang meinte ich am Anfang der Methode, also ganz oben
Basti
Nein sie werden vorher nicht aufgerufen und in ApplyChanges prüfe ich.
… sollte somit immer überprüft werden, ob der Kernel Runlevel gleich KR_READY ist. …
…
Diese Einschränkung betrifft ebenfalls den Datenfluss, sodass keine SendDataToParent / SendDataToChildren Funktionen verwendet werden dürfen.
Wie du es machst, ist deine Sache.
Nur das sie nicht verwendet dürfen steht da.
Du weißt doch am besten wann wie und wo sie in deinem Modul aufgerufen werden.
Klar kannst du einfach vorher jedesmal prüfen, elegant ist das aber nicht
Michael
Es muss nicht immer auf KR_READY geprüft werden. Das muss nur dann gemacht werden, wenn du mit anderen Instanzen auf irgendeine Art kommunizieren möchtest. Sofern du innerhalb deiner eigenen Instanz bleibst, musst du nichts prüfen.
Der Hintergrund ist einfach, dass beim Starten von IP-Symcon alle Instanzen in „zufälliger“ Reihenfolge erstellt werden. Und da beim Erstellen einer Instanz die Funktionen Create und ApplyChanges aufgerufen werden, kann es sein, dass die andere Instanz noch gar nicht existiert. Das umgehst du, indem du auf KR_READY prüfst. Denn wenn KR_READY gesetzt ist, ist der Kernel bereit und alle Instanzen wurden bereits erfolgreich erstellt.