2013-04-10 19 views
14

Mi chiedo dove mettere gli ascoltatori e gestori di eventi di Laravel. Qualcuno mi ha detto che posso metterli ovunque. Questo è quello che ho provato finora.Dove inserisco ascoltatori e gestori di eventi?

# listeners/log.php 
<?php 
Event::listen('log.create', '[email protected]'); 

# handlers/LogHandler.php 
<?php 
class LogHandler { 
     public function create(){ 
      $character = new Character; 
      $character->name = "test"; 
      $character->save(); 
    } 
} 

# controllers/MainController.php 
    public function test(){ 
     Event::fire('log.create'); 
     return "fired"; 
    } 

# start/global.php 
ClassLoader::addDirectories(array(
    app_path().'/commands', 
    app_path().'/controllers', 
    app_path().'/models', 
    app_path().'/database/seeds', 
    app_path().'/libraries', 
    app_path().'/listeners', 
    app_path().'/handlers', 
)); 

risposta

22

ho intenzione di assumere che si sta chiedendo perché non stanno lavorando, piuttosto che per la conferma di qualcosa che hai a lavorare.

Mentre è corretto che puoi mettere i listener di eventi ovunque, devi assicurarti che vengano effettivamente inclusi - Laravel non cerca nel tuo codice sorgente cercandoli.

Il mio posto preferito per includere tali file è start/global.php. Se guardi in fondo al file puoi vedere dove sono inclusi i filtri, puoi fare lo stesso per includere i tuoi ascoltatori. Sarebbe più pulito per tenerli tutti in un'ascoltatori di file, come tutti i percorsi sono in una file di percorsi ...

# start/global.php 
require app_path().'/filters.php'; 
+0

Grazie, ha funzionato per me! – Strernd

+5

+1 Bel suggerimento. Tuttavia, mi chiedo se ci sia un'altra alternativa interessante ... magari creando una cartella "app/listener" per gli ascoltatori di Class ...? E aggiungendo 'app_path(). '/ Listener',' a 'ClassLoader :: addDirectories (array (' a 'app/start/global.php' ...? –

+0

Penso che funzionerebbe per i gestori, ma dal momento che il gli ascoltatori non sono in realtà delle classi, non penso che verranno mai caricati? –

12

La mia personale opinione è che è cattiva pratica, in generale, al grumo listener di eventi in un posto unico Certo, oggi hai solo bisogno di 2 o 3, ma lo scope può essere aggiunto a qualsiasi progetto in qualsiasi momento, aggiungendo molto di più.

Invece, in genere creo una directory sotto la directory app (ad esempio app/CompanyName) e inserisco tutto il codice specifico dell'applicazione. A dire laravel come trovare i file, è possibile aggiornare il composer.json llike questo:

"autoload": { 
    "classmap": [ 
     // ... 
    ], 
    "psr-4": { 
     "CompanyName\\" : "app/" 
    }, 
} 

Dopo di che, assicurarsi di eseguire composer dump-autoload.

Ora, è possibile creare directory namespace all'interno della directory di applicazioni personalizzate, come app/CompanyName/Events/, ed essere in grado di separare i vostri listener di eventi in gruppi che abbiano un senso, e li mette dentro di un fornitore di servizi, ad esempio:

<?php namespace CompanyName/Events; 
// File: app/CompanyName/Events/LogEventsProvider.php 

use Illuminate\Support\ServiceProvider; 

class LogEventsProvider extends ServiceProvider 
{ 
    public function register() 
    { 
     Event::listen('log.create', 'CompanyName/Events/[email protected]'); 
    } 

    public function create() 
    { 
     // ... 
    } 
} 

Ora è possibile aggiungere questo fornitore di servizi per la vostra app/config/app.php e essere pronti per partire, e hanno tutti i listener di eventi correlati in un unico file, e tutti i listener di eventi in una singola directory, eppure separata in modo che, se qualcosa va storto con uno di loro non è necessario cercare attraverso tutti loro per trovare dove sta accadendo l'errore.

NB: Non l'ho inventato come pratica, ma l'ho trovato da qualche parte lungo la strada. Tuttavia non riesco a ricordare dove fosse.

+0

È buona norma, in generale, registrarsi e ascoltare con la stessa classe Provider? Non sarebbe meglio avere una classe ascoltatrice dedicata? – kitensei

+0

No , hai ragione, è meglio dividere le due cose: ti permetterebbe di testare più facilmente i tuoi ascoltatori di eventi senza alcun ingombro dalla registrazione dei bind del fornitore di servizi. L'ho incluso solo sopra come un'illustrazione di come la registrazione di un listener di eventi può Questo è fondamentalmente il mio punto precedente: registra gli ascoltatori all'interno di un fornitore di servizi e puoi comunque mantenere il controllo completo su dove è posizionato il metodo effettivo di "ascolto". –

Problemi correlati