Ereignisse und Listener
Chamilo verwendet das Ereignissystem von Symfony für eine entkoppelte Kommunikation zwischen Komponenten.
Ereignis-Listener
Chamilo verwendet zwei Speicherorte für Listener:
src/CoreBundle/EventListener/— Symfony-Kernel/HTTP-Listener (Anfrage, Antwort, Ausnahme, Login/Logout, Kurs-/Sitzungszugriff usw.). Beispiele:CidReqListener,CourseAccessListener,LoginSuccessHandler,LogoutListener,ExceptionListener,ResourceDoctrineListener.src/CoreBundle/Entity/Listener/— Doctrine-Entitäts-Listener, die an spezifische Entitäten gebunden sind. Beispiele:ResourceNodeListener,CourseListener,SessionListener,LanguageListener,UserListener,MessageListener.
Wählen Sie den Speicherort, der zu dem passt, auf das Sie reagieren möchten: HTTP-Pipeline-Ereignisse gehören in EventListener/; Entitätslebenszyklus-Hooks gehören in Entity/Listener/.
Ereignis-Abonnenten
Befindet sich in src/CoreBundle/EventSubscriber/:
Ereignis-Abonnenten können auf mehrere Ereignisse lauschen:
Sicherheits-Abonnenten — Behandeln von Login-/Logout-Ereignissen, Verfolgen von Login-Versuchen
API-Abonnenten — Vor-/Nachverarbeitung für API-Anfragen
Doctrine-Abonnenten — Reagieren auf Entitätslebenszyklus-Ereignisse
Doctrine-Lebenszyklus-Ereignisse
Entitäten verwenden #[ORM\HasLifecycleCallbacks] für Datenbankebene-Ereignisse:
Erstellen benutzerdefinierter Listener
Um benutzerdefiniertes Verhalten hinzuzufügen:
Erstellen Sie eine Listener-/Abonnenten-Klasse im entsprechenden Bundle
Kennzeichnen Sie sie als Ereignis-Listener oder Abonnent in der Dienstkonfiguration
Implementieren Sie die Handler-Methode
Wichtige Ereignisse
kernel.request
Bei jeder HTTP-Anfrage
kernel.response
Vor dem Senden der HTTP-Antwort
security.interactive_login
Benutzer meldet sich an
doctrine.prePersist
Bevor eine Entität zum ersten Mal gespeichert wird
doctrine.postUpdate
Nachdem eine Entität aktualisiert wurde
Chamilo-spezifische Ereignisse
Diese Ereignisse werden von Chamilos eigenem Code ausgelöst und sind die primären Integrationspunkte für Plugins. Konstanten sind in Chamilo\CoreBundle\Event\Events definiert.
Events::COURSE_CREATED
chamilo.event.course_created
Nachdem ein Kurs erstellt wurde
Events::COURSE_ACCESS_CHECK
chamilo.course_access_check
Bevor ein Benutzer auf einen Kurs zugreift
Events::COURSE_USER_SUBSCRIPTION_CHECK
chamilo.event.course_user_subscription_check
Bevor sich ein Benutzer für einen Kurs einschreibt
Events::SESSION_RESUBSCRIPTION
chamilo.event.session_resubscription
Wenn ein Benutzer versucht, sich erneut für eine Sitzung anzumelden
Events::LOGIN_CREDENTIALS_CHECKED
chamilo.event.login_credentials_checked
Nachdem die Anmeldedaten validiert wurden
Events::LOGIN_CONDITION_CHECKED
chamilo.event.login_condition_checked
Nachdem zusätzliche Anmeldebedingungen überprüft wurden
Events::DOCUMENT_ACTION
chamilo.event.document_action
Wenn die Symbolleiste des Dokumententools gerendert wird
Events::DOCUMENT_ITEM_ACTION
chamilo.event.document_item_action
Wenn pro Datei Aktionsschaltflächen gerendert werden
Events::DOCUMENT_ITEM_VIEW
chamilo.event.document_item_view
Wenn ein Dokument zur Ansicht geöffnet wird
Events::EXERCISE_REPORT_ACTION
chamilo.event.exercise_report_action
Wenn die Übungsbericht-Seite ihre Aktionslinks rendert
Events::EXERCISE_ENDED
chamilo.event.exercise_ended
Nachdem ein Lernender eine Übung abgeschickt hat
Events::EXERCISE_QUESTION_ANSWERED
chamilo.event.question_answered
Nachdem jede Frage beantwortet wurde
Events::LP_CREATED
chamilo.event.learning_path_created
Nachdem ein Lernpfad erstellt wurde
Events::LP_ITEM_VIEWED
chamilo.event.learning_path_item_viewed
Wenn ein Lernender ein LP-Element öffnet
Events::LP_ENDED
chamilo.event.learning_path_ended
Nachdem ein Lernender einen Lernpfad abgeschlossen hat
Events::ADMIN_BLOCK_DISPLAYED
chamilo.event.admin_block_displayed
Wenn das Admin-Dashboard seine Blockliste erstellt
Events::USER_CREATED
chamilo.event.user_created
Nachdem ein Benutzerkonto erstellt wurde
Events::USER_UPDATED
chamilo.event.user_updated
Nachdem ein Benutzerkonto aktualisiert wurde
Events::USER_DELETED
chamilo.event.user_deleted
Nachdem ein Benutzerkonto gelöscht wurde
Events::PORTFOLIO_ITEM_ADDED
chamilo.event.portfolio_item_added
Nachdem ein Portfolio-Element erstellt wurde
Events::NOTIFICATION_CONTENT_FORMATTED
chamilo_hook_event.notification_content
Wenn der Inhalt einer Benachrichtigung formatiert wird
Plugin-Beispiel: Hinzufügen einer Schaltfläche zum Dokumenten-Viewer
Dieser Abschnitt führt durch, wie ein Plugin einen Ereignis-Abonnenten verwendet, um eine Schaltfläche in eine bestehende Chamilo-Seite einzufügen – ohne Änderung des Kerncodes.
Szenario
Ein Plugin namens MyViewer möchte neben jedem Dokument im Kursdatei-Manager eine Schaltfläche "In MyViewer öffnen" hinzufügen. Das relevante Ereignis ist Events::DOCUMENT_ITEM_VIEW, das von Chamilo ausgelöst wird, wenn ein Dokument angezeigt werden soll. Es enthält die Entität CDocument und eine veränderbare Liste von Links.
Plugin-Verzeichnisstruktur
Haupt-Plugin-Klasse (src/MyViewerPlugin.php)
src/MyViewerPlugin.php)Die Basisklasse Plugin bietet isEnabled(), get($settingKey) und Hilfsfunktionen für die Installation von Kurstools und Einstellungen. Das Singleton-Muster (static $instance) ist die Standardkonvention in Chamilo, da die Plugin-Klasse auch außerhalb des Symfony-Containers (in älteren PHP-Seiten) instanziiert wird.
Ereignis-Subscriber (src/EventSubscriber/MyViewerEventSubscriber.php)
src/EventSubscriber/MyViewerEventSubscriber.php)addLink() fügt HTML zu dem Array hinzu, das von Chamilos Dokumentenansicht-Template neben den integrierten Aktionen "Herunterladen" und "Vorschau" gerendert wird. Der Subscriber verändert niemals die Kern-Dateien von Chamilo.
Registrierung
Es ist keine manuelle Dienstregistrierung erforderlich. Chamilos config/services.yaml aktiviert global das autoconfigure-Flag von Symfony, wodurch jede Klasse, die EventSubscriberInterface implementiert, automatisch als kernel.event_subscriber markiert wird. Solange das Plugin-Verzeichnis geladen ist (über Composers Classmap oder PSR-4 Autoload), erkennt Symfony den Subscriber beim nächsten Cache-Leeren.
Wie die Ereignisdaten fließen
Mehrere Plugins können unabhängig voneinander dasselbe Ereignis abonnieren; jedes fügt Daten zu den gemeinsamen Daten hinzu, ohne von den anderen zu wissen. Die Reihenfolge der Ausführung folgt dem Prioritätssystem von Symfony – übergeben Sie eine Prioritätsganzzahl als zweites Element des Handler-Tupels in getSubscribedEvents(), wenn die Reihenfolge wichtig ist:
Zuletzt aktualisiert
War das hilfreich?