PDA

Visualizza la versione completa : PHP on Rails


DarthWiz
22-12-2008, 16:45
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. :stordita:

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

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ì. :fagiano:

CozzaAmara
24-12-2008, 17:42
Molto interessante la tua esperienza, lo dico da sviluppatore PHP che recentemente sta studiando Ruby-> RoR.

Posso chiederti quali grosse differenze hai notato da PHP a Rails, dove lo sviluppo ottiene dei grossi benefici, dove meno ecc?

:ciauz:

andrea.paiola
24-12-2008, 18:11
scaffold

DarthWiz
24-12-2008, 18:38
Originariamente inviato da CozzaAmara
Molto interessante la tua esperienza, lo dico da sviluppatore PHP che recentemente sta studiando Ruby-> RoR.

Posso chiederti quali grosse differenze hai notato da PHP a Rails, dove lo sviluppo ottiene dei grossi benefici, dove meno ecc?

Per me uno degli aspetti più belli di Ruby è la "naturalezza" con cui permette di esprimere dei concetti: c'è tantissimo "syntactic sugar" che fa sì che un programma ruby ben scritto si legga quasi facilmente come un testo in inglese. Ci sono pochissime cose "inutili" da mettere in giro, e questa è una differenza con cui mi sto un po' scontrando nell'implementazione del mio framework.

Per esempio, in Rails posso tranquillamente fare

u = User.find_by_name_and_surname('Mario', 'Rossi')

mentre col mio framework posso al massimo puntare a un

$u = User::find_by_name_and_surname(array('Mario', 'Rossi'));

che al momento però non è ancora implementato, e si ottiene con un ancor più brutto

$u = User::find('first', array('conditions' => array('name = ? AND surname = ?', 'Mario', 'Rossi')));

Quello che io miro ad ottenere è appunto un framework che dia anche a PHP questo genere di immediatezza espressiva in cui leggo una riga di codice e capisco immediatamente cosa fa. Purtroppo in PHP c'è sempre di mezzo la parola chiave "array", mentre in Ruby basta un semplice paio di [].

Oltre a questo, sempre restando sul linguaggio "puro", Ruby ha da sempre un binding "sensato" dei nomi delle classi, mentre PHP lo avrà solo tra poco: al momento tutti i framework per PHP impongono una sintassi del tipo

$user = new User();
$u = $user->find(...);

che è concettualmente sbagliato perché $user non è un'istanza di User. Tra questo che è sbagliato e inventarti una classe UserPeer (come fa Propel) solo per aggirare i limiti del linguaggio, quando torni a PHP dopo un po' che programmi in Ruby, ti viene da sbattere la testa sul muro. :dhò:


Queste sono considerazioni spicciole sul linguaggio puro e semplice, ma prendendo in considerazione tutto il framework, il discorso si fa ancora più ampio: in Rails c'è una solidissima impalcatura che risparmia tantissimo lavoro tedioso e passibile di errori in PHP semplice. I dati entrano sempre da un controller, interagiscono (praticamente) sempre con il model, escono sempre da una view. In questi tre passaggi le variabili hanno sempre gli stessi nomi (cosa che ho cercato di rispettare anch'io nel mio framework, ma anche qui mi sono trovato un po' limitato dal linguaggio), il flusso di controllo è sempre rigorosamente lo stesso. In più quando si arriva all'HTML, ci sono un sacco di funzioni per aiutare in un sacco di cose. Tra queste sono sicuramente apprezzabili la generazione dinamica degli URL e degli elementi dei form: il programmatore ragiona con gli oggetti astratti della sua applicazione, e su che URL "mapparli" lo decide il framework in base alle regole stabilite dal programmatore, pre-impostate su dei default così ragionevoli che raramente si sente il bisogno di cambiarli.


A me è successo di dover tornare a PHP dopo aver provato tutte queste comodità, e davanti alla tabula rasa m'è venuto un magone mica da ridere. :D 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. :D


Ad ogni modo, per questi prossimi giorni mi prendo un po' una pausa dal PHP, ma vi terrò informati su cosa combino.

Anzi Cozza, se ti interessa fare un giro col ThinFramework fammi sapere, ché piazzo un .tar.gz da qualche parte -- per ora ce n'è abbastanza per fare un piccolo blog come quello che c'è su www.thinserver.org (sito che gira sul mio PC a casa). Magari nelle prossime 24 ore metto "in produzione" il sistema di commenti che ho già scritto, così giusto per far vedere che funziona, anche se la cosa più interessante è vedere il codice, che è molto "railoso" pur essendo PHP. :D

DarthWiz
24-12-2008, 18:40
Originariamente inviato da andrea.paiola
scaffold

Quelli secondo me sono l'attrattiva più grande per i principianti, e in effetti sono utilissimi per imparare com'è il "giro del fumo" in Rails, però all'atto pratico... non li ho mai usati.

Il fatto è che è così facile implementare le cose esattamente come ti servono, che con gli scaffold a momenti perdi tempo. :D

ynw
25-12-2008, 02:38
1) Ruby
2) Plugin
3) Procedure e convenzioni di sviluppo consolidate
4) Community
5) Manutenibilità

andrea.paiola
25-12-2008, 09:38
fai così
prendi sta guida http://ruby.html.it/guide/leggi/151/guida-ruby-on-rails-2/

e ci dici cosa manca, io andrei proprio nell'ordine in cui han fatto la guida

le migration le hai fatte? :D

kentaromiura
25-12-2008, 11:09
DartWiz, se vuoi un mio parere ti conviene, anziché reinventare il volante (e si tutte ste ruote hanno rotto) utilizzare qualche framework già MVC, magari light che abbia già delle cose implementate come
1) sicurezza nelle query al DB e in generale layer di sicurezza
2) una struttura MVC solida e già testata e soprattutto configurabile
3) una community dietro e sopratutto un po di documentazione

io recentemente ho dovuto reinformarmi sul php e cercando un approccio MVC ho fatto le mie ricerchette e son finito su kohana:
http://kohanaphp.com/
che è il figlio maggiore del più famoso codeIgniter, ovvero CI è stato riscritto totalmente in php 5 ora, non dico di usare proprio quello e customizzarlo o svilupparci dei plugin sopra, ma di guardare in giro per non correre il rischio di affrontare problemi già ampliamente superati da altri in maniera rigida, testata, blahblahblah

e comunque qualsiasi cosa tu faccia documenta bene tutto, altrimenti non lo utilizzerà nessuno,
la cosa migliore oltre che usare il docphp nei commenti ( o come si chiama ) è di scrivere un bel po' di tutorial, il primo getting start, poi come far le query al db, come richiamare più di una vista, come passare il controllo ad un altro controller ecc...
Insomma, le cose comuni che ci si aspetta da un framework MVC.

Un esempio di documentazione fatta abbastanza decentemente la trovi qui:
http://www.castleproject.org/monorail/documentation/v1rc2/index.html
:fagiano:

malesherbes
20-01-2009, 09:41
Si, lo so, sono sia tardivo che off-topic (in parte)...:)
Ma già che siete lì a creare framework con supporto MVC
e relativa documentazione,
e dato che il php soffre ed ha sofferto
di ogni genere di fraintendimento possibile nel campo
dell'analisi-progettazione-sviluppo di applicazioni,
evitatene un altro, quantomeno nei "tutorials":
quello definito "anemic domain model".
La maggior parte, della documentazione (non tutta per fortuna)
e soprattutto del
codice che vedo in giro su base MVC
finisce per relegare ogni
responsabilità allo strato C dell'MVC,
pensando che il controller sia il deus ex machina del caso
e che gli oggetti di "business" siano dei puri
contenitori di dati.
Forse, diffondere la cultura del
"responsibility driven design" associata
ad un corretto domain/design modeling, cosa spesso
scoraggiata da alcune implementazioni dello strato
di persistenza, farebbe migliorare molto tutte le
applicazioni, indipendentemente dall'uso del
pattern MVC.
E saremmo tutti meno stressati!! :)

...Si, sono off-topic :)

DarthWiz
20-01-2009, 10:13
Ops, ho buttato il sasso e ritirato la mano. :fagiano:

In verità in questi ultimi giorni al lavoro mi hanno appioppato il padulo del mese (anzi, anche più d'uno) quindi non ho più avuto questa gran sovrabbondanza di tempo libero di cui soffrivo prima e che mi ha spinto a iniziare l'avventura di scrivere un framework.

Ho dato un'occhiata a Kohana e senza dubbio, per quel che offre PHP, sembra ben fatto, ma il mio obiettivo non è certamente creare "il miglior framework MVC per PHP" (sarebbe presuntuoso per uno che programma di professione da poco più di 4 anni), quanto creare "un framework il più simile possibile a Rails", cioè uno dove le stesse cose hanno gli stessi nomi e i file si trovano negli stessi posti.

Sono d'accordissimo sulla questione della cultura che manca, specialmente in ambito PHP perché credo che l'ambiente sia popolato da molti webmaster-improvvisati-programmatori, e credo che il mio framework possa essere utile nei due versi: da una parte permetterebbe al programmatore PHP di avvicinarsi a un framework molto popolare e ben fatto, dall'altra permetterebbe al programmatore Ruby di adattarsi molto velocemente al linguaggio ostile ( :D ) e di "importare cultura" nelle lande selvagge dove quel linguaggio viene parlato. Sento la mancanza di una faccina che ridacchia.

Comunque penso che l'errore del "controller factotum" sia un errore col quale tutti iniziano, forse perché è l'approccio più vicino a quello più naturale per PHP, dove la "pagina" è di fatto il controller, con dentro tutte le istruzioni. L'uso appropriato del model viene inevitabilmente solo dopo un po', ma il punto è accorgersi che si sta sbagliando, e qui è questione di finezza, di apprezzare la "bellezza del codice", cosa che non è istintiva per tutti (io personalmente sono un maniaco e 3/4 del mio lavoro è di refactoring) ma che con un po' di guida da parte di un programmatore più esperto o di buona documentazione si può allenare.

In questi giorni non ho molto tempo ma mi piacerebbe portare avanti il mio lavoro proprio per questo motivo "culturale", perciò mi stavo chiedendo, se qualcuno volesse darci un'occhio per avanzare una critica o magari collaborare, dove potrei pubblicare il codice. Mi vengono in mente i nomi di SourceForge e GitHub, ma non ho mai pubblicato un mio lavoro e non saprei quale sistema conviene di più.

Ogni suggerimento è il benvenuto.

Loading