Come utilizzare gli eventi in WinterCMS - Parte 3

Questo articolo è la seconda parte di una serie di articoli che ci aiuteranno a capire meglio come funzionano e come utilizzare gli eventi nelle nostre applicazioni sviluppate con WinterCMS.

Sottoscriveere un singolo metodo

Riprendendo da dove eravamo rimasti nella seconda parte di questa serie di tre articoli sull'uso degli eventi possiamo passare all'ultima parte parlando dell'uso delle classi invece che delle clousure.

In alcuni casi potremmo volere usare una classe al posto di una closure, la classe verrrà risolta dall'Apllication IoC container fornendoci pieno controllo sulla dependency injection del tuo listener.

La classe evento che andremo a utilizzare può essere registrata con il consueto metodo Event::listen come tutte le altre passando però il nome della classe come stringa, in questo modo:

 Event::listen('auth.login', 'MyEventHandler');

In modo predefinito verrà chiamato il metodo handle della classe

class MyEventHandler
{
    public function handle($data)
    {
        // ...
    }
}

Se per qualche ragione non volessimo usare il metodo handle predefinito possiamo passare il nome del metodo che deve essere sottoscritto, ad esempio:

Event::listen('auth.login', 'MyEventHandler@onLogin');

Sottoscrivere una classe

I subscribers di eventi sono classi che possono sottoscrivere eventi da dentro la classe stessa e devono defiire un metodo subscribe che verrà passato all'istance dell'event dispatcher

class MyUserEventHandler
{
    /**
     *  Gestisce gli eventi di login.
     */
    public function userLogin($event)
    {
        // ...
    }

    /**
     * Gestisce gli eventi di logout.
     */
    public function userLogout($event)
    {
        // ...
    }

    /**
     * Registra listeners per il subscriber.
     *
     * @param  Illuminate\Events\Dispatcher  $events
     * @return array
     */
    public function subscribe($events)
    {
        $events->listen('auth.login', 'MyUserEventHandler@userLogin');

        $events->listen('auth.logout', 'MyUserEventHandler@userLogout');
    }
}

Una volta che il subscriber è stato definito può essere registrato con il metodo Event::subscribe i nquesto modo:

Event::subscribe(new MyUserEventHandler);

Possiamo anche sfruttare l'Application IoC container per risolvere il nostor subscriber, per fare questo passerempo semplicemente il nome del subscriber al metrodo subscribe.

Event::subscribe('MyUserEventHandler');

Il trait Event Emitter

In alcune occasioni potremmo volere "agganciare" un evento a una singola istanza di un oggetto, WinterCms ci permette di farlo sfruttando un sistema di eventi alternativo implementando il trait Winter\Storm\Support\Traits\Emitter all'interno della nostra classe:

class MyUserManager
{
    use \Winter\Storm\Support\Traits\Emitter;
}

Questo trait fornisce un metodo in ascolto per gli eventi lanciati con bindEvent

$manager = new MyUserManager;
$manager->bindEvent('user.beforeRegister', function($user) {
    // Verifichiamo che $user non sia uno spammer
});

Il metodo fireEvent verrà usato per lanciare l'evento:

$manager = new MyUserManager;
$manager->fireEvent('user.beforeRegister', [$user]);

Questi eventi esisteranno solamente nell'oggetto locale diversamente da quelli visti in precedenza che sono al contrario globali.

Abbiamo terminato questa panoramica sugli eventi di WinterCMS con questo ultimo articolo di questa mini serie, se ti sei perso gli articoli precedenti li trovi ai link seguenti

• Parte 1
• Parte 2

Happy coding!

Lunga vita e prosperità