Kann jemand beantworten, ob es für Module oder Templates eine Funktion gibt, die bei der (De-)Aktivierung aufgerufen wird?
Um den schlauen Fragen wofür man das braucht zuvorzukommen…:
Bei Installation eines Moduls sollen Tabellen angelegt werden, bei Installation eines Themes halt ein paar Konfigurationsvariablen.
Kann doch nicht sein, dass man in Freiburg nicht an sowas gedacht hat, oder?
lies mal die Anleitung zu metadata.php genauer durch
metadata.php hat mit Themes nicht viel zu tun.
Aber mit Modulen
Es geht primär um Templates. Da muss man auch mal was initialisieren.
Dafür gibt es wohl keine ordentliche Lösung?
Intelligenterweise wäre die API für Templates und Module identisch.
bau dir einfach ein Modul zu deinem Template, wo du die Installationsgeschichten einbauen kannst.
hab ich schon, und jetzt will ich das ganze sinnvoll und für den User nachvollziehbr zusammenführen - sowie man das überall auf der Welt nach den Regel der Programmierkunst machen würde.
… Überall? Ganz Gallien?
Der Welt von World of Warcraft vielleicht…
Bitte ließ eine Beschreibung von MVC durch, was die modulare Programmierung ist und was und wozu Templates sind. Denn Du hast überhaupt keine Ahnung, was die üblichen Regeln der Programmierkunst sind, und versucht deswegen denn Sinn und Zweck von Templates zu vergewaltigen. Einem Auto wachsen ja auch kein Flügel, wenn Du es pink anmalst.
Aber, warum denn so aggresiv? Ein wenig anmaßend, jemand Unbekanntem keine Ahnung in Programmierung zu attestieren, oder? Verzichte doch bitte auf solche kindlichen Worte zugunsten des Themas.
Was ist so falsch daran, nach einem einheitlichen Mechanismus zu fragen, der aufgerufen wird, wenn ein Modul oder ein Template aktiviert wird?
weil ein Fahrrad und ein Motorrad auch nicht die gleiche Antriebstechnik haben - obwohl beide Räder bewegen
Guter Punkt! Fahrzeug-Metaphern scheinen hier beliebt zu sein, aber wir sollten sie dann auch richtig anwenden. Also schieben wir das doch mal auf die passende Ebene:
Es geht ja eben nicht um den ganzen Antrieb (Modulmechanik, Templatemechanik), sondern nur um den Einbau eines Rades (Aktivierung), Fachleute sprechen hier von der Aufhängung. Und jetzt kommts: Das wird bei Fahrrad, Motorrad, Auto, LKW und sogar Space Shuttle mit dem bewährten Kleinteil Schraube gemacht, stimmts?
[QUOTE=oxidusr324;116135]…bei Installation eines Themes halt ein paar Konfigurationsvariablen.
[/QUOTE]
abgesehen davon, dass ich bildliche Vergleiche jederzeit uminterpretieren kann und damit natürlich wiederlegen kann…
Bei der “Installation” eines Themes kann man sehr wohl eigene Config-Variablen setzen. Das gehlt halt nicht ganz so elektrisch, sondern muss als zusätzliches SQL abgefeuert werden. Also wie folgt:
[ol]
[li]die Theme-Dateien hochladen
[/li][li]das Theme-SQL ausführen
[/li][li]das Theme aktivieren im Backend
[/li][/ol]
Vielen Dank Hebsacker,
das ist momentan tatsächlich der einzige Weg und damit die exakte Antwort auf meine Frage - nur unschön.
Die Idee mit dem Templateinstallations-Modul hatte ich vor einiger Zeit ausprobiert. Klar geht das, aber ich halte das für schwer vermittelbar und unelegant.
Hoffentlich stutzt ein mitlesender Entwickler, und denkt konsequent eine metadata.php für Templates an.
Ich hänge mich da mal etwas hier ein.
Mir fällt so spontan eigentlich gar nicht viel anderes ein, außer dass man Konfigurationsvariablen für ein Template zur Verfügung haben möchte. Und da muss ich sagen, dass ich dem oxidusr324 trotz seines überheblichen Stils recht geben muss, dass das in der theme.php doch ganz komfortabel wäre.
Obwohl der Weg über die SQL-Anweisungen für jemanden, der einen Web-Shop administriert, durchaus machbar sein sollte, hätte doch eine »elektrische« Lösung über die theme.php auch Ihren Reiz. Und ich verstehe es doch richtig, dass ich wenn Konfigurationsvariablen vorbelegen möchte, ihren Wert encoden muss. Ich finde das macht die Sache nicht unbedingt transparenter, oder?
Und so etwas wie
$aTheme = array(
‘id’ => ‘azure’,
‘title’ => ‘Azure’,
‘description’ => ‘Azure theme by OXID eSales AG’,
‘thumbnail’ => ‘theme.jpg’,
‘version’ => ‘1.3’,
‘author’ => ‘OXID’,
‘config’ => array(
‘sIconsize’=> array(
‘vartype’ => ‘str’,
‘varvalue’ => ‘87*87’,
‘grouping’ …),
);
mit der DB abzugleichen, ob die Variablen dort stehen und die Werte dem Default entsprechen und ggf. die Variablen einzutragen und einen Reset auf die Default-Werte anzubieten, würde doch vor allem für die nicht-Azure-basierten Themes einen netten Mehrwert bieten, oder nicht?
Gruß
Ansgar