[Draft] Best Practice zur PHP-Modul Erstellung

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.

Wir freuen uns auf eure Meinungen und Anregungen! :slight_smile:

Best Practice zur PHP-Modul Erstellung

paresy

Hallo Paresy,

find ich gut. :slight_smile: So hat man selbst auch einen kleinen Leitfaden.
Dann muss ich ja jetzt erstmal meine Module ins englische übersetzen. :smiley:

Wie sieht es aus, wird es dann eine Liste mit allen Modulen geben, die auch geprüft werden?

Grüße,
Kai

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.

paresy

Ich habe die Liste mal besser sortiert und formatiert :slight_smile:

paresy

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)

paresy

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.

Genau. Das ist vollkommen korrekt und genauso gedacht.

paresy

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)

paresy

Hallo ihr beiden,

danke für die Hinweise. :slight_smile:
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. :smiley:

Grüße,
Kai

Ich habe den Beitrag mal in den öffentlichen Bereich verschoben!

paresy

@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…

paresy

Verstehe ich das richtig, dass ich in SendDataToParent / SendDataToChildren am Anfang erstmal auf KR_READY prüfen muss? Und falls nicht return false?

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 :slight_smile:

Basti

Nein sie werden vorher nicht aufgerufen und in ApplyChanges prüfe ich.

Das hier?

… 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 :wink:
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.

Alles klar, danke :slight_smile:

Hallo Paresy,

tolle Sache - werde meine „Modulchen“ mal prüfen :wink:

Wie wäre es mit zentralen Tools hier im Forum oder so für

[ul]
[li]GUID-Generator
[/li][li]Prefix-Generator
[/li][/ul]

Damit diese eindeutig wären?

Grüsse,

Mike