[Python] Webapp per database in CGI

[Manlio Perillo]

Pietro Battiston ha scritto:
> [...]
> ma anche in qualche paginetta qua e là (ad esempio molte, come te,
> consigliavano almeno WSGI)
> 

WSGI, come CGI, è un protocollo tra il server HTTP e l'applicazione Python.

>>> quindi la mia soluzione di fallback è che semplicemente
>>> mi scrivo tutto da zero; ho già fatto qualche esperimentino e sarebbe un
>>> lavoro lunghetto ma assolutamente fattibile.
>>>
>> Ti consiglio almeno un framework WSGI minimale.
> 
> Mi sembrava di avere capito che il WSGI avesse bisogno comunque di
> processi che girano continuamente, e che in genere gli hosting non te lo
> permettono...
> 

No.
WSGI è molto più flessibile di CGI, e ci sono modi diversi di impiegarlo:

1) esiste un semplice wrapper per fornire l'API di WSGI sopra CGI.
   In questo modo ogni request WSGI è servita da un processo.

2) è possibile implementare WSGI direttamente nel server HTTP, e
   l'implementazione può scegliere di eseguire ciascuna request in un
   processo.

   Google App Engine fa qualcosa di simile a questo;
   ma non so darti maggiori dettagli, se viene al Pycon c'è un talk di
   Guido van Rossum a riguardo:
   http://www.pycon.it/conference/talks/google-app-engine-2

3) è possibile implementare WSGI direttamente nel server HTTP, in modo
   che l'applicazione Python venga eseguita all'interno del server
   stesso.

   Apache mod_wsgi e Nginx mod_wsgi fanno questo.

4) è possibile implementare WSGI in modo che lo scambio dati avvenga
   tramite un protocollo client server su TCP/IP.

   WSGI non definisce nessun protocollo di rete, ma puoi usare SCGI,
   FastCGI o altro (Unbit, ad esempio, ha sviluppato un suo protocollo).

   In questo caso l'applicazione Python viene eseguita da un
   "server WSGI", scritto in Python stesso.

   Come poi il server gestisca le richieste è un altro discorso.


> (ho fatto anche qualche prova con esito negativo, ma data la mia
> inesperienza questo vuol dire poco)
> 
> Comunque l'ultimissimo dei miei problemi è l'efficienza (il database
> potrà essere anche grossino, ma sicuramente l'applicazione non sarà
> utilizzata intensivamente).
> 

Ok, allora usa pure il wrapper WSGI sopra CGI.

Lo trovi nel modulo wsgiref.handlers, nella libreria standard;
oppure integrato nei vari framework WSGI, ad esempio
http://werkzeug.pocoo.org/documentation/deploying

>>> Se però avete qualche libreria da consigliarmi (fondamentalmente un
>>> layer comodo per lavorare su mask via html e/o http), sono tutt'occhi.
>>>
>> Che intendi con "lavorare su mask"?
> 
> Beh, ammetto che se le parole sono vaghe è perché lo sono ancora un po'
> le idee nella mia mente. Però ad esempio, se il lavoro lo dovrò fare da
> zero, dato il mio database, per rappresentare gli elementi di una
> tabella in html mi farò una libreria in cui l'oggetto fondamentale è il
> "campo", di cui ogni istanza è associata ad una particolare colonna di
> una particolare tabella, ad una sua rappresentazione in html e ad una
> modalità di aggiornamento via POST... e per la rappresentazione in html,
> a sua volta, prevederò diverse possibilità (una stringa può essere ad
> inserimento libero, oppure con un menu...). A quel punto una pagina in
> html sarebbe semplicemente la composizione di una serie di campi.
> 
> Un minimo di astrazione del genere la dovrei fare comunque perché
> scrivere un po' di html non mi scoccia, ma vorrei invece che il giorno
> in cui aggiungessi una nuova colonna ad una tabella del database
> l'aggiungerla anche all'interfaccia fosse automatico o quasi.
> 

Ci sono delle applicazioni WSGI che forniscono un API restful per
accedere ad un database.

Io ne ho una (ma sperimentale, ed incompleta):
http://hg.mperillo.ath.cx/wsgix/file/tip/wsgix/contrib/sqltables/

Django fornisce una interfaccia web automatica ad un database; e mi
sembra ci sia un altra applicazione che lo faccia e ora non mi viene in
mente.

> Per questo chiedevo se una libreria del genere esiste.
> 
> (il database sarà sqlite e forse - mi piace, ma non ho ancora deciso se
> ne vale la pena in questo caso - via sqlalchemy)
> 

Ti consiglio sqlalchemy, è quello che ho usato io.



Ciao  Manlio