Alt!!
Prima di cospargere di benzina e dare alle fiamme il niubbo che apre discussioni nella sezione sbagliata dando loro un titolo a un passo dal blasfemo, datemi una possibilità di salvare la pellaccia, visto che addirittura ho letto TUTTE le discussioni del forum su Ruby.
La mia storia è questa: da un paio d'anni conosco e uso proficuamente Ruby & Rails (ho iniziato con Ruby puro, Rails solo dopo qualche mese e un po' di gavetta su applicazioni stand-alone), come tanti ho imparato un sacco di cose da questo fantastico linguaggio 100% OO, e il paradigma MVC + Convention Over Configuration di Rails mi ha letteralmente aperto un mondo.
Un mondo che fino a un paio di mesi fa è rimasto il mio "mondo ideale" visto che si sa, gli imprenditori italiani sono "pragmatici", e se tutti usano PHP e Java, bisogna usare PHP e Java per poter sviluppare applicazioni "supportabili" (*), e Ruby lo si deve (testuali parole) sdoganare. Però per farlo serve tempo, e di tempo non ce n'è perché il business corre e bisogna stargli dietro... insomma lo sapete anche voi com'è la trafila. Un paio di mesi fa appunto ho cambiato lavoro e sono finito in una società così pragmatica che mi ha affidato un progetto dicendo sostanzialmente "fallo come ti pare, basta che funzioni". Quello che è successo è che il mio progetto l'ho realizzato con Rails così velocemente che ora sono in largo anticipo sulle specifiche che tardano ad arrivare.
Dato che ho tutto questo tempo libero, per cercare di farne un uso proficuo mi sono messo a scrivere un'implementazione di Rails per PHP 5.3, dato che tra namespace e late static binding ora è possibile avere un'implementazione se non perfetta almeno decente di ActiveRecord, e da lì a discendere.
Il motivo per cui apro questa discussione è fare una specie di sondaggio per capire quali siano le caratteristiche più importanti ed irrinunciabili di Rails, in modo da stabilire delle priorità nell'impelementazione e capire dove posso applicare dei compromessi, visto che certe cose in PHP non si possono ancora fare, come per esempio delle chiamate a metodo appena dopo la dichiarazione della classe, tanto utili in Ruby per fare le associazioni con ActiveRecord o mettere i pre/post-filtri sui controller.
Allo stato attuale, dopo una settimana di lavoro, il mio framework consiste di:
- layout delle cartelle praticamente identico a Rails (app/{models,views,controllers}/*)
- routing degli URL implementato nello stesso modo (:controller/:action/:id configurabili a piacere, ma non ci sono le named routes)
- ActiveRecord implementato come si deve per quel poco che c'è (mi limito a dichiarare la classe model, la tabella viene dedotta tramite Inflector, i campi vengono letti dal db al momento dell'inizializzazione, le istanze sono istanze e i metodi statici sono metodi statici senza troppe porcate)
- il template engine è di una semplicità e versatilità disarmante (i template vengono semplicemente "inclusi" a fine elaborazione con tutte le variabili inizializzate a dovere, e sono in PHP puro e non un qualche altro linguaggio stupido come Smarty)
- ci sono un po' di helper che aggiungo di volta in volta man mano che mi servono (il più importante per ora è url_for, che si appoggia alle routes per creare gli URL)
- i controller supportano la ridirezione e pre/post-filtraggio, ma questi ultimi sono implementati in modo diverso (più elementare) rispetto a Rails.
Per ora il mio prodotto è straordinariamente simile a Rails, ma su certe cose sono tentato di prendere le distanze e sono dubbioso: prendere la strada facile adesso potrebbe portare a gravi inconsistenze poi. Il punto di forza del mio prodotto è proprio l'essere molto simile a Rails (più di altri secondo me), ma non vorrei che prendere le distanze mi portasse troppo lontano dall'obiettivo. A ben guardare, il valore del ThinFramework (così l'ho chiamato) potrebbe essere duplice:
- permettere al programmatore Rails di trovarsi a casa se fosse costretto a lavorare su PHP
- permettere al programmatore PHP di "evolvere" su Rails.
Perciò io sto implementando la cosa in modo che sia vicino a Rails per quelle che sono le mie esigenze e per quella che è la mia conoscenza di Rails, ma magari mi perdo qualcosa, e per questo chiedo a voi: oltre alle caratteristiche che ho elencato, cos'è che vi piace di Rails e vi piacerebbe ritrovare in un framework per PHP?
(*) le mie considerazioni sulle applicazioni "supportabili" le lascio per un altro post, questo è già abbastanza lungo così.
Rispondi quotando
Mesi fa, prima di iniziare il progetto vero e proprio che mi avevano assegnato, mi sono scritto una mia versione di ActiveRecord compatibile con PHP 5.2 giusto per avere una base da cui partire, ma soffriva delle limitazioni di cui parlavo sopra. Ora che invece non mi corre dietro nessuno, ho deciso di affrontare le cose come si deve e scendere a compromessi il meno possibile, di modo che quando uscirà PHP 5.3, il mio potrebbe essere il framework più simile a Rails... anche se essendo per ora da solo a svilupparlo, molto probabilmente finirò presto sopravanzato da qualche azienda, ma poco male: almeno mi sarò divertito e avrò imparato molto sia di Rails che di PHP. 
