Klassisches php vs. Objektorientiertes php

[BNa]

Hallo,

is nu ne Weile her, daher mal ne primitive Frage:

Muss ich für 3.2.* Extensions zwingend das/%$=/R§Unsägl.-ausdrücke"§%&/(- objektorientierte php benutzen oder darf es auch klassisches php sein????

Gruß in die Runde,
Bernd

[gn#36]

Du nimmst dein "Klassisches php" und verpackst es in eine Klasse => fertig ist das Objektorientierte PHP das du brauchst

So ungefähr jedenfalls - ganz ohne Klassen wird es nicht gehen, wenn du wirklich eine Erweiterung erstellen willst, die phpBB manipuliert ohne die core Dateien zu modifizieren.

Siehe KB:ext_erstellen sowie KB:ext_erstellen_fortgeschritten (letzteres habe ich noch nicht ganz fertig)

Aber für Zusatzseiten muss du im Grunde nur eine eine Funktion in die Klasse packen, wenn du möchtest, und natürlich kannst du theoretisch den klassischen Weg gehen und selber eine Datei wie die viewtopic.php basteln - phpBB ist noch weit davon weg komplett objektorientiert zu sein. Die Vorlage für in phpBB eingebundene Seiten funktioniert vermutlich immer noch ziemlich ähnlich.

[BNa]

Vielen Dank schonmal,

ich glaub das reicht mir, sofern das building einer normalen klassischen php-class mir nicht unbedingt fremd ist.
Also reicht das erstellen einer klassischen nicht-objektorientierten class{} völlig?

Grüßle....

[oxpus]

Öhm, streng genommen ist eine Klasse ja schon ein Objekt

[BNa]

Ja ne, klar. Muss es in Extensions denn überhaupt class()es geben, also ist es via phpbb.com vorgeschrieben?
Kann ich nicht einfach nur Funktionen schreiben, also mehrere function()s und diese dann in die "Steuerdatei" packen?

[oxpus]

Ja ne, klar. Muss es in Extensions denn überhaupt class()es geben, also ist es via phpbb.com vorgeschrieben?
Kann ich nicht einfach nur Funktionen schreiben, also mehrere function()s und diese dann in die "Steuerdatei" packen?

Selbstverständlich. Das mache ich ja bei Bedarf auch so.

[BNa]

Sehr schön. Vielen Dank an euch Beide für Klärung und Anstoß...

[gn#36]

Das kannst du machen, aber wenn du es über die "normalen" Mechanismen einbinden willst musst du dich glaube ich etwas verrenken um Klassen komplett zu vermeiden. Eine Funktionsbibliothek die du irgendwo einbindest geht sicherlich, aber wenn du nicht an core Dateien ändern willst, dann wirst du wohl mindestens die Klasse bauen müssen, die dann von phpBB eingebunden wird.

Wenn du die Erweiterung in der DB auf .com einreichen willst wirst du um OOP nicht herumkommen. Funktionsbibliothek geht vermutlich auch da, aber der klassische Weg für eingebundene Seiten mit Sicherheit nicht. Es gibt auch Erweiterungen die komplett ohne Klassen auskommen, das liegt dann aber daran, dass sie einfach keinen PHP Code enthalten, sondern nur Style Events nutzen.

[BNa]

Hm, also doch nicht?
Reicht es denn, wenn ich eine "Tarn-class()" einrichte, um dem zu entsprechen?
Also sowas wie eine Pseudo-class(), nur um den Regeln zu entsprechen?
Ohne das ganz private, public, construct, $this->, Doppel-Doppelpunkt :: etc.-Gedöns?
Quasie eine klassische class() im alten(!) php-stil?

Code: Alles auswählen

class blub{

function blab($laber){
if (!empty($laber))
{
return $laber; 
}
else
{
return false;
}

} 

[gn#36]

Wenn es um die Regeln für eine Einreichung auf .com geht - die stehen sicher in irgend einer Ordnung drin. Ich habe sie mir nicht so genau angesehen, was da an alten Methoden nun erlaubt ist und was nicht. Schau lieber selber, bevor ich dir noch was falsches erzähle.

Ich habe glaube ich in noch keiner Klasse einen Grund für private gesehen - wenn ich sowas nutze, dann eigentlich immer protected Wenn du den Kram nicht brauchst, brauchst du ihn auch nicht benutzen. Warum du den Konstruktor nun unbedingt wie den Klassennamen nennen willst ist mir nicht klar, das ist doch das gleiche. Wenn man es nicht nutzen will, dann muss man es nicht übertreiben und kann die Klassen letztlich nur als Wrapper verwenden, wenn auch nicht wirklich in dieser von dir vorgeschlagenen Form.

Es gibt schon Minimalregeln, die deine Klasse erfüllen muss:

• Sie muss im korrekten Namespace liegen
• Sie muss den korrekten Namen haben
• Sie muss mindestens eine Methode bereitstellen, die die Ausgabe ansteuert

In der Methode kannst du dann letztlich genau das machen, was du vorher in der separaten Datei gemacht hast, nur dass du die nötigen Objekte (wie $db oder $template) entweder über den Konstruktor holen musst oder per global. Ich weiß nicht ob letzteres für Einreichungen erlaubt ist. Der Inhalt der Datei ist letztlich also klassisch, nur hast du statt der Initialisierung am Anfang der Datei nun halt eine Klasse als Wrapper.

Wenn du dich in eine core Datei einklinken willst muss deine Klasse mindestens:

• Im korrekten Namespace liegen
• Die Methode static function getSubscribedEvents() enthalten, die das Event der anderen Methode zuordnet
• Die andere Methode in der du die inhaltliche Manipulation durchführst enthalten, die ggf. ihren Parameter $event manipuliert

Innen drin ist dann natürlich nicht mehr alles gleich.

Für Template Dateien hat sich nicht wirklich was geändert, es ist nur zusätzliche Syntax erlaubt. Um Templates an definierten Positionen zu manipulieren musst du nur den korrekten Namen für deine Templatedatei verwenden. Eigene Templates wie bisher.

Das ist dann natürlich nicht mehr ganz das gleiche wie ein include in der core Datei.