Klassen die nicht überladen werden können

Deutsches Forum
1

Ich habe diesen Thread zum Thema Überladen von Klassen gelesen.

Ich verstehe diesen Part hier nicht:

Hi,
actually this class can be overloaded, but not then it is extended. i mean if somebody uses
class A{}
class B extends A{}
you cannot overload class A if you want to new functionality would exist in class B.
In other words you can write module for class A and then in oxid it will call with oxNew(“A”) it will bring what you expected, but if in oxid there will be oxNew(“B”) you wont get you module code in that object.

Ich habe zum Beispiel ein eigenes Kontaktformular erstellt in dem ich ein Modul erstellt habe, welches ich der Klasse oxubase zugewiesen habe. Vom Code her habe ich mich größtenteils an der Klasse Contact orientiert. Ich habe doch oxubase damit überladen und es funktioniert auch. Wo sind die Einschränkungen bezüglich der Erweiterung der im Beitrag genannten Klassen?

Wenn mich hier jemand aufklären könnte, wäre ich sehr verbunden.

Gruß
Stefan

2

Wenn du eine neue View erstellst, die von oxubase abgeleitet ist, dann funktioniert das. Dafür muss kein Moduleintrag im Admin gemacht werden, weil die View direkt aufgerufen werden kann. In der View steht dann “class myview extends oxubase”.

Wenn du eine bestehende View-Klasse verändern willst, dann geht das mit dem Modul-Mechanismus. Die geänderte View erbt dann z.B. von details. Die View ist dann im Ordner modules, wird deklariert mit “class myview extends myview_parent”, und im Admin ist ein Moduleintrag nötig: “details => myview”. Wenn jetzt im Code oxnew(“details”) steht, wird nicht details sondern automatisch myview aufgerufen.

Wenn man eine Funktion für alle Views braucht, wäre es praktisch, mit dem Modulmechanismus oxubase zu erweitern, so dass automatisch die eigene Klasse statt oxubase aufgerufen wird. Alle Views hätten dann die neue Funktionalität, weil alle Views von oxubase abgeleitet sind. Genau das geht aber nicht, weil oxubase nicht mit oxnew aufgerufen wird, sondern direkt in den Views mit “extends oxubase”.

3

Vielleicht wird es so klarer.


<?php
/**
 * you can't overload me, i'm a base class, other classes extend my 'hardcoded'
 * eg: oxlist => need for oxarticlelist, oxattributelist etc.
 */
class a{
  //some code
}

/**
 * i'm the last core-class in tree, here the extends 
 * is hard coded to the base class.
 * i don't extend my parent by the modul chain, 
 * so i only be inherit by my directly parent
 * eg: oxarticlelist extends oxlist
 */
class b extends a{
  //some code
}

// with eval in runtime generated middel-class 
eval ("class myB_parent extends b{}");

/** 
 * my class-modul, extends a virtual class, created during runtime 
 * eg: 
 * extendedoxarticlelist extends extendedoxarticlelist_parent{}
 * middleclass:
 * extendedoxarticlelist_parent extends oxarticlelist{}
 */
class myB extends myb_parent{
  //some code
}
4

Danke für Eure Erläuterungen. Das bringt mich weiter.

Ich habe mir jetzt auch nochmal die Infos in der Oxid-Dokumentation zum Thema Module durchgelesen, http://www.oxid-esales.com/en/resources/help-faq/manual-eshop-pe-ce-4-0-0-0/expand-oxid-eshop-with-modules

Es gibt ja das Schema, dass man die Modulklassen mit

class modulklasse extends modulklasse_parent

definieren soll. In den Beiträgen in der Dokumentation wird dies aber nicht durchgängig verwendet. Um was geht es dabei eigentlich? Geht es nur darum die Möglichkeit zu schaffen mehrere Module für eine Elternklasse zu definieren oder gibt es dafür noch einen anderen Hintergrund?

Gibt es irgendwo noch mehr Dokumentation zur Modulprogrammierung mit oxid?

5

[QUOTE=stefanwesop;41874]Geht es nur darum die Möglichkeit zu schaffen mehrere Module für eine Elternklasse zu definieren oder gibt es dafür noch einen anderen Hintergrund?[/QUOTE]
Ja darum geht es. Hier gibt’s noch mehr Doku: http://wiki.oxidforge.org/Tutorials