Verwendung von veraltetem Code

Hallo,

Quote from Christopher Walz

Seit wann entspricht WCF_CLICK_EVENT eigentlich bereits click? Im WSC 3.1 scheint das bereits der Fall zu sein (clickEvent wird nicht genutzt):

Use click event globally for now · WoltLab/WCF@7932131

We need to evaluate if we can use a 3rd party library to consistently use pointer events. Using 'touchstart' has its issues, but gets rid of the lame tap delay.

github.com

Hallo,

Quote from MysteryCode

Heißt das IParameterizedEventListener wird auf absehbare Zeit deprecated?

Neue Events werden auf Basis von IEvent implementiert. Bei bestehenden Events kommen wir auf absehbare Zeit wohl nicht um IParameterizedEventListener drum herum.

Quote from MysteryCode

Standardmäßig komme ich nicht an die aufrufende Klasse und deren Properties und kann generell nur das modifizieren, was der Entwickler des Ausgangspakets vorsieht, wenn ich das richtig sehe.

Das ist korrekt und genau so gewollt.

Quote from MysteryCode

Abgesehen davon, warum sollte ich eine Klasse für einen Listener erstellen und sie explizit aufrufen statt den Part in einer Funktion/Trait/direkt im Code zu handeln?

Das musst du falsch verstanden haben. Konzeptionell funktionieren die Listener und Events wie die bereits bekannten Listener und Events. Mir ist auch nicht klar, wie ich das besser als die Beispiele in den Docs erklären können sollte.

Hallo,

Quote from MysteryCode

Joa, relativ uncool. Also für Drittentwickler, die über die Vorstellungskraft des Entwicklers des Ausgangspakets hinaus gehen wollen.

ich hätte in meiner ersten Antwort vermutlich noch ein wenig mehr ausführen sollen, weil sich in der Praxis eigentlich gar nichts ändert (bzw. die Flexibilität sogar steigt).

1. Die Klassen sind ein sauberer Ersatz für das $parameters-Array, weil du komplette IDE-Unterstützung hast. Auch bei den $parameters bekommst du nur das, was der Entwickler dir bereitstellt.
2. Die „alten“ Events waren nie als Freifahrtschein dafür gedacht an beliebigen Properties vom „feuernden“ Objekt rumzufummeln – hier muss ich erneut auf OO-Best-Practices verweisen. Dass das bislang möglich war ist also kein Feature, sondern eher der seit 2007 kaum überarbeiteten Architektur geschuldet, die zum Teil auch durch den schäbigen OO-Support in PHP um 2007 bedingt war. Diese feste Bindung an die Klasse die das Event feuert sorgt dafür, dass die bestehende Implementierung in der Praxis in Beton gegossen wird.
3. Du kannst jetzt dasselbe logische Event an mehreren Stellen feuern. Bei dem Entwurf explizit als PoC-Beispiel genutzt wurde das in der Doku beispielhaft genannte UserLoggedIn-Event. Aktuell gibt es keine sinnvolle Möglichkeit zu erkennen, wann sich ein Benutzer konzeptionell einloggt, insbesondere wenn alternative Login-Möglichkeiten durch Plugins hinzukommen. Die Events in changeUser sind kein sinnvoller Indikator.
4. Funktionieren die Events in der JavaScript-DOM-API, Javas Swing, den großen PHP-Frameworks (Laravel, Symfony) und PSR-14 ganz genau so. Dort scheint es offensichtlich auch zu funktionieren
5. Freuen wir uns natürlich über sinnvolle Vorschläge für Events. Insbesondere, da neue Events jetzt deutlich weniger invasiv in bestehenden Code integriert werden können. Es sind keine neuen Objekt-Properties von Nöten, die Events sind von der bestehenden Implementierung entkoppelt, was notwendiges Refactoring erleichtert, und auch dieser Pfusch mit $parameters entfällt.

Hallo,

Quote from MysteryCode

Die IDE Unterstützung ist prinzipiell super, ich hatte bisher halt immer instanceof verwendet oder phpDoc; je nach Anwendungsfall.

Die IDE-Unterstützung funktioniert aber nicht mehr mit $parameters (ist beispielsweise in der Email-Klasse im Einsatz). Versuch mir mal ohne in den Code zu schauen zu sagen wie du den Versand einer E-Mail mit einem EventListener verhinderst. Mit den neuen Event-Klassen wäre das ein $event->preventDefault() (in Anlehnung an JavaScript).

Quote from MysteryCode

Beispielsweise konnte ich einzelne Objekte aus der Liste herausnehmen oder auf einfache Art Bedingungen zu DatabaseObjectList-Objekten auf Seiten hinzufügen. Gut, effektiv hängt es schlussendlich von der genauen Implementierung der Events ab…

Das nutzen wir auch in unseren Plugins. Die Events hast du bei den Page|Form|Actions ja zwangsläufig weiterhin. In einer neuen Implementierung könnte die Page|Form|Action hypothetisch direkt IEvent implementieren, wenn es nur ein einziges sinnvolles Event für die Klasse gibt. Alternativ benutzt man irgendwie so etwas:

<?php
final class BeforeSelect implements IEvent {
  public function __construct(MultipleLinkPage $page) { /* … */ }
  public function getObjectList(): DatabaseObjectList { return $page->objectList; }
}

// Benutzung in der UserListPage.
EventHandler::getInstance()->fire(new BeforeSelect($this));

Ich möchte nicht ausschließen, dass es da noch weitere Anpassungen gibt, wenn sich herausstellt, dass gewisse Dinge in der Praxis zu unschön werden. Das BeforeSelect-Event würde ich so wie beispielhaft dargestellt vermutlich nicht implementieren.

Quote from MysteryCode

ich verweise hier einfach mal auf unsere qualitativen Diskussionen über Events hier und da, bei denen immer die Frage kommt "warum?" statt einfach mal "warum eigentlich nicht?"

Mit jeder neuen öffentlichen Schnittstelle und damit auch mit jedem Event geht man ein Commitment ein. Insbesondere mit dem bisherigen Konzept kommt dann wieder der Punkt mit dem Beton zum Einsatz: Wir müssen genau die Klasse mit genau den Properties beibehalten. Mit den unabhängigen Event-Klassen kann man das Event potentiell verschieben.

Ein ganz konkretes Beispiel: https://github.com/WoltLab/WCF/issues/3608. Wenn es jetzt ein UserLoggedOut-Event gäbe, dann könnte man das Event in ein neues LogoutForm mitnehmen und ist nicht daran gebunden, dass der Logout über eine Action erfolgt. Das ist ein Implementierungsdetail was den Entwickler eigentlich gar nicht interessiert. Den Entwickler interessiert, dass ein Benutzer sich ausgeloggt hat – nicht, dass der Benutzer die LogoutAction erfolgreich benutzt hat.

Grundsätzlich gilt aber natürlich weiterhin, dass man für etwaige Wünsche auch einen entsprechenden Use-Case mitbringen muss. Nicht immer ist die vorgeschlagene Lösung auch die konzeptionell sinnvollste Lösung. Stichwort: XY-Problem.

Quote from MysteryCode

Ja, mir ist bewusst, dass man prinzipiell auch ein Objekt der Klasse Foo gegen ein Array hätte tauschen können und das dann vermutlich in der nächsten Funktion knallt, aber so viel Hirn traue ich den meisten doch zu.

Ich würde es nicht auf fehlende „Hirnkapazität“ schieben, aber ich habe im Plugin-Store beispielsweise schon Plugins abgelehnt, die mittels Reflection dafür sorgen, dass Properties von private auf public gestellt wurden. Wenn das dann in einem Refactoring kaputt gehen würde, dann wäre natürlich wieder „WoltLab Schuld“, auch wenn die Intention dahinter durch das private mehr als deutlich sein sollte. Entsprechend sehe ich es auch als Aufgabe vom Framework an da entsprechende Guard-Rails bereitzustellen, damit man es gar nicht erst verkehrt machen kann.

Hallo,

Add UserLoggedIn event and cancel lost password requests upon login by TimWolla · Pull Request #4356 · WoltLab/WCF

Add a UserLoggedIn event Implement the UserLoggedIn event Cancel lost password requests when the user logs in

github.com

Es gibt jetzt einen ersten PR für ein UserLoggedIn-Event auf Basis der neuen Event-Klassen. Da ist dann auch ein beispielhafter EventListener mit drin.

/cc gn5VmUKCtv6ekrMf (der schon Interesse gezeigt hat), Hanashi (der diverse externe Logins im Store hat).

Hallo,

und ein entsprechendes Gegenstück gibt's auch schon für 5.4 → 5.5: https://docs.woltlab.com/6.0/m…54/deprecations_removals/