2015-06-12 8 views
7

Sto lavorando a un'app Mojo e mi piacerebbe poter utilizzare alcuni ruoli Moose per semplificarmi la vita.Do Mojolicious e Moose giocano bene insieme?

Su CPAN Vedo MojoX::Moose::Controller, che ha interni molto semplici. Non vedo molto altro sull'uso di Moose con Mojo. Qualunque problema potenziale dovrei essere a conoscenza o è solo una navigazione scorrevole?

+0

Controlla il gruppo Mojolicious di Google o #mojo sui server IRC di Perl. –

+3

Grazie. In realtà sono su IRC, quindi questa sarebbe la mia prossima mossa, ma ho pensato che sarebbe stato utile documentare la risposta qui per coloro che non sono su IRC. – oalders

risposta

5

Nella mia esperienza, lavorano bene insieme. Ho creato con successo Mojolicious apps con Moose (e Moo dovrebbe funzionare egregiamente.)

L'alce può estendere la classe di controller Mojolicious di base e quindi puoi fare qualsiasi cosa al Moose che vuoi. Ecco un esempio:

package MyApp { 
    use Moose; 
    extends 'Mojolicious'; 
    with 'MyApp::Role::Whatever'; 

    sub startup { 
     my $self = shift; 
     my $r = $self->routes; 
     $r->get('/')->to('foo#default'); 
    } 
} 

package MyApp::Foo { 
    use Moose; 
    extends 'Mojolicious::Controller'; 

    sub default { 
     my $self = shift; 
     $self->render(text => "Helloooooo!!"); 
    } 
} 
+1

Se si utilizza Moose per estendere una classe non Moose, è necessario utilizzare MooseX :: NonMoose per evitare interferenze nel costruttore (tra gli altri problemi). – Ether

1

Giocano sicuramente bene. Ho creato un'API che viene eseguita su un cluster di 20 server. È un'app mojo che utilizza anche classi alce che consumano più ruoli.

L'approccio che ho preso è quello di stratificare l'applicazione correttamente, fino al livello di archiviazione. In questo senso, mojo è davvero necessario solo ai livelli superiori nello stack. All'inizio creo un oggetto richiesta basato su alce che viene poi spostato in basso nello stack. Più in basso, viene creato un oggetto di risposta basato su alci che passa la risposta ai livelli superiori della pila. Finalmente mojo prende il sopravvento e gestisce la risposta finale json.

Stiamo spingendo un sacco di traffico di produzione attraverso lo stack e si comporta in modo brillante. Una cosa che ho fatto è stata assicurarsi di utilizzare le versioni XS dei moduli, laddove possibile, come questa prestazione potenziata dello stack.

3

Dal momento in cui inizialmente ho fatto questa domanda, abbiamo spostato del codice Mojo + Moose in produzione. Ci sono alcuni avvertimenti che condividerò qui. Questa risposta è stata effettivamente scritta da Florian Ragwitz. Sto postando per suo conto.

Mojolicious e Moose possono giocare bene insieme, ma è necessario prestare attenzione affinché le cose funzionino bene e ci sono alcuni avvertimenti.

È importante che il costruttore di Moose venga utilizzato per creare nuovi oggetti. Utilizzare MooseX::NonMoose è un modo semplice per garantire che. Senza chiamare Moose durante la costruzione di oggetti, molte funzioni di Alci come il controllo del vincolo del tipo di attributo tipo BUILDARGS, BUILD, e i builder desiderosi non funzioneranno.

MooseX::NonMoose sarà anche delegare all'originale Mojolicious::Controller costruttore, che ha il comportamento di appena benedire gli argomenti del costruttore disponibile in un riferimento hash. Ciò potrebbe causare alcuni risultati strani.

Ad esempio:

package MyController; 

use Moose; 
use MooseX::NonMoose; 

extends 'Mojolicious::Controller'; 

has foo => (init_arg => 'bar'); 

Più tardi ...

MyController->new(bar => 42) # bless { foo => 42, bar => 42 }, 'MyController' 

Si noti come il riferimento ad hash beati risultante contiene le chiavi foo e bar, piuttosto che solo bar come ci si aspetterebbe da una normale classe di alci. Questo di solito non è un problema finché non si intende utilizzare gli slot oggetti con lo lo stesso nome di un altro attributo init_arg.

Esistono anche limitazioni su quali estensioni Moose possono essere utilizzate. Mojo richiede istanze basate su hash, quindi non sarà possibile utilizzare nessuna delle meta istanze non hash basate su Moose, come MooseX::GlobRef e MooseX::ArrayRef. MooseX::StrictConstructor non funzionerà anche in questo ambiente, perché Moose non può stabilire quali argomenti del costruttore sono stati destinati a essere utilizzati dal costruttore Mojo.

Nel complesso, combinando Mojolicious e Moose dovrebbero funzionare abbastanza bene, in pratica, come finché siete a conoscenza dei piccoli avvertimenti e sono OK con il non essere in grado di utilizzare determinate estensioni Moose.

Problemi correlati