Zend Framework ed altri framework per PHP

[guest]

Ottimo allora.

Ci sarebbe anche Kohana che a quanto pare permette di fare esattamente quello che voglio, non necessita di configurazione (ho appena fatto un Hello World seguendo il tutorial creando 1 solo file, il che è un bene), ha il routing come serve a me:

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

ovvero pesca i controller in altre directory, MA, non posso definire un filtro per l'intera route (o almeno non ci sono riuscito). Dovrei farlo controller per controller.

Una cosa negativa, poi, potrebbe essere la distinzione tra Controller e Controller_Template. Il primo è un normalissimo controller, il secondo è un controller con supporto alle view. Non mi pare una fossa furba, in ottica MVC, dove le view fan parte integrante del progetto.

[guest]

Una soluzione potrebbe essere la seguente, ditemi se fila.
Creo due controller generici estendendo il Controller_Template di Kohana.

Il primo controller sarà:

class Controller_Frontend extends Controller_Template

e l'altro

class Controller_Backend extends Controller_Template

Nel primo caso, è un normalissimo controller da utilizzare come base per i futuri controlli di frontend (Controller_Index extends Controller_Frontend)

Il Controller_Backend, invece, estende sempre il base di kohana, ma avrà al suo interno un filtro "before" che forza l'autenticazione.
In questo modo, chi utilizza il Controller_Backend dovrà essere autenticato.

Successivamente, per ogni controller usato nel backend, come per esempio Controller_Libri (nel caso di un controller per la gestione libri) dovrò estendere il Controller_Backend, ed automaticamente sarà soggetto ad autenticazione.

Il routing resta invariato a quello postato sopra, ovvero un semplice routing con directory. Se "admin" peschi i controller da /admin/ altrimenti fai il routing standard.
Sta ai singoli controller di backend estendere il controller autenticato anzichè il controller pubblico.

Dal punto di vista teorico può andare bene, perchè io devo estendere il controller standard di Kohana a prescindere, quindi non è assolutamente una configurazione extra, ma una normale programmazione ad oggetti.
Una configurazione extra sarebbe dover mettere il check per l'autenticazione in ogni controller admin, cosa che non voglio fare (ed ecco il motivo della discussione) ma in questo caso, io lo inserisco solo e soltanto in un punto. Nel caso avessi bisogno di autenticazioni particolari, faccio l'override del "before" presente nel Controller_Backend direttamente dal Controller_Particolare

[guest]

FUNZIONA!

[andrea.paiola]

quindi usi kohana?

ormai c'è un totoframework in giro eh

[guest]

Dove l'avevi scritto?
Lo sto provando... Ero tentato a C.I. ma poi ho letto che Kohana è un fork che funziona esclusivamente su PHP 5.2 e ne utilizza le sue implementazioni ed allora mi sono orientato su quello.

[andrea.paiola]

Dove l'avevi scritto?

Zend Framework ed altri framework per PHP

ma era un edit, per vedere se ti ero più d'aiuto

[guest]

Link sbagliato? Non vedo il tuo messaggio...

[andrea.paiola]

Link sbagliato? Non vedo il tuo messaggio...

link giusto, post n° 17 del thread Oggi, 09.45.52

[guest]

comunque è un'altra cosa rispetto alla complessità... le regole mi paiono abbastanza semplici e tra l'altro in progetti complessi personalmente cercherei di seguirle lo stesso anche se non me le chiede il framework

Concordo per le regole, ma voglio essere io a dare le mie regole al mio progetto, non deve essere il progetto a dare le regole a me.

Anche con Kohana, che sto sperimentando adesso, ci sono delle regole su come operare, ovviamente, ma solo regole a livello di codice e non a livello logico.
Il programma lo faccio come mi pare, sapendo che un controller va posizionato li, una vista va posizionata di la, il nome del controller va dato in un certo modo in modo che possa essere caricato in automatico delle funzione di autoload e così via.
Questo è corretto, ogni framework ha il suo standard, ma da quel che ho avuto modo di vedere, su symfony devi anche strutturare il database in un dato modo, eseguire da cli determinati comandi per strutturare il progetto e così via.

Troppi automatismi portano a troppe chiusure. Fa tutto lui, se volessi fare manualmente dovrei riscrivere tutte le configurazioni, ed a quel punto, se devo riscrivere metà configurazione del fremework, tanto vale cambiare framework.

Non so se capisci cosa intendo.

Io ho bisogno di alcuni paletti, non di tutto il recinto in cui chiudermi.

[andrea.paiola]

Troppi automatismi portano a troppe chiusure. Fa tutto lui, se volessi fare manualmente dovrei riscrivere tutte le configurazioni, ed a quel punto, se devo riscrivere metà configurazione del fremework, tanto vale cambiare framework.

Non so se capisci cosa intendo.

capisco, ma il convention over configuration funziona così... cerchi un framework che non lo implementi ed essendo uno dei punti cruciali di Rails mi hai confuso!

tra l'altro è uno dei motivi che mi ha un po' allontanato da Rails e Symfony

[guest]

Premetto che non conosco Rails, ma non penso che sia così 'chiuso' come symfony. Almeno credo.
Su symfony o lo riconfiguri tutto (e quindi, a quel punto, conviene cambiare framework) o devi fare come vuole lui. Non penso che Rails sia così.

[andrea.paiola]

Premetto che non conosco Rails, ma non penso che sia così 'chiuso' come symfony. Almeno credo.
Su symfony o lo riconfiguri tutto (e quindi, a quel punto, conviene cambiare framework) o devi fare come vuole lui. Non penso che Rails sia così.

se vuoi ti faccio un'analisi più approfondita, almeno di quel che ricordo... ma non andiamo ot...

[guest]

No no, non mi serve una analisi.
Semplicemente tra me e symfony non c'è stato il colpo di fulmine.

[andrea.paiola]

No no, non mi serve una analisi.
Semplicemente tra me e symfony non c'è stato il colpo di fulmine.

ma questo si era capito, allora ti consiglio di non "perdere tempo" su Rails

ora basta cazzate e vai a lavorare!

[guest]

ma questo si era capito, allora ti consiglio di non "perdere tempo" su Rails

E chi perde tempo su Rails? E' Valeriano che mi ha fatto fare confusione, è sempre colpa sua.

ora basta cazzate e vai a lavorare!

A ma non devo mica fare niente, stavo cercando un framework con una specifica feature, l'ho trovato, ora il mio compito è finito