Das ist noch ein schwarzer Fleck auf der sonst weißen OXID-Weste, da man neue “views” oder Komponenten nur durch Eingriffe in den OXID-Core-Code lösen kann, was aber nicht mehr “update-fest” ist…
Ich habe ein ähnliches Problem wie folgt gelöst:
in “views” habe ich meine neue Klasse “[B]oxcmp_pt_utils.php[/B]” gespeichert.
In “[B]views/oxubase.php[/B]” den array “aUserComponentNames” wie folgt erweitert:
Dann wird die “[B]oxcmp_pt_utils.php[/B]” richtig aktiviert…
Das ist aber der Punkt, an dem die [B]Update-Sicherheit[/B] verloren geht, weil eine neue Version von "[B]views/oxubase.php[/B]"das wieder überschreibt!
Hier muss die OXID AG m.E. [B]unbedingt [/B]nachbessern, weil die Modulentwicklung sonst problematisch wird.
Ich hatte in http://www.oxid-esales.com/forum/showthread.php?t=1571#post9304 einen möglichen update-sicheren Lösungsvorschlag gemacht (für einen OXID_Entwickler gibt es da wahrscheinlich noch elegeantere Lösungen), die Resonanz von OXID-Seite war bisher allerdings eher bescheiden…
Alles klar, dann weiß ich da ja bescheid, vielen Dank
Hab jetzt noch ein bisschen rumprobiert und es mal mit oxarticle gemacht da ich eh gerade dabei bin was für die Artikel zu machen und jetzt geht es, wollte aber eben erstmal nur testen ob das einbinden klappt und dachte mir das ich dafür oxview nehme da des auf den meisten Seiten läuft xD
sry das ich den post wiederbelebe … aber ich hab ein ähnliches Problem … ich hab das test Modul wie oben geschrieben und als
order => test/test eingetragen
was muss ich in der order.tpl eintragen um das aufzurufen [{??? ->testAusgabe()}]
[QUOTE=TG_Cashbtis;39343]sry das ich den post wiederbelebe … aber ich hab ein ähnliches Problem … ich hab das test Modul wie oben geschrieben und als
order => test/test eingetragen
was muss ich in der order.tpl eintragen um das aufzurufen [{??? ->testAusgabe()}]