Mehrere Eventlistener in services.yml

[D@ve]

Macht es von der Performance einen Unterschied, ob man mehrere listener in der services.yml einträgt?

Wird in meinem listener gerade ziemlich voll und unübersichtlich die Idee war es das nach Dateien aufzuteilen vietopic_listener, viewforum_listener etc.

Oder was ist da die best practise?

thx,
Gruß, Dave

[Elsensee]

Habe mich jetzt etwas in den Symfony-Code eingelesen, der da ausgeführt wird... Oder es versucht... Für mich sah das bloß so aus:
Man trägt es in der services.yml ein -> Symfony -> Magie -> es funktioniert.

Na gut, Spaß beiseite..
Ich kenn das Problem mit einem vollem, großen und langen Event Listener, doch im Gegensatz zu dir, konnte ich noch keine mich zufriedenstellende Aufteilung finden.
Soweit ich das gesehen habe, wird bei mehreren Event Listeners lediglich je einmal mehr eine foreach-Schleife ausgeführt, in der einige relevante Informationen zur Klasse des Event Listeners und sowas ermittelt werden, bevor er dann letztendlich als "SubscriberService" hinzugefügt wird. Beim Hinzufügen wird jedoch lediglich die in deinem Event Listener durch EventSubscriberInterface implementierte Funktion getSubscribedEvents() aufgerufen und die Zugehörigkeit Event-Name => Funktion gespeichert. (Man kann übrigens in der Funktion getSubscribedEvents() auch noch ganz andere tolle Dinge machen, um z. B. die Priorität deiner Funktion in der "Aufrufhierarchie" zu ändern...)
Danach passiert die weitere Magie einfach so, als würde alles aus einer Datei kommen.

Zusammengefasst: Die Performance wird im Regelbetrieb vermutlich kaum merklich bis gar nicht darunter leiden. Ich habe auch schon ein paar Extensions gesehen, die den Event Listener auf zwei Klassen aufgeteilt haben.

[D@ve]

Symfony -> Magie -> es funktioniert.

So arbeite ich gerade auch... Symfony/phpBB3.1 ist für mich gerade so ein Puzzle der Erkenntnis. Vieles Sehe ich gerade einfach nur als Blackbox Input => Voodoo => Output
Ich verstehe nicht warum, es funktioniert, ich verstehe nicht, wie es funktioniert, aber es funktioniert... Aber langsam füllt sich das Puzzle mit Teilen.

Unser Prof hat immer gesagt: "Wenn eine Klasse mehr als 500 Zeilen Code hat, ist es unsauber programmiert" und hat knallhart Punkte abgezogen, wenn man deutlich drüber war...

Auch wenn man das nicht immer 1:1 auf PHP übertragen kann, hat er doch eigentlich recht (ein Kommentar über den phpBB-Code spare ich mir hier besser). Ich hab mir das Limit vor einiger Zeit selber so bei 1000 Zeilen gesetzt und da bin ich jetzt mit meinem Listener und merke schon, dass es unübersichtlich wird.

thanks anyway.

[Elsensee]

Ich verstehe nicht warum, es funktioniert, ich verstehe nicht, wie es funktioniert, aber es funktioniert... Aber langsam füllt sich das Puzzle mit Teilen.

Ja, ich denke auch, dass Programmierer einfach so arbeiten. Ich las mal, dass eine API für den Programmierer quasi auf Anhieb verständlich sein sollte, aber ich könnte so einfach nicht arbeiten. Ich muss entweder wissen, wie es von innen aussieht, oder, wie du auch, ein Beispiel sehen, in dem das genau beschrieben wird.
Damals bei 3.0 hatte mich der Support an den Code herangeführt. (und auch an die Sprache PHP allgemein ) Mittlerweile reicht das nicht mehr aus, weil 3.1 so viel komplexer ist. Zum Glück helfe und programmiere ich da noch an Extensions. Ohne Extensions wüsste ich z. B. nicht, wie und warum das BBCode-System so funktioniert wie es funktioniert. Und ohne deine Frage, hätte ich vermutlich nie nachgeguckt, wie Event Listener registriert werden. Also ja - das Puzzle füllt sich mit Teilen und ich hoffe das phpBB-Team führt nicht nochmal so weitreichende Änderungen an der API durch. Das gehört sich einfach nicht für eine Feature-Version!

Unser Prof hat immer gesagt: "Wenn eine Klasse mehr als 500 Zeilen Code hat, ist es unsauber programmiert" und hat knallhart Punkte abgezogen, wenn man deutlich drüber war...

Auch wenn man das nicht immer 1:1 auf PHP übertragen kann, hat er doch eigentlich recht (ein Kommentar über den phpBB-Code spare ich mir hier besser). Ich hab mir das Limit vor einiger Zeit selber so bei 1000 Zeilen gesetzt und da bin ich jetzt mit meinem Listener und merke schon, dass es unübersichtlich wird.

Das ist ein guter Tipp. Danke.
Mein Listener hat jetzt fast 800 Zeilen und es wird schon echt schwierig, da durchblicken, aber ich dachte bisher das würde nur an mir oder meinem Setup liegen, welches zum Programmieren eigentlich echt nicht das Beste ist.. :/
Und beim phpBB-Code hat sich das in den Klassen meist schon verbessert. Die includes/functions.php ist natürlich noch immer zu heavy..

[tas2580]

Warum nicht einfach eigene Klassen/Funktionen anlegen die man dann im Listener nur aufruft? Ich habe das jetzt schon bei mehreren Extensions gesehen, da gibt es dann einen Ordner "core" oder "src" in dem für jedes Event eine eigene Datei liegt, der Listener ruft dann nur noch beim jeweiligen Event die passende Funktion/Methode auf. So kann man seinen Code schön aufteilen und hält den Listener klein und übersichtlich.

Ich würde die Größe einer Funktion nicht an der Anzahl der Zeilen fest machen denn das hängt mir irgendwie zu arg vom Programmierstiel ab. Die einen schreiben { in eine neue Zeile und andere schreiben es in die gleiche Zeile, durch solche Dinge kann sich die Anzahl der Zeilen schnell erhöhen. OK bei phpBB ist das durch die Coding Guidelines alles geregelt, aber wenn du deinen 1000 Zeilen Code neu formatierst kann es gut sein das du nur noch 600 Zeilen hast was dann ja besser sein soll obwohl es der gleiche Code ist. Ich kenne zwar die Regel mit 500 Zeilen, verfahre da aber eher nach der Unix-Philosophie

Schreibe Computerprogramme so, dass sie nur eine Aufgabe erledigen und diese gut machen.

Also Funktionen so oft es geht aufteilen und Sinnvoll in Klassen zusammenfassen, wie viele Zeilen sie haben ist da eher nebensächlich. Oft führt das aber automatisch dazu das man nicht über 500 Zeilen kommt denn um eine Sache zu machen braucht man selten mehr wie 500 Zeilen Code.

Gruß Tobi

[D@ve]

Ich würde die Größe einer Funktion nicht an der Anzahl der Zeilen fest machen denn das hängt mir irgendwie zu arg vom Programmierstiel ab

Ja klar ist das Stil... Sauberer Stil und nicht-sauberer Stil.

An der Uni lernst Du wirklich Hard-Core-OOP... So wie man es eigentlich richtig macht. Und da schachtelt man alles ab. Eine Klasse hat dann manchmal auch eben nur zwanzig dreißig Zeilen. Aber das führt zu extrem übersichtlichem und leicht-verständlichem Code. Weil Du sofort verstehst, was die Klasse macht.

Um das mal zu verdeutlichen. Hab mir für phpBB mal ein Mini-Framework für Formulare gebastelt. Das sieht dann so aus.

Code: Alles auswählen

		$this->message_TXT = new text_box($this);
		$this->message_TXT->rows_INT = 5;
		$this->message_TXT->text_STR = $user->lang['MESSAGE'];
		$this->message_TXT->style_OBJ->width_INT = 300;
		$this->message_TXT->is_required_BLN = true;

		$this->newsletter_CHK = new checkbox($this);
		$this->newsletter_CHK->text_STR = $user->lang['NEWSLETTER'];
		$this->newsletter_CHK->create_item($user->lang['NEWSLETTER_SUBSCRIBE'], 1);

		$this->captcha_OBJ = new captcha($this);
		$this->captcha_OBJ->text_STR = $user->lang['CONFIRM_CODE'];
		$this->captcha_OBJ->description_STR = $user->lang['RECAPTCHA_EXPLAIN'];.
.
.

Es gibt eine Klasse Formular, eine Klasse Formular-Feld, eine Klasse Checkbox (die erbt von Formularfeld), dann wieder eine Klasse für ein Checkbox-Item usw. usw.

Ist zwar noch nicht perfekt. Aber dafür, dass ich das mal an einem Nachmittag runtergeschrieben hab, klappt das gut. Programmieren geht dann auch wesentlich schneller, weil man immer nur kleine Einheiten hat.

Wenn ich mir da gerade anschaue, was ich da heute an der viewtopic rumgeschraubt habe um ein paar URLs umzuschreiben Wo wird die $base_url generiert... warum wird sie bei der einen URL benutzt und bei der anderen nicht... In welchen hooks kann darauf zugreifen.

Eigentlich könnte die viewtopic ein Zehnzeiler sein:

Code: Alles auswählen

.
.
.
if ($post_id_INT)
{
  $topic_OBJ = Topic::load_by_post_id($post_id_INT, $start_INT, $sort_STR);
}
elseif($topic_id_INT)
{
  $topic_OBJ = Topic::load_by_topic_id($post_id_INT, $start_INT, $sort_STR);
}
$topic_OBJ->render();

Und alles andere läuft dann in der Topic-Klasse. Diese besteht aber auch nur aus wenigen Zeilen, weil sie im Prinzip nur ein Array mit Posting-Objekten enthält. Die Postingklasse hat als Properties eine eine Message-Klasse, eine User-Klasse, der User hat eine Avatar-Klasse, Signatur-Klasse usw.

Jede Klasse hat eine render() Methode, die den HTML-Code ins Template schreibt. Die Topic->render ruft dann jeweils die render Methoden von posting auf usw.

Am Ende hat man dann zwar ein paar Dateien mehr als jetzt, aber man hat nicht mehr diese 3000-Zeilen-Trümmer, wo man erstmal drei Wochen studieren muss, um zu kapieren, was die überhaupt alles machen. Man blickt sofort was Sache ist, denn so ein Avatar-Objekt, kennt seine URL, weiß wie groß es ist und es kann dies an die Außenwelt kommunizieren. Sie hat nur eine handvoll Methoden (upload, delete, render) und sonst nichts...

[D@ve]

ooops. hab mich offtopic etwas in Rage geredet... Schon spät...

Aber PHP ist deswegen so als Frickler-Sprache verschrieen und wird im Unternehmensumfeld so gut wie garnicht mehr eingesetzt, weil dieses OOP-Bewusstsein einfach bei den meistens Entwicklern garnicht da ist.

Würde mich aber freuen, wenn phpBB-Entwickler dieses Bewusstsein für OOP etwas mehr entdecken würden. Das würde vieles vereinfachen... Aber das ist schwer. Merke das ja auch bei mir... - es geht ja auch ohne... irgendwie... einigermaßen... und mit viel Gehacke und schlaflosen Nächten.

Und jetzt gute Nacht...

[tas2580]

Ja klar ist das Stil... Sauberer Stil und nicht-sauberer Stil.

Würde ich so nicht sagen, wichtig ist nur das man einen einheitlichen Stiel hat.


Wenn du so ein Fan von OOP bist dann nutze es doch auch
Ein Listener könnte dann so aussehen:

Code: Alles auswählen

static public function getSubscribedEvents()
{
    return array(
        'core.foo_event'        => 'foo_function',
        'core.bar_event'        => 'bar_function',
    );
}
public function foo_function($event)
{
    $my_class->foo();
}
public function bar_function($event)
{
    $my_class->bar();
}

Im Construct musst du halt noch deine Datei mit deiner Klasse einbinden und du hast im Listener nur noch Aufrufe für deinen Code, evtl. noch ein paar Variablen durch schleusen, aber sonst kannst du deinen Code doch komplett aus dem Listener raus halten und in mehrere Dateien verteilen. So bleibt das ganze dann schön übersichtlich.

Gruß Tobi

[nickvergessen]

Also ich splitte meine Listener so auf, dass es Sinn macht.
Die Performance ob jetzt 1 oder 5 Listener aus deiner Extension geladen werden ist vernachlässigbar.

[D@ve]

Naja für mich ist das noch eine Blackbox... Hätte ja sein können, dass da SQL-Queries gemacht werden...

Gruß, Dave