Routing beforeFilter e afterFilter

[guest]

Post splittati da questo 3d: Kohana o CodeIgniter

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?

[Uno]

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

[guest]

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.

[Uno]

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?

[guest]

L'esempio l'ho fatto nell'altro thread, quello in cui ho postato un pezzo di codice.

[Deflagrator]

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?[/QUOTE]

Usa il metodo __destruct

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...

[andrea.paiola]

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

[guest]

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.

[Deflagrator]

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.

[guest]

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.

[Deflagrator]

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.

Mmmm, io non so con che logica stai sviluppando router e controller, però potresti inserire tutte le chiamate che ti servono nel construct, tipo:

__ contruct {
$this-> beforefilter
$this-> method
$this-> afterfilter
$this-> view
}

Ma ovviamente, tutto sta a come hai progettato il funzionamento...

[guest]

Guarda, supponiamo di sviluppare una grossa applicazione con 100 Controller per il frontend ed altrettanti controller di Backend accessibili solo tramite autenticazione.

200 Controller = 200 File come minimo.

Nello sviluppo di questi 200 file le probabilità nel dimenticarsi di mettere un qualcosa tipo <? if (empty($_SESSION['username'])) die(); ?> sono esponenziali.

Quello che quindi vorrei fare è, senza mettere mano in alcun modo al controller e/o alle view, poter eseguire determinati metodi direttamente dal router.

Ad esempio, al router vorrei dire che tutto ciò che inizia con /admin/ deve eseguire il controller come di consueto ma PRIMA deve eseguire un mio metodo Auth::checkLogin().
Il metodo farà la verifica e se il login è stato fatto, allora esce senza fare nulla e prosegue con l'esecuzione del controller, altrimenti, forza un redirect alla pagina di login.

Devo farlo a monte di ogni controller.

Con Kohana posso fare una cosa simile, creando un controller base per le admin, di nome Admin_Controller che estende il controller di Kohana, mettere dentro questo controller il mio check in fase di __contruct e poi istanziare i controller aggiuntivi partendo direttamente dal mio Admin_Controller (ereditando quindi il controllo di login).
Questo è un workaround, ma nel caso sviluppassi un mio router, voglio avere la possibilità di eseguire metodi prima e dopo il routaggio direttamente dal router stesso, senza metter mano al resto del codice.

[Antonio]

Con Kohana posso fare una cosa simile, creando un controller base per le admin, di nome Admin_Controller che estende il controller di Kohana, mettere dentro questo controller il mio check in fase di __contruct e poi istanziare i controller aggiuntivi partendo direttamente dal mio Admin_Controller (ereditando quindi il controllo di login).
Questo è un workaround, ma nel caso sviluppassi un mio router, voglio avere la possibilità di eseguire metodi prima e dopo il routaggio direttamente dal router stesso, senza metter mano al resto del codice.

Con lo ZF hai gli hook che possono essere usati dai plugin; basta fare un plugin di autorizzazione e farlo caricare al bootstrap ed hai fatto (Così faccio io)

Zend Framework: Documentation: Plugins - Zend Framework Manual

Ti ho allegato tutto il flowchart di ZF con i punti di injection usabili

EDIT: Altre slide più approfondite: Zend Framework Dispatch Workflow (v1.01)

[guest]

Dovrei usare il preDispatch quindi.
Però, mi sembra fin troppo complesso da usare ZF.

A livello di programmazione, voi come implementereste un sistema di "pre/post" a livello di router? Io ho il router, ho il framework, funzionano, ma non so come aggiungere queste 4 hook nel modo più elegante possibile.

Mi manca solo questo, poi sono a posto, non voglio usare un FW esterno (e se proprio devo, tra tutti, mi sa che utilizzerò Kohana per fare esperimenti, è il più semplice e più simile al mio)

[Antonio]

Dovrei usare il preDispatch quindi.
Però, mi sembra fin troppo complesso da usare ZF.

A livello di programmazione, voi come implementereste un sistema di "pre/post" a livello di router? Io ho il router, ho il framework, funzionano, ma non so come aggiungere queste 4 hook nel modo più elegante possibile.

Mi manca solo questo, poi sono a posto, non voglio usare un FW esterno (e se proprio devo, tra tutti, mi sa che utilizzerò Kohana per fare esperimenti, è il più semplice e più simile al mio)

Penso che la cosa migliore sia usare il DP Observer con la gestione a plugin.