Salve a tutti,<br><br>vi scrivo per parlarvi di un progetto che ho iniziato un circa un mesetto fa.<br><br>Assolutamente non sono qui per "vendervi" un prodotto, visto che non è ancora pronto, ma sono qui a parlarvi del progetto perchè mi piacerebbe poter avere aiuti nello sviluppo, e poi sviluppare da soli non è così divertente (:-)<br>
<br>Il progetto, che si chiama Spyro, è un webframework, scritto nativamente per Python3. La scelta che mi ha spinto ad avviare questo tipo di progetto è la totale o parziale assenza di supporto dai webframework attuali, verso questo ambiente di produzione.<br>
Visto che mi piace stare al passo coi tempi, e che devo sviluppare delle applicazioni web nuove, ho pensato di iniziare io stesso a sviluppare un framework.<br><br>Non voglio essere troppo prolisso, il codice lo trovate qui [1] e ha opportuni commenti.<br>
Il progetto si basa su tre principi:<br> 1- tutti i settaggi devono risiedere in un file esterno.<br> 2- sempre retrocompatibile.<br> 3- esplicito è meglio che implicito.<br><br>Il codice ha meno dipendenze possibili, perchè queste, essendo progetti di terze parti potrebbero minare a quello che si vuole ottenere, specialmente al #2, chiaramente alla fine ognuno usa quello che meglio preferisce, ma lo scopo primario non è quello di consentire di scambiare prodotti di terze parti sulla stessa base.<br>
<br>Una cosa che non ho mai sopportato di vari framework è che per passare dall'ambiente di sviluppo a quello di produzione, quasi sempre devi cambiare alcune cose al codice, spesso per settaggi cosiddetti hard-coded.<br>
Al #1 ho pensato di porvi rimedio con un file esterno di configurazione, sfruttando il fantastico YAML, e tutte le features che questo offre per elaborare il file di configurazione che si passa poi per nome alla classe Application che elabora il file. Questa è la base dell'applicazione WSGI.<br>
Il vantaggio è quello di potersi basare su uno strumento di verifica che permette di riconoscere errori vari. In questo modo il codice si scrive una sola volta: per il testing e per il deploy. Tutto quello che deve cambiare si cambia nella configurazione, e poi si esegue l'applicazione. In questo modo si limitano i bug nell'applicazione derivati da errori fatti da modifiche veloci dei settaggi. Le funzioni che esaminano i settaggi dovranno essere opportunamente migliorate per garantire maggiore sicurezza.<br>
Il #2 è un po' uno dei principi che muovono l'intera community di Python. Troppo spesso però (in senso più generale) mi ritrovo io stesso a dover riadattare i miei programmi per farli girare con nuove versioni delle librerie o applicazioni di terze parti. Tutto questo non vuol dire che non ci debbano essere miglioramenti o aggiunte di funzionalità, ma tutto quello che cambia sotto la "corteccia" non deve minare la funzionalità di un metodo messo a disposizione, e questi ultimi non devono essere rinominati, rimossi o eseguire qualcosa di diverso da quanto originariamente previsto (va bene farlo diverso ma deve fare quello). In questo modo spero di poter garantire una base su cui lavorare in modo stabile e far girare una applicazione con una qualunque versione del webframework, senza incompatibilità. Nuove features e nuovi metodi sono quindi OK, ma piuttosto di rimuoverne uno obsoleto stando a questo principio bisognerebbe usare un livello di astrazione e quindi riscrivere il corpo del metodo/funzione e farlo funzionare con i nuovi metodi.<br>
Il #3 si riferisce un po' in termini generali all'approccio del framework. Mi piace che le cose siano autoesplicative, e che ci siano opportuni metodi per salvare i dati e cose simili, senza rendere misterioso come il framework funziona. I programmatori non devono perdere tempo a capire come e/o perchè una cosa funziona, ma devono concentrarsi solo sulla propria applicazione.<br>
<br>Il codice probabilmente è da riscrivere in qualche parte o magari solo migliorare altre parti. Le poche applicazioni web che ho sviluppate per la maggior parte le ho fatte in PHP (conosciuto Python son passato a cose di basso livello in C) e da allora la mia mente è sempre rimasta un po' legata a questo approccio, dove tra dev e deploy cambiano i settaggi del server e poco o niente del codice. Anche se il web non è mai stato il mio target primario, almeno non il web che si "vede", avendo lavorato a qualche applicazione C/C++ di networking tra cui webserver.<br>
Attualmente l'unico server WSGI già pronto che ho trovato per Python3 è wsgiref e uso quello per i test, ma ho in progetto di riscrivere e completare un server in C asincrono da interfacciare con le nuovi API Python3.<br>
<br>Il framework attualmente fornisce tutto il necessario che mi è venuto in mente per fare una applicazione, compreso il session manager (che magari non sarà dei migliori ma funziona). Trovate nella cartella "devs/" una alternativa al session manager che usa un'altro approccio, ma espone a rischi di sicurezza descritti in cima al file, e comunque l'overhead descritto nel file TODO [(!4) nella lista Future Versions] avviene solo la prima volta ed è visibile con "ab" perchè questo non invia all'app gli header necessari per recuperare il session identifier.<br>
Manca una feature oggi molto diffusa, ovvero il passaggio di argomenti da parte dello url-dispatcher, nella forma /controller/id/value, è da aggiungere in una futura release, comunque per ora consente di accedere facilmente a dati GET, POST, COOKIE e tutte le variabili d'ambiente WSGI. L'url dispatcher comunque supporta le regexp ed esegue una ricerca lineare nel dict che descrive le url (ricavato come descritto nella documentazione).<br>
<br>Manca un ORM built-in che però mi piacerebbe implementare sulla falsariga di Autumn, che sembra comunque non più attivo da tempo. SQLAlchemy lo trovo davvero molto featured, mi piacerebbe una cosa più semplice (non un sostituto di SQLAlchemy). Fare un abstraction layer per semplificare le cose come Elixir implicherebbe che io conosca bene SQLAlchemy cosa che purtroppo non sò. Elixir stesso non ha supporto a Python3, e l'autore mi ha confermato che non c'è in cantiere alcun supporto a Python3 (dicendomi addirittura che forse non ci sarà mai). Per ora il database manager supporta solo pgsql tramite py-postgresql con query SQL.<br>
Per il templating adesso da default si appoggia a Jinja2, appena altri engine saranno Python3-ready verranno aggiunti al supporto.<br>Come noterete tutto è ben integrato e si fà largo uso del Register (rappresentazione interna dei dati contenuti nel file YAML).<br>
<br>Mancano anche alcuni (ok, tutti tranne uno :s) test perchè quelli che scrivevo io non erano automatici, in quanto richiedevano l'uso di una applicazione di test in esecuzione. Spero possiate aiutarmi anche a scrivere quelli.<br>
<br>Spero di non avervi annoiato, e soprattutto spero che qualcuno sia disposto ad aiutarmi, anche solo criticando il lavoro o dandomi consigli su come gestire il progetto. E' il mio primo vero progetto Open Source, ed è sotto licenza 2-clause BSD ed ogni aiuto è ben gradito (proprio ogni tipo di aiuto, sottolineo, anche correzioni nei commenti se non sono chiari o scrittura della documentazione).<br>
<br>Ci sarebbe molto altro da dire, ma preferisco che sia il codice a parlare (forse ho dimenticato di dire qualcosa di importante, nel caso chiedete), e se avete bisogno chiaramente resto a disposizione. Se su questa ML creo disturbi potrei sempre creare una ML su google groups se qualcuno è interessato.<br>
<br>Quasi dimenticavo, i target principali sono i sistemi *nix e *nix like (linux, bsd e os x sopra a tutti).<br><br>Resto a disposizione, buona serata a tutti.<br><br>[1] <a href="http://code.google.com/p/spyro/">http://code.google.com/p/spyro/</a><br>