Von Hook auf Moduleinstellungen zugreifen

[b2m]

Hallo zusammen,

folgende allgemeine Problemstellung:

- eine Funktion (Methode einer Klasse...), die über einen Hook aufgerufen wird, soll nur von bestimmten Modulen ausgeführt werden und dabei soll die Funktion auch noch auf die Modulparameter zugreifen können.

konkret an einem Beispiel:

- eine über den parseArticles Hook registrierte Funktion (Methode einer Klasse...) soll nur ausgeführt werden, wenn es sich bei dem Modul um eine ModNewsList handelt und dabei soll auch noch auf die Einstellungen dieses Moduls zugegriffen werden.

Als einfachste Lösung hätte ich debug_backtrace mit dem seit PHP 5.1.1 verfügbaren object Rückgabewert gewählt. Jedoch kommt mir das beim weiteren Überdenken so vor, als ob ich quasi von hinten durch die Brust ins Auge... na ihr wisst schon. Mir fällt aber spontan keine andere Lösung ein. Vielleicht schwirrt jemandem eine Systemvariable... von Contao oder eine andere Idee im Kopf herum, mit der er/sie mich beglücken kann.

Gruß b2m

[Toflar]

Redest Du von einem bestimmten Hook der bereits im Core vorhanden ist oder willst Du einfach wissen, wie man das am elegantesten Lösen würde.

Also was mal klar ist: Wenn der Hook nicht irgendwie das Modulobjekt übergibt, kannst Du es eh bereits vergessen, weil woher soll der Subscriber-Code wissen, in welchem Kontext er gerade aufgerufen wird.

Ansonsten einfach mit instanceof arbeiten. Es gibt viele Möglichkeiten. Du könntest die gewollten Klassen in ein globales Array speichern und beim Aufruf prüfen ob es darin vorkommt. Oder Du könntest die entsprechenden Klassen mit Interfaces erweitern:

class MyClassToCall implements CallableClass 

und dann mit

if($this instanceof CallableClass) 

prüfen, ob diese Klasse dazu gehört.

Oder eine abstrakte Klasse definieren, von der alle "callable" Klassen erben...

Naja, viele Wege führen nach Rom

[b2m]

Hi,

Redest Du von einem bestimmten Hook der bereits im Core vorhanden ist oder willst Du einfach wissen, wie man das am elegantesten Lösen würde.

Hook ist schon vorhanden, bekommt aber 'nur' das Template und ein Objekt mit den Daten aus der Datenbank.

Also was mal klar ist: Wenn der Hook nicht irgendwie das Modulobjekt übergibt, kannst Du es eh bereits vergessen, weil woher soll der Subscriber-Code wissen, in welchem Kontext er gerade aufgerufen wird.

Eine Lösung wäre wie schon beschrieben debug_backtrace, womit man sogar auf die entsprechende Instanz des Objektes zugreifen kann und somit Zugriff auf die Moduleinstellungen hätte (was genau das ist, was ich bezwecken wollte).

Ansonsten einfach mit instanceof arbeiten. Es gibt viele Möglichkeiten. Du könntest die gewollten Klassen in ein globales Array speichern und beim Aufruf prüfen ob es darin vorkommt. Oder Du könntest die entsprechenden Klassen mit Interfaces erweitern:

class MyClassToCall implements CallableClass 

und dann mit

if($this instanceof CallableClass) 

prüfen, ob diese Klasse dazu gehört.

Oder eine abstrakte Klasse definieren, von der alle "callable" Klassen erben...

Naja, viele Wege führen nach Rom

Daran habe ich auch schon gedacht, aber ich möchte ja auf eine bestimmte Instanz eines Objektes zugreifen (also quasi ein

$this->_caller->_caller->item 

) und da komme ich mit OOP afaik nicht zum Ziel (oder habe ich da etwas falsch im Kopf). Eine alternative und üblichere Variante für das Problem wäre natürlich eine eigene Klasse in Contao zu registrieren, die von ModuleNewsList erbt und die entsprechende Methode überschreibt. Dann habe ich aber wieder das Problem mit anderen Erweiterungen inkompatibel zu sein und deshalb suche ich nach einem anderen Weg über einen Hook. Das klappt prinzipiell ganz gut, aber das Backtracing kann afaik über PHP/Servereinstellungen beeinflusst werden (muss das noch einmal recherchieren) und ist somit sehr vom Webspace abhängig.

Deshalb hatte ich gehofft einen alternativen Weg zu finden, um an die Instanz eines Callers zu kommen bzw. respektive in Contao einen Hinweis auf das gerade abgearbeitete Modul mit Zugriff auf die entsprechenden Einstellungen.

So ich glaube ich drücke mich gerade etwas wirr aus und sollte da noch einmal eine Nacht darüber schlafen.

Gruß b2m

[xtra]

Du koenntest tricksen und ein eigenes Modul registrieren, welches die NewsListe erweitert und im "FE_MOD" ersetzt.

Dort in der parseArticles dann folgendes:

class MyExtendedNewsList
{
public function parseArticles($objArticles)
{
$GLOBALS['parseArticlesCaller'] = $this;
$varBuffer=parent::parseArticles($objArticles);
unset($GLOBALS['parseArticlesCaller']);
return $varBuffer;
} 

Ist zwar auch von Hinten durch die Brust, trifft damit aber immerhin schon zwei Augen und ein Hyhnerauge...

[b2m]

Hi

Du koenntest tricksen und ein eigenes Modul registrieren, welches die NewsListe erweitert und im "FE_MOD" ersetzt.

das machen andere Module aber auch (z.B. Tags), somit müsste ich afaik Ausnahmen für alle Module schreiben, die evtl. ebenfalls die NewsListe ersetzen und stets auf Zack bleiben, ob es da neue Module gibt bzw. ob sich da evtl. die Parameter der Methoden geändert haben... Deshalb suche ich gerade nach einer alternativen Lösung für meine alternative Lösung, die momentan so aussieht:

        foreach (debug_backtrace() as $b) {
            if ($b['class'] == 'ModuleNewsList') {
                $mod = $b['object'];
                 break;
            }
        } 

Da die Module, die ModuleNews (da liegt parseArticles) ersetzen, anschließend nochmal nen parent call zu ModuleNews machen, umgehe ich damit die Kompatibilitätsproblematik, missbrauche aber eine PHP Funktion für etwas, wofür sie eigentlich nicht geschrieben wurde, und das gefällt mir noch nicht.

Gruß b2m