Jump to content
Sign in to follow this  
guest

Routing beforeFilter e afterFilter

Recommended Posts

Post splittati da questo 3d: http://www.hostingtalk.it/forum/php/15049-kohana-o-codeigniter.html

 

A me piace più C.I. per la pulizia del codice e della documentazione.

Se dovessi paragonare C.I e Koana direi che il primo è come una Debian e il secondo come Ubuntu.

Possono funzionare entrambi, ma mentre il secondo spinge per la modernità e per offrire optional il primo è solido, va avanti con calma ma con testa (una sola principalmente) ed ha una buona comunità, si trovano buoni tutorial in giro etc... si possono scrivere nuove librerie con facilità etc...

 

Io non ho esaminato Koana a fondo da poter fare un paragone.

Il mio è stato un caso particolare, ed il router di C.I. non mi è piaciuto. Concordo con te su tutto, ma nel nostro caso specifico, noi non scriveremo mai estensioni per koana (quindi non mi interessa sapere se è facile o meno) e sarà molto improbabile che utilizzeremo anche le sue librerie interne, quindi anche in questo caso, non mi importa che strade prende, a me serve il router.

 

Anzi, faccio una doppia richiesta:

a) conoscete un framework MVC ridotto all'osso che mi permetta di gestire routing dinamico e statico come koana, e che mi permetta di definire, sempre tramite routing, le directory da cui pescare i controller in base a dei pattern rilevati nella URL? In più deve avere la gestione di beforeFilter e afterFilter

 

b) nel caso non esistesse nulla di quanto scritto sopra, come implementereste voi tale gestione? il beforeFilter potrei farlo richiamare dal __contruct del Controller base del framework e di default il metodo beforeFilter non fa nulla, ma l'afterFilter? quando lo richiamo ed in che modo?

Edited by Uno

Share this post


Link to post
Share on other sites
Io non ho esaminato Koana a fondo da poter fare un paragone.

Il mio è stato un caso particolare, ed il router di C.I. non mi è piaciuto. Concordo con te su tutto, ma nel nostro caso specifico, noi non scriveremo mai estensioni per koana (quindi non mi interessa sapere se è facile o meno) e sarà molto improbabile che utilizzeremo anche le sue librerie interne, quindi anche in questo caso, non mi importa che strade prende, a me serve il router.

 

Anzi, faccio una doppia richiesta:

a) conoscete un framework MVC ridotto all'osso che mi permetta di gestire routing dinamico e statico come koana, e che mi permetta di definire, sempre tramite routing, le directory da cui pescare i controller in base a dei pattern rilevati nella URL? In più deve avere la gestione di beforeFilter e afterFilter

 

b) nel caso non esistesse nulla di quanto scritto sopra, come implementereste voi tale gestione? il beforeFilter potrei farlo richiamare dal __contruct del Controller base del framework e di default il metodo beforeFilter non fa nulla, ma l'afterFilter? quando lo richiamo ed in che modo?

 

Ehem... C.I. gestisce il routing nella stessa maniera di Kohana, la differenza è che il secondo ha sempre abilitata la query string, invece su C.I. devi deciderlo tu e cambiare una semplice variabile sul config se lo vuoi.

E' decisamente più sicuro l'url senza query string diretta, ovviamente se questa serve, serve.... ma spesso non serve ed inutile che sia li.

Al contrario a Kohana mi pare che manchi (non sono sicuro l'ho visto tempo fa) il rewrite con regex semplificato nel uri routing... quello di C.I è veramente semplicissimo.

 

Che intendi con beforeFilter e afterFilter? Prima ancora di passare al routing e dopo il tutto?

Con questi framework puoi facilmente usare un hook o plugin, per esempio con C.I. se metti una tua classe o una tua funzione su pre_system queste vengono processate prima di qualsiasi altra cosa, solo i benchmark vengono chiamati prima. Se usi post_system o post_controller vengono processati dopo....

Kohana ha dei metodi simili... ma secondo me un pò meno immediati

Share this post


Link to post
Share on other sites

Aspetta, io parlo di Kohana 3, è diverso dal 2. Quest'ultimo è molto più simile a CI, compreso il routing.

 

Non mi piace il routing di CI per il modo in cui bisogna dichiarare le regole, bisogna fare un array con le regola passata come chiave. Non mi piace, ne la logica, ne il modo di scrivere le regole.

 

Kohana 3 è diverso:


Route::set('sections', '<directory>(/<controller>(/<action>(/<id>)))',
 array(
   'directory' => '(admin|affiliate)'
 ))
 ->defaults(array(
   'controller' => 'home',
   'action'     => 'index',
 ));

 

Per beforeFilter intendo gli hooks, CI, da quel che ho appena letto, ti fa definire degli hooks globali, ovvero un "pre_controller" che agisce prima di ogni controller. Io invece devo richiamare l'hooks o direttamente dalla configurazione del router, ovvero il router instrada la richiesta e nel caso ci fosse un "pre" prima di invocare il metodo del controller invoca la mia hook (stessa cosa per il "post") oppure un "pre" fatto direttamente a livello di singolo Controller.

 

Con CI o lo si fa globale o no. Almeno questo ho letto.

Share this post


Link to post
Share on other sites

Mi sa che se non fai un esempio concreto sarà difficile che io possa risponderti.

Immagino che la condizione non sarà nell'url, altrimenti basta metterla nella funzione dell'hoock, ma se è così, cioè non dipendente dall'url, ti basta metterla nel controller no?

Share this post


Link to post
Share on other sites

b) nel caso non esistesse nulla di quanto scritto sopra, come implementereste voi tale gestione? il beforeFilter potrei farlo richiamare dal __contruct del Controller base del framework e di default il metodo beforeFilter non fa nulla, ma l'afterFilter? quando lo richiamo ed in che modo?

 

Usa il metodo __destruct :sisi:

 

Io tempo fa, mi ero messo a sviluppare un mini framework mvc, che praticamente è un pò come lo vorresti tu, cioè nessuna libreria, solo routing e gestione controller, non l'ho completato, però con quello che avevo fatto in poche righe, già svolgeva a sufficenza il suo lavoro...

Share this post


Link to post
Share on other sites
Non saprei, koana sarà anche un fork, ma il codice non è compatibile tra i due progetti. A differenza di Mambo e Joomla nel primo periodo. Non so se uno sviluppatore attuale di kohana tornerà a sviluppare per CI dovendo riscrivere buona parte di codice.

intendevo per i nuovi siti, per roba già esistente in effetti non ha senso cambiare

Share this post


Link to post
Share on other sites

Nel __destruct non va bene, perchè la hook di post deve essere richiamata da dentro il Controller subito prima della view, se lo metto nel destruct sarà richiamata dopo la view.

 

In pratica devo avere:

beforeController

beforeView

postView

postController

 

per il primo e l'ultimo nessun problema, per i due centrali non saprei.

Forse posso provare a metterli dentro la view, nei rispettivi contruct/destroy ma le due hook son dentro il controller, non dentro la view.

 

Comunque sia, anche noi usiamo un nostro framework, e sto appunto cercando di implementare un sistema di routing. Tra tutti quelli che ho provato, Kohana mi è sembrato il più semplice, sia a livello di codice (a prima vista è scritto benissimo), sia a livello di semplicità d'uso.

Share this post


Link to post
Share on other sites
Nel __destruct non va bene, perchè la hook di post deve essere richiamata da dentro il Controller subito prima della view, se lo metto nel destruct sarà richiamata dopo la view.

 

In pratica devo avere:

beforeController

beforeView

postView

postController

 

per il primo e l'ultimo nessun problema, per i due centrali non saprei.

Forse posso provare a metterli dentro la view, nei rispettivi contruct/destroy ma le due hook son dentro il controller, non dentro la view.

 

Comunque sia, anche noi usiamo un nostro framework, e sto appunto cercando di implementare un sistema di routing. Tra tutti quelli che ho provato, Kohana mi è sembrato il più semplice, sia a livello di codice (a prima vista è scritto benissimo), sia a livello di semplicità d'uso.

 

Potresti provare a mettere un richiamo al metodo che ti interessa, all'interno del metodo del view.

Share this post


Link to post
Share on other sites
Potresti provare a mettere un richiamo al metodo che ti interessa, all'interno del metodo del view.

 

No, l'obiettivo è non dover mettere mano alle view o al controller.

Sto cercando di fare in modo che sia il router a richiamare eventuali pre e post, questo serve, come da hint di Valeriano ad evitare che su 350 Controller realizzati ce ne sia magari uno che non verifica l'autenticazione.

 

Può sembrare una stupidata, ma quando hai vagonate di file (centinaia e centinaia) dimenticarsi qualche check non è una eventualità così rara. L'obiettivo è proprio quello di mettere un check a monte.

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
Sign in to follow this  

×