Grails Filters vs Interceptor

Question

Ho studiato Grails da un po 'di tempo. E analizzato un po 'su Filtri e Interceptor. Entrambi hanno quasi la stessa funzionalità di tracciare le sessioni o reindirizzare utenti non autorizzati in un particolare controller.

Ma sono confuso quando e perché dovrei usare Filtro di Interceptor e viceversa. Dato che gli Inceptor hanno due metodi di controllo beforeInterceptor e afterInterceptor e per i filtri tre chiusure comuni before, after e afterView.

Le mie domande sono quali sono i pro e i contro dell'uso di Filter against Interceptor o viceversa. In questo modo noi, sviluppatori, possiamo decidere quando, dove e perché dovremmo usare o Filtro o Interceptor in un particolare Controller per fare tracciamento, reindirizzamento, ecc.

Answer 1

Utilizzare uno o entrambi gli intercettori in un controller quando l'intercettazione la logica si applica solo a quel controller.

Utilizzare un filtro quando la logica si applica a più (o tutti) controllori, o quando è necessario fare qualcosa dopo il rendering della vista (non c'è l'equivalente dell'intercettore di afterView), o se si desidera mantenere tutto centralizzato in un posto invece di diffondersi tra file di controller separati.

Answer 2

I vecchi filtri (da Grails 2) sono obsoleti in Grails 3. La sostituzione dei filtri è Interceptor.

L'utilizzo di intercettori è per azioni quali: l'autenticazione, loggin, ecc
Gli intercettori (come suggerisce il loro nome) sono Intercettare le richieste web in arrivo e innescare un azioni correlate. Le azioni sono definite nel relativo controller.

Gli Interceptor presentano alcuni importanti vantaggi (oltre ai filtri) come il supporto per la compilazione statica e consentono configurazioni flessibili.
Questi sono i principali 3 metodi di Interceptor:
- booleana prima() {true}
- booleana dopo() {true}
- vuoto afterView() {}

Gli Iterceptors sono configurati come Spring Beans (nel contesto dell'applicazione Spring) e sono configurati per essere auto-cablati con il loro nome.