Seite 1 von 2
Klassisches php vs. Objektorientiertes php
Verfasst: 09.01.2017 18:45
von 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
Re: Klassisches php vs. Objektorientiertes php
Verfasst: 09.01.2017 23:32
von 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.
Re: Klassisches php vs. Objektorientiertes php
Verfasst: 10.01.2017 01:07
von 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....
Re: Klassisches php vs. Objektorientiertes php
Verfasst: 10.01.2017 08:12
von oxpus
Öhm, streng genommen ist eine Klasse ja schon ein Objekt

Re: Klassisches php vs. Objektorientiertes php
Verfasst: 10.01.2017 14:12
von 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?
Re: Klassisches php vs. Objektorientiertes php
Verfasst: 10.01.2017 16:08
von oxpus
BNa hat geschrieben: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.
Re: Klassisches php vs. Objektorientiertes php
Verfasst: 10.01.2017 16:41
von BNa
Sehr schön. Vielen Dank an euch Beide für Klärung und Anstoß...
Re: Klassisches php vs. Objektorientiertes php
Verfasst: 10.01.2017 20:26
von 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.
Re: Klassisches php vs. Objektorientiertes php
Verfasst: 10.01.2017 22:15
von 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;
}
}
Re: Klassisches php vs. Objektorientiertes php
Verfasst: 10.01.2017 23:10
von 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.