Instanz-Status 101 in ApplyChanges() überschreiben

Erweiterungen PHP-Module (Entwicklung)
1

Hallo,

ich habe da mal wieder eine Verständnisfrage.
In einigen Modulen habe ich eine Möglichkeit eingebaut, die Instanz mittels einer Property zu deaktivieren.

Da ich frühestens in ApplyChanges() an den Wert der Property dran komme, kann ich auch erst ab dort den Status der Instanz zwischen 102 und 104 ändern, je nach gewünschter Einstellung.

Nun ist es so, dass ApplyChanges() ja auch beim Laden des Moduls aus Create() heraus aufgerufen wird. Während dieses ersten Aufrufs von ApplyChanges() hat die Instanz aber noch den Status 101, weil dieser offensichtlich erst ganz zum Schluss durch Create() auf 102 gesetzt wird.

Bisher habe ich mich nicht weiter darum gekümmert und den Status einfach ganz frech in ApplyChanges() überschrieben. Das funktioniert auch und ich konnte noch keine Probleme dadurch feststellen.

Nun stelle ich mir jedoch die Frage, ob das nicht vielleicht doch irgendwelche Auswirkungen haben kann, wenn ich einfach in die Statusübergänge, die von IPSModule gesteuert werden, eingreife.

Ich bin dann irgendwann dazu übergegangen, mich mit RegisterMessage() an Änderungen des Instanzstatus zu hängen und greife erst in den Status ein, wenn dieser nach dem Laden 102 ist.
Das finde ich aber auch recht umständlich und ein Stück weit von hinten durch die Brust ins Auge, zumal ich gerne in ApplyChanges() schon gewisse Dinge in Abhängigkeit des jeweiligen Instanzstatus tun will, was aber beim Laden des Moduls aufgrund von Status 101 auch wieder alles etwas komplizierter macht.

Daher die Frage:
Kann ich den Status 101 einfach wie bisher überschreiben oder sollte ich das besser nicht tun?

Mit der ganzen Thematik, was ich in welchem Kernel- und Instanzstatus tun sollte und was nicht, stehe ich immer noch etwas auf Kriegsfuß. Insgesamt tue ich mich nach wie vor mit dem Zusammenspiel von Create() und ApplyChanges() schwer, weil man in Create() eben vieles noch nicht tun kann, ich aber manchmal Dinge nur beim Laden des Moduls tun möchte und nicht beim normalen Übernehmen der Einstellungen.

Vielleicht wären Create(), ApplyChanges(), Destroy(), __construct() und Co. sowie die Kernel- und Instanzzustände und die sich daraus resultierenden Einschränkungen beim Laden des Moduls / Neustarten des Dienstes mal ein Thema für ein Webinar.

Es funktioniert zwar immer alles bei mir, aber das muss ja nicht heißen, dass es gut/richtig ist. Irgendwie ist IPSModule für mich nach wie vor eine große Blackbox.

2

Genau so mache ich es auch, in jedem meiner Module prüfe ich u.a. so ein Property und setze dann einen eigenen Status.
Das muss man natürlich an passender Stelle im ApplyChanges() machen und ggfs. auch Timer etc. deaktivieren.
Ich habe insgesamt standardmäßig 4 solcher Stati:

  • Instanz ist deaktiviert
  • Prüfung auf Vorliegen von Voraussetzungen (zB externe Programme, die das Modul nutzt, passende Betriebssystem)
  • Prüfung auf Fehler der Konfiguration
  • erforderliche Arbeiten zum Abschluss eines Modul-Updates

Das verursacht kein Problem, im Gegenteil passt es ja 100% in die Struktur, da ein ApplyChanges() nicht nur bei Änderungen der Konfiguration aufgerufen wird sondern auch bei der Start von Instanzen (auch IPS-Start).

Was man aber auch machen muss ist in bestimmten Funktionen, die
aufgerufen werden können, eine Prüfung einzubauen, damit diese nicht ausgeführt werden, wenn die Instanz „disabled“ ist.
Bsp: eine aus einem Script/Aktion/Ablaufplan aufgerufenen Detail-Funktion eines Moduls soll ja nur dann ablaufen, wenn das Modul nicht disabled ist. Da aber der Modul-individuelle Status „disabled“ nicht vom IPS-Kern abgefangen werden kann, würde die Funktion ausgeführt werden.
Aber das ist ja so oder so sinnvoll.

3

Hi,

Das wäre aber meiner Meinung nach nicht korrekt da du dem User diese Hoheit nimmst.

Ich kann durchaus von einem modul eine funktion nutzen wollen ohne es gleich aktivieren zu müssen.

Viele grüsse

4

Die Funktionsweise eines Moduls liegt in Verantwortung des Modulentwicklers. Wenn das Modul im Status „deaktiviert“ nichts tun soll, was man wohl auch erwarten würde, da so eine Funktion sonst wenig Sinn macht, dann ist das Modul eben so designed. So gesehen kein Eingriff in die Hoheit des Users, sondern works as designed. :wink:

Ja, wie gesagt, ich habe auch noch keine Probleme festgestellt. Aber das muss ja nicht heißen, dass es richtig ist, wenn man die internen Mechanismen nicht genau kennt. Irgendjemand wird sich ja etwas beim Status 101 gedacht haben und dass dieser von Create() gesteuert wird. Daher die Frage.

Aber schon mal beruhigend zu wissen, dass ich nicht der einzige bin, der das macht. :wink:

Schon klar, sonst wäre die Funktion ja ziemlich sinnfrei, wenn das Modul im Status deaktiviert normal weiterarbeiten würde (s.o.).

5

ja, genau so habe ich es auch gemeint.
Wenn ich nur zB einen zyklische Ablauf unterbinden wollte, das Modul aber normal nutzbar wäre, würde ich das dann anders lösen.

Ich bin mir nicht ganz sicher, ob ich das genau richtig verstanden habe. Meine o.g. Stati sind nicht 101 etc sondern # 201 (ff), also Custom-Stati. Das fand ich sauberer als Standard-Stati zu benutzen.

6

Hallo,

Also ich verstehe es eher so, das ein modul welches man deaktiviert nichts automatisch bzw ereignisbasiert machen soll.

Wenn ein user aber in einem script/ablaufplan oder was auch immer eine funktion aus dem modul nutzen möchte, zum beispiel weil er einen eigenen automatismus hat, sollte er dies können ohne das modul explizit zu aktivieren (weil eben das aktive modul irgendwas automatisiert macht).

Gut, wird von der art und weise des moduls abhängen, aber mich würde interessieren wie es von symcon gedacht ist

Viele grüße

7

Naja, wenn ich ein bestimmtes Modul einsetze, weiß ich ja worauf ich mich einlasse und wie es funktioniert und was es leistet und was nicht.
Wenn es nicht das tut, was ich benötige, werde ich es vermutlich nicht einsetzen oder mache einen Verbesserungsvorschlag. Letzten Endes muss ich aber damit leben, was der Modul-Entwickler mir freundlicherweise kostenlos anbietet oder ich nutze es halt nicht.

Meine persönliche Sicht ist, dass wenn ich ein Gerät deaktiviere, dies auch nichts mehr tun soll. Wenn ich z.B. ein Gateway deaktiviere, weil ich temporär sämtliche Kommunikation mit dem Bus blockieren möchte, dann will ich ja nicht, dass es munter weiter arbeitet, nur weil ich in irgendeinem Skript vielleicht direkt eine Funktion des Gateways nutze.

Gruß
Slummi