Der Fehler wird in deinem Source im Beitrag nicht angezeigt.
Bei der print_r Ausgabe sieht man aber dass das eine “scrips” das andere “scripts” geschrieben ist.
Überprüfe bitte nochmal ob du die Variablennamen korrekt geschrieben hast.
Aber sicher doch (sorry, dass ich das nicht gleich gemacht habe)
Ich habs n bissel zusammengeschnitten, dass es ohne die MySQL DB funktioniert und die unwichtigen Dinge (die das ganze nur unübersichtlicher machen) weggelassen.
Es gibt ein paar Grundregeln von OOP. Eine davon besagt, dass Klassenvariablen immer privat sind.
Das hat mehrere Gründe, wenn auch nicht direkt dich betreffend, aber es sollte dein Problem lösen.
class ccms {
private $scripts = array();
protected function add_script($script) {
$this->scripts[] = $script;
}
}
class addon_test extends ccms {
public function __construct() {
$this->add_script("nonsense.js");
}
}
Außerdem wiedersprichst du hier den Grundlagen der Vererbung, weil ein Addon meiner Meinung nach kein cms ist (kann natürlich sein, dass ccms eine Basisklasse für Addons ist, aber das glaub ich nicht )
Ein viel besseres Layout wäre dieses hier:
class ccms {
private $addons = array();
private $dbcon;
private function load_addons() {
//...
foreach($addon_file) {
$addon_class = require($addon_file);
$this->addons[] = new $addon_class($this);
}
//...
}
public function get_dbcon() {
return $this->dbcon;
}
};
class AddonBase {
private $ccms;
public function __construct($parent_ccms) {
$ccms = $parent_ccms;
}
}
class AddonTest extends AddonBase {
public function __construct($parent_ccms) {
parent::__construct($parent_ccms);
}
}
Sollte sich von selbst klären, wenn du etwas darüber nachdenkst…
Gibt natürlich noch bessere Layouts (zB wo die ccms-Klasse die DB-Verbindung nicht öffentlich zugänglich machen muss) aber so schaut das doch schon viel besser aus
Das steht zwar so nirgends geschrieben, ist aber die übliche Vorgehensweise.
Natürlich gibt es auch Ausnahmen (zB das setzen von temporären Flags), aber auch das sollte von Methoden übernommen werden, damit sparst du dir einige Unannehmlichkeiten später.
Ich hab noch nie eine protected Variable gebraucht
Das liegt daran, dass die Basisklasse keine Ahnung hat was die abgeleitete Klasse daran ändert. Außerdem sind Änderungen durch Basisklassen sowiso sehr selten erwünscht, da abgeleitete Klassen ja nur Funktionalität hinzufügen sollen, aber niemals Funktionalität ersetzen.
Ok, danke für eure denkanstösse.
Ich denke das mit der addon_base ist das richtige (daran hab ich nämlich garnicht gedacht ^^)
Naja, das mit der DB-Verbindung…
Wenn ich das kontrollieren möchte, müsste ich ja eine funktion in der addon_base schreiben, die die Querys übernimmt und auch überprüft. Aber wird das nicht etwas aufwändig, wenn das Addon auch von sich aus die Einstellungen laden könnte, um dann die eigene, nicht kontrollierte Verbindung aufzubauen?
Bzw. wie könnte ich verhindern, dass ein fremdes Addon (oder ein anderer fremder Teil) die Konfiguration laden kann…?
du meinst flock, oder?
Aber da passt ja i-wie gar keine operation, oder? bzw. LOCK_EX wär möglich, aber dann kann man die konfiguration ja sozusagen „löschen“ …
bzw. ich könnte die datei temporär leeren (also inhalt in ner privaten variable speichern) und nacher wieder reinschreiben fatal-error=> konfiguration weg)
achso, ja
bedeutet also, dass das addon dann gar keine verbindung zur DB benötigt…
aber was, wenn es ein addon gibt (oder geben soll xD) welches daten in der DB speichern muss, beispielsweise ein Counter.
Und das übliche problem, dass das addon via filesystem trotzdem auf die konfigurationsdatei zugreiffen kann ist dann ja noch nicht behoben
)
Das steht zwar so nirgends geschrieben, ist aber die übliche Vorgehensweise.
bzw. LOCK_EX wär möglich, aber dann kann man die konfiguration ja sozusagen „löschen“ …
