Re: [Python] Programmazione web
2008/4/24 Enrico 'Henryx' Bianchi <[EMAIL PROTECTED]>: > - programmazione CGI; > - programmazione attraverso application server; > - programmazione tramite server pages; > - programmazione tramite framework. Di fatto, direi di no. Per esempio sconsiglierei abbastanza CGI. Per applicazioni semplici strutturalmente Django può essere una buona scelta/base di partenza. Oppure si Nevow+Twisted. Ma ovviamente per fare il deployment devi avere un host che lo supporta. -- -enrico ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Programmazione web
Il giorno 24/apr/08, alle ore 23:56, Enrico 'Henryx' Bianchi ha scritto: > Attualmente, volevo studiarmi Python in modo da applicarlo alla > programmazione web. Da quello che ho capito leggendo in giro, ho due > alternative: Hai un concetto molto personale di "due" ;-) > > - programmazione CGI; No, al massimo se vuoi restare a livello abbastanza basso, WSGI > - programmazione attraverso application server; Non so quanto ti convenga...dipende ovviamente dalle esigenze! > - programmazione tramite server pages; Per replicare PHP & company? L'unico uso che vedo per questo genere di cose è di aggiungere un minimo (veramente minimo) di dinamismo a un sito web essenzialmente statico. Ma se questa è l'esigenza, tantovale usare PHP, che è più diffuso tra gli hoster! > - programmazione tramite framework. Nel "caso medio" è la soluzione migliore. Ma esistono tante di quelle soluzioni che non è una scelta semplice! > Ora, visto che da quello che ho visto gli approcci possono essere > molteplici e tutti con i loro pro e contro, quale conviene utilizzare? Beh, come al solito la domanda non ha una risposta...devi sapere tu le tue esigenze, e cominciare a scegliere gli strumenti che meglio sodddisfano queste esigenze. Poi quando avrai limitato la scelta, scegli pure quello che ti piace di più! > Da quello che ho visto e capito l'approccio migliore e` utilizzando un > framework tipo Twisted o utilizzando WSGI, ma sinceramente sono > abbastanza confuso... > Twisted è un po' più a basso livello di altri tipo django, per cui più complesso da usare, ma ovviamente più flessibile. WSGI è ancora più a basso livello, non è pensabile usare direttamente WSGI, ma userai ocmunque un framework che si basa su WSGI. Il vantaggio (tutto teorico ad oggi, IMHO) è che puoi facilmente integrare applicazioni WSGI differenti. Nove volte su dieci, comunque, un web framework tipo django, pylons,ecc. è sufficiente per le tue esigenze. Se devi creare un server multiprotocollo che deve scalare ottimamente, twisted è la soluzione migliore in genere... Ciao > Enrico > > ___ > Python mailing list > Python@lists.python.it > http://lists.python.it/mailman/listinfo/python -- Antonio Valente ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Programmazione web
Y3s ha scritto: > [...] > WSGI è ancora > più a basso livello, non è pensabile usare direttamente WSGI, ma > userai ocmunque un framework che si basa su WSGI. Falso. WSGI è usabilissimo, continuando a restare a basso livello. Ovviamente hai bisogno di qualche funzione di "supporto", ma il punto è che IMHO non è necessario introdurre astrazioni ad alto livello (oggetti Request/Response, etc). > Il vantaggio (tutto > teorico ad oggi, IMHO) è che puoi facilmente integrare applicazioni > WSGI differenti. Appunto. Questo perchè, sempre IMHO, le implementazioni si "allontanano" da WSGI, usandolo solo come "dettaglio implementativo". > Nove volte su dieci, comunque, un web framework tipo django, > pylons,ecc. è sufficiente per le tue esigenze. Se devi creare un > server multiprotocollo che deve scalare ottimamente, twisted è la > soluzione migliore in genere... > Non è detto. Ci sono altre soluzioni asincrone che stanno uscendo (inclusa la mia implementazione di WSGI per Nginx). Ovviamente il *grosso* vantaggio di Twisted è che hai una ottima API per la programmazione concorrente e hai a disposizione decine di protocolli internet già implementati, per non parlare poi di Nevow Athena. > Ciao > >> Enrico >> Ciao Manlio Perillo ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Programmazione web
Enrico 'Henryx' Bianchi ha scritto: > Attualmente, volevo studiarmi Python in modo da applicarlo alla > programmazione web. Da quello che ho capito leggendo in giro, ho due > alternative: > > - programmazione CGI; > - programmazione attraverso application server; > - programmazione tramite server pages; > - programmazione tramite framework. > > Ora, visto che da quello che ho visto gli approcci possono essere > molteplici e tutti con i loro pro e contro, quale conviene utilizzare? > Da quello che ho visto e capito l'approccio migliore e` utilizzando un > framework tipo Twisted o utilizzando WSGI, ma sinceramente sono > abbastanza confuso... > Io ti consiglio di imparare ed usare WSGI direttamente per applicazioni semplici, ma di cominciare comunque a studiare da subito un web framework come Django. Le scelte comunque sono moltissime. Personalmente uso WSGI dietro Nginx (da me implementato) + SQLAlchemy (ma *non* l'ORM) + Mako. Sto anche sviluppando un mini framework per rendere più conveniente usare WSGI. Tra l'altro tratterò queste cose nel mio talk a Pycon Due. > Enrico > Manlio Perillo ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Programmazione web
Y3s ha scritto: > Il giorno 25/apr/08, alle ore 11:45, Manlio Perillo ha scritto: > >> Y3s ha scritto: >>> [...] >>> WSGI è ancora >>> più a basso livello, non è pensabile usare direttamente WSGI, ma >>> userai ocmunque un framework che si basa su WSGI. >> >> Falso. >> WSGI è usabilissimo, continuando a restare a basso livello. > > Usabile certamente, ma conveniente? > Si, lo sto usando e direi che conviene abbastanza ;-). Innanzitutto mantenersi a basso livello mi aiuta a ricordare che sto sviluppando una *applicazione web*, e ci sono sempre diverse cose che devo avere ben presenti e gestire io. Lo stesso motivo per cui ho deciso di non usare più gli ORM: è importante ricordarsi che si sta usando un database relazionale e ragionare in questi termini. Ovviamente se non si vuole usare un database relazionale è un altro discorso. >> Ovviamente hai bisogno di qualche funzione di "supporto", ma il >> punto è >> che IMHO non è necessario introdurre astrazioni ad alto livello >> (oggetti >> Request/Response, etc). > > Sicuramente non è necessario, ma penso sia abbastanza scomodo > sviluppare una vera applicazione solo con WSGI.. > Non solo WSGI. Ovviamente hai bisogno di alcune funzioni di supporto, gestione della configurazione, dispatching delle URL, autenticazione e forms. Io mi riferivo ad astrazioni sopra WSGI, come in webop: http://pythonpaste.org/webob/ Per non parlare poi di Django. > [...] > Se devi creare un >>> server multiprotocollo che deve scalare ottimamente, twisted è la >>> soluzione migliore in genere... >>> >> Non è detto. >> Ci sono altre soluzioni asincrone che stanno uscendo (inclusa la mia >> implementazione di WSGI per Nginx). >> >> Ovviamente il *grosso* vantaggio di Twisted è che hai una ottima >> API per >> la programmazione concorrente e hai a disposizione decine di >> protocolli >> internet già implementati, per non parlare poi di Nevow Athena. >> > > Appunto, per un "server multiprotocollo ad alta scalabilità" penso > che twisted sia ancora insuperato... > Ah, scusami, non avevo letto multiprotocollo ;-). > -- > Antonio Valente > Ciao Manlio Perillo ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Programmazione web
Il giorno 25/apr/08, alle ore 11:45, Manlio Perillo ha scritto: > Y3s ha scritto: >> [...] >> WSGI è ancora >> più a basso livello, non è pensabile usare direttamente WSGI, ma >> userai ocmunque un framework che si basa su WSGI. > > > Falso. > WSGI è usabilissimo, continuando a restare a basso livello. Usabile certamente, ma conveniente? > Ovviamente hai bisogno di qualche funzione di "supporto", ma il > punto è > che IMHO non è necessario introdurre astrazioni ad alto livello > (oggetti > Request/Response, etc). Sicuramente non è necessario, ma penso sia abbastanza scomodo sviluppare una vera applicazione solo con WSGI.. > >> Il vantaggio (tutto >> teorico ad oggi, IMHO) è che puoi facilmente integrare applicazioni >> WSGI differenti. > > Appunto. > Questo perchè, sempre IMHO, le implementazioni si "allontanano" da > WSGI, > usandolo solo come "dettaglio implementativo". Continuo a pensare che WSGI sia troppo a basso livello per essere comodo :-) > >> Nove volte su dieci, comunque, un web framework tipo django, >> pylons,ecc. è sufficiente per le tue esigenze. Se devi creare un >> server multiprotocollo che deve scalare ottimamente, twisted è la >> soluzione migliore in genere... >> > > Non è detto. > Ci sono altre soluzioni asincrone che stanno uscendo (inclusa la mia > implementazione di WSGI per Nginx). > > Ovviamente il *grosso* vantaggio di Twisted è che hai una ottima > API per > la programmazione concorrente e hai a disposizione decine di > protocolli > internet già implementati, per non parlare poi di Nevow Athena. > Appunto, per un "server multiprotocollo ad alta scalabilità" penso che twisted sia ancora insuperato... -- Antonio Valente ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Programmazione web
On Fri, Apr 25, 2008 at 11:45 AM, Manlio Perillo <[EMAIL PROTECTED]> wrote: > Ovviamente hai bisogno di qualche funzione di "supporto", ma il punto è > che IMHO non è necessario introdurre astrazioni ad alto livello (oggetti > Request/Response, etc). Io trovo comode astrazioni come WebOb sull'environ di wsgi. Tanto alla fine ti scriveresti utility simili. > Appunto. > Questo perchè, sempre IMHO, le implementazioni si "allontanano" da WSGI, > usandolo solo come "dettaglio implementativo". Secondo me è anche il modello a middleware agnostici che in teoria è perfetto e in pratica un po' meno. Questa specie di decorator pattern in cui però alcuni middleware non perfettamente scritti impattano sull'environ e rompono le uova nel paniere di altri middleware non mi piace molto. Tra l'altro framework come Pylons wrappano la tua applicazione con 3 o 4 middleware ogni volta, il che rende difficile qualsiasi tipo di debug cross-middleware (data la natura opaca del modello) -- Lawrence, stacktrace.it - oluyede.org - neropercaso.it "It is difficult to get a man to understand something when his salary depends on not understanding it" - Upton Sinclair ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Programmazione web
Lawrence Oluyede ha scritto:
> On Fri, Apr 25, 2008 at 11:45 AM, Manlio Perillo
> <[EMAIL PROTECTED]> wrote:
>> Ovviamente hai bisogno di qualche funzione di "supporto", ma il punto è
>> che IMHO non è necessario introdurre astrazioni ad alto livello (oggetti
>> Request/Response, etc).
>
> Io trovo comode astrazioni come WebOb sull'environ di wsgi. Tanto alla
> fine ti scriveresti utility simili.
>
No, non è affatto necessario.
Innanzitutto l'oggetto Request non serve, tanto lo "stato" della request
è tutto nel dizionario `environ`.
E lo stesso per l'oggetto Response, wsgiref contiene una classe Headers
per gestire gli headers, infatti io uso quella.
In Python abbiamo la fortuna di avere dizionari che possono contanere
qualsiasi oggetto, perchè mai dobbiamo introdurre una classe Request?
Avere oggetti di questo tipo mi sembra più che altro una necessità che
si ha nei linguaggi staticamente tipizzati, ma non di certo in Python.
Tanto per farti due esempi di come uso io WSGI:
def info(environ, start_response):
headers = [
('Content-Type', 'text/html; charset=utf-8'),
]
cookie = http.parse_cookie(environ)
template = environ['wsgix.lookup'].get_template('info.html')
ctx = {
'environ': environ,
'page_title': 'environ'
}
body = template.render(**ctx)
start_response(http.responses[http.OK], headers)
return [body]
def xxx(environ, start_response):
headers = Headers([])
obj = manager.get_obj(environ)
if not obj:
return http.not_found_response(
environ, start_response, headers)
model = model.model(environ)
action, values, errors = model.submit(environ)
if errors:
return http.bad_request_response(
environ, start_response, headers)
id = manager.create_some_object(
environ['app.engine'], environ, obj, **values)
u = util.application_uri(environ)
u = u + environ['app.base_url'] + 'xxx/' + id + '/'
return http.redirect_response(
environ, start_response, headers, u)
In pratica tutto gira attorno al dizionario environ e all'instanza della
classe Headers, e tutto è a livello abbastanza basso ma comunque
conveniente.
Tutto lo stato (incluso le opzioni, ad esempio caricate da un file di
configurazione tramite un middleware) sono nel `environ`.
Le funzioni per il parsing prendono tutti i dati (incluse le eventuali
opzioni) dall'`environ`, e se serve conservono dentro all'`environ` il
risultato del parsing, per il caching.
Almeno fino ad ora non sento nessuna necessità di mettere in mezzo
oggetti sopra il dizionario environ.
L'unica astrazione che sto usando è quella per gestire i forms (basata
sul modello di XForms).
>> Appunto.
>> Questo perchè, sempre IMHO, le implementazioni si "allontanano" da WSGI,
>> usandolo solo come "dettaglio implementativo".
>
> Secondo me è anche il modello a middleware agnostici che in teoria è
> perfetto e in pratica un po' meno.
> Questa specie di decorator pattern in cui però alcuni middleware non
> perfettamente scritti impattano sull'environ e rompono le uova nel
> paniere di altri middleware non mi piace molto.
Se un middleware non è ben scritto e "rompe" la tua applicazione, non lo
usi. Quale è il problema?
> Tra l'altro framework
> come Pylons wrappano la tua applicazione con 3 o 4 middleware ogni
> volta, il che rende difficile qualsiasi tipo di debug cross-middleware
> (data la natura opaca del modello)
>
Mi interessa questo aspetto, mi potresti dare maggiori informazioni?
Io fino ad ora non ho incontrato problemi, anzi con i middleware (ma
fino ad ora direi che ne sto usando solo di semplici) trovo che
l'applicazione si gestisca meglio.
Ciao Manlio Perillo
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
Re: [Python] Programmazione web
On Fri, Apr 25, 2008 at 3:09 PM, Manlio Perillo <[EMAIL PROTECTED]> wrote: > No, non è affatto necessario. Certo, ma io parlavo di comodità di API, per questo esistono le librerie e poi i framework. > E lo stesso per l'oggetto Response, wsgiref contiene una classe Headers > per gestire gli headers, infatti io uso quella. È quel che ho detto io. Alla fine finiresti con usare delle funzioni di utility, che siano scritte da te o meno :) > In Python abbiamo la fortuna di avere dizionari che possono contanere > qualsiasi oggetto, perchè mai dobbiamo introdurre una classe Request? Perché ciclare, iterare o interrogare un dizionario ha meno semantica che request.params o request.is_authenticated. Non sto sostenendo che sia utile o fondamentale usare astrazioni, solo che a volte è comodo. > Avere oggetti di questo tipo mi sembra più che altro una necessità che > si ha nei linguaggi staticamente tipizzati, ma non di certo in Python. Cosa c'entra la tipizzazione del linguaggio con un API? > Tutto lo stato (incluso le opzioni, ad esempio caricate da un file di > configurazione tramite un middleware) sono nel `environ`. Come in Pylons > Se un middleware non è ben scritto e "rompe" la tua applicazione, non lo > usi. Quale è il problema? Certo, e magarti di devi scrivere tu la funzionalità per la quale in un qualsiasi framework ben fatto (non faccio nomi... Django) ti basta importare una linea e scrivere un if > > Tra l'altro framework > > come Pylons wrappano la tua applicazione con 3 o 4 middleware ogni > > volta, il che rende difficile qualsiasi tipo di debug cross-middleware > > (data la natura opaca del modello) > > > > > Mi interessa questo aspetto, mi potresti dare maggiori informazioni? Crea una Pylons application, vai a guardare middleware.py o fai partire l'applicazione e fai "paster shell" esplorando l'oggetto app che ti viene fornito > Io fino ad ora non ho incontrato problemi, anzi con i middleware (ma > fino ad ora direi che ne sto usando solo di semplici) trovo che > l'applicazione si gestisca meglio. Io preferisco il modello Django, non ne faccio segreto con nessuno. Trovo che WSGI sia una gran cosa per sostituire CGI e per comunicare con un web server, un po' meno per il collage. Ma questa è la mia esperienza da settembre con Paste e Pylons, nulla più -- Lawrence, stacktrace.it - oluyede.org - neropercaso.it "It is difficult to get a man to understand something when his salary depends on not understanding it" - Upton Sinclair ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Programmazione web
Lawrence Oluyede ha scritto: > On Fri, Apr 25, 2008 at 3:09 PM, Manlio Perillo > <[EMAIL PROTECTED]> wrote: >> No, non è affatto necessario. > > Certo, ma io parlavo di comodità di API, per questo esistono le > librerie e poi i framework. > Anche io. >> E lo stesso per l'oggetto Response, wsgiref contiene una classe Headers >> per gestire gli headers, infatti io uso quella. > > È quel che ho detto io. Alla fine finiresti con usare delle funzioni > di utility, che siano scritte da te o meno :) > Si, ma appunto WSGI è nato per essere così; non è una libreria. Il mio dubbio riguarda come debbano essere scritte queste librerie di supporto. Se aumentare l'astrazione, oppure se cercare di restare a basso livello. >> In Python abbiamo la fortuna di avere dizionari che possono contanere >> qualsiasi oggetto, perchè mai dobbiamo introdurre una classe Request? > > Perché ciclare, iterare o interrogare un dizionario ha meno semantica > che request.params o request.is_authenticated. Boh, probabilmente sfugge qualcosa a me perchè non vedo grosse differenze in semantica tra: environ['is_authenticated'] e request.is_authenticated e non capisco perchè parli di ciclare ed iterare sul dizionario. > Non sto sostenendo che sia utile o fondamentale usare astrazioni, solo > che a volte è comodo. > >> Avere oggetti di questo tipo mi sembra più che altro una necessità che >> si ha nei linguaggi staticamente tipizzati, ma non di certo in Python. > > Cosa c'entra la tipizzazione del linguaggio con un API? > Perchè con i linguaggi a tipizzazione statica devi per forza introdurre una oggetto aggiuntivo per gestire lo stato della request. >> Tutto lo stato (incluso le opzioni, ad esempio caricate da un file di >> configurazione tramite un middleware) sono nel `environ`. > > Come in Pylons > Ah, non lo sapevo. >> Se un middleware non è ben scritto e "rompe" la tua applicazione, non lo >> usi. Quale è il problema? > > Certo, e magarti di devi scrivere tu la funzionalità per la quale in > un qualsiasi framework ben fatto (non faccio nomi... Django) ti basta > importare una linea e scrivere un if > Mi faresti un esempio pratico? In effetti a tutt'oggi non sono ancora riuscito a vedere un esempio (con commenti) di middleware scritto male. E' davvero così difficile sistemare questi middleware? >> > Tra l'altro framework >> > come Pylons wrappano la tua applicazione con 3 o 4 middleware ogni >> > volta, il che rende difficile qualsiasi tipo di debug cross-middleware >> > (data la natura opaca del modello) >> > >> >> >> Mi interessa questo aspetto, mi potresti dare maggiori informazioni? > > Crea una Pylons application, vai a guardare middleware.py o fai > partire l'applicazione e fai "paster shell" esplorando l'oggetto app > che ti viene fornito > >> Io fino ad ora non ho incontrato problemi, anzi con i middleware (ma >> fino ad ora direi che ne sto usando solo di semplici) trovo che >> l'applicazione si gestisca meglio. > > Io preferisco il modello Django, non ne faccio segreto con nessuno. Anche a me piace Diango, anche se certe cose sono fatte effettivamente male (ma vabbe, non si può sperare di fare tutto bene). > Trovo che WSGI sia una gran cosa per sostituire CGI e per comunicare > con un web server, un po' meno per il collage. Ma infatti WSGI è nato per comunicare con il web server ;-). > Ma questa è la mia > esperienza da settembre con Paste e Pylons, nulla più > Le cose sono tre: 1) WSGI 1.0 è stato scritto male 2) WSGI 1.0 è troppo difficile da usare bene 3) Paste e Pylons sono scritti male Manlio Perillo ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Programmazione web
2008/4/25 Manlio Perillo <[EMAIL PROTECTED]>: > Il mio dubbio riguarda come debbano essere scritte queste librerie di > supporto. A me gli oggetti Request e Response piacciono :) > Boh, probabilmente sfugge qualcosa a me perchè non vedo grosse > differenze in semantica tra: > > environ['is_authenticated'] e > request.is_authenticated Certo che no > e non capisco perchè parli di ciclare ed iterare sul dizionario. Mi è capitato più volte di ruminare nell'environment per capire dove Pylons infilasse le cose o di patchare middleware di Paste andando a naso :D > Perchè con i linguaggi a tipizzazione statica devi per forza introdurre > una oggetto aggiuntivo per gestire lo stato della request. Continuo a non seguirti. Io parlo di astrazione, API e semantica. Tu parli di tipizzazione statica. Mi sa che non siamo sulla stessa linea d'onda > Mi faresti un esempio pratico? > In effetti a tutt'oggi non sono ancora riuscito a vedere un esempio (con > commenti) di middleware scritto male. paste.auth.auth_tkt :D > E' davvero così difficile sistemare questi middleware? Monkey patching :D > Anche a me piace Diango, anche se certe cose sono fatte effettivamente > male (ma vabbe, non si può sperare di fare tutto bene). Certo. > Ma infatti WSGI è nato per comunicare con il web server ;-). E allora perché usarlo per fare framework come i lego? Vedi quell'aberrazione di TG > Le cose sono tre: > 1) WSGI 1.0 è stato scritto male Non saprei > 2) WSGI 1.0 è troppo difficile da usare bene Direi che questo in parte è vero > 3) Paste e Pylons sono scritti male Sul secondo direi di sì. -- Lawrence, stacktrace.it - oluyede.org - neropercaso.it "It is difficult to get a man to understand something when his salary depends on not understanding it" - Upton Sinclair ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Programmazione web
Lawrence Oluyede ha scritto: > 2008/4/25 Manlio Perillo <[EMAIL PROTECTED]>: > [...] >> e non capisco perchè parli di ciclare ed iterare sul dizionario. > > Mi è capitato più volte di ruminare nell'environment per capire dove > Pylons infilasse le cose o di patchare middleware di Paste andando a > naso :D > Ah, capisco. Ma questo probabilmente significa che c'è un problema nella documentazione. Se i valori nel dizionario sono messi con criterio probabilmente si evitano questi problemi. >> Perchè con i linguaggi a tipizzazione statica devi per forza introdurre >> una oggetto aggiuntivo per gestire lo stato della request. > > Continuo a non seguirti. Io parlo di astrazione, API e semantica. Tu > parli di tipizzazione statica. Mi sa che non siamo sulla stessa linea > d'onda > Sembra di si ;-). Ok, direi di lasciar perdere. > >> Mi faresti un esempio pratico? >> In effetti a tutt'oggi non sono ancora riuscito a vedere un esempio (con >> commenti) di middleware scritto male. > > paste.auth.auth_tkt :D > A parte il problema con l'inizializzazione del middleware (personalmente non mi piace l'approccio di Paste) quale è il problema con questo middleware? Non ti piace quello che fa, o il come lo fa? Personalmente la funzionalità che offre non mi piace per niente, ma se lo usi significa che è quello che vuoi, no? >> E' davvero così difficile sistemare questi middleware? > > Monkey patching :D > Si, ma non è che mi sia molto chiaro cosa devi farci con quel middleware e come lo usi. >> Anche a me piace Diango, anche se certe cose sono fatte effettivamente >> male (ma vabbe, non si può sperare di fare tutto bene). > > Certo. > >> Ma infatti WSGI è nato per comunicare con il web server ;-). > > E allora perché usarlo per fare framework come i lego? Perchè è l'unico modo per far interoperare parti diverse. Per cooperare, tutti i pezzi del lego devono usare la stessa interfaccia. Vedi Django, ad esempio: vive in un mondo a se. Un middleware scritto per Django funziona solo con Django (e di solito non è un problema). > Vedi > quell'aberrazione di TG > Sto vedendo TG ora, ma secondo me tu fai un pò di confusione tra WSGI e un framework che lo usa. Mi sembra come dire che Python è un pessimo linguaggio perchè ho visto il programma xxx scritto da cani. A questo punto ho dei dubbi su cosa tu intenda con "fare framework come i lego". Per me fare un framework come i lego significa sviluppare le funzionalità del framework come middleware WSGI riutilizzabili, e possibilmente in modo che il tutto funzioni anche se un dato middleware non è presente. > [...] Ciao Manlio Perillo ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Programmazione web
Manlio Perillo ha scritto: > Lawrence Oluyede ha scritto: > [...] >>> Mi faresti un esempio pratico? >>> In effetti a tutt'oggi non sono ancora riuscito a vedere un esempio (con >>> commenti) di middleware scritto male. >> paste.auth.auth_tkt :D >> > > A parte il problema con l'inizializzazione del middleware (personalmente > non mi piace l'approccio di Paste) quale è il problema con questo > middleware? > Rivedendo meglio in effetti il middleware è scritto male, dato che non dovrebbe mettere nell'environ qualcosa come environ['paste.auth_tkt.set_user'](userid, tokens='', user_data='') http://dirtsimple.org/2007/02/wsgi-middleware-considered-harmful.html > [...] Ciao Manlio Perillo ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Programmazione web
2008/4/25 Manlio Perillo <[EMAIL PROTECTED]>: > Personalmente la funzionalità che offre non mi piace per niente, ma se > lo usi significa che è quello che vuoi, no? Sì ma è scritto male e ho dovuto patcharlo. > Si, ma non è che mi sia molto chiaro cosa devi farci con quel middleware > e come lo usi. Serve per autenticare gli utenti > Perchè è l'unico modo per far interoperare parti diverse. > Per cooperare, tutti i pezzi del lego devono usare la stessa interfaccia. Certo > Vedi Django, ad esempio: vive in un mondo a se. > Un middleware scritto per Django funziona solo con Django > (e di solito non è un problema). Ma a me questa cosa va benissimo! Non ho nessun problema con il "lockin" in un framework di successo :-). Non critico Django/Rails/twisted.web/Spring/Plone/XYZ perché il codice scritto per loro funziona solo con loro eh :D > Sto vedendo TG ora, ma secondo me tu fai un pò di confusione tra WSGI e > un framework che lo usa. No, dico solo che allo stato attuale non ho ancora visto grandi motivazioni all'atto pratico per preferire WSGI ad un framework qualsiasi che non lo usa. Tanto praticamente tutti i framework Python possono essere usati con tool come modwsgi (e immagino anche il tuo per nginx) > Mi sembra come dire che Python è un pessimo linguaggio perchè ho visto > il programma xxx scritto da cani. No certo, infatti dico sempre che WSGI è una buona idea ma che all'atto pratico ha dei limiti > Per me fare un framework come i lego significa sviluppare le > funzionalità del framework come middleware WSGI riutilizzabili, e > possibilmente in modo che il tutto funzioni anche se un dato middleware > non è presente. Eh eh se fosse davvero così allora sì. Ma nella mia esperienza non sempre è così. -- Lawrence, stacktrace.it - oluyede.org - neropercaso.it "It is difficult to get a man to understand something when his salary depends on not understanding it" - Upton Sinclair ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Programmazione web
Lawrence Oluyede ha scritto: > 2008/4/25 Manlio Perillo <[EMAIL PROTECTED]>: >> Personalmente la funzionalità che offre non mi piace per niente, ma se >> lo usi significa che è quello che vuoi, no? > > Sì ma è scritto male e ho dovuto patcharlo. > >> Si, ma non è che mi sia molto chiaro cosa devi farci con quel middleware >> e come lo usi. > > Serve per autenticare gli utenti > Si, ma nel modo sbagliato direi :). > [...] >> Sto vedendo TG ora, ma secondo me tu fai un pò di confusione tra WSGI e >> un framework che lo usa. > > No, dico solo che allo stato attuale non ho ancora visto grandi > motivazioni all'atto pratico per preferire WSGI ad un framework > qualsiasi che non lo usa. Si, questo è vero. Ma ad esempio alcune delle cose che non mi piacciono di Django probabilmente sarebbero state sviluppate meglio se avessere costruito il tutto sopra WSGI fin dall'inizio e nel modo corretto. > [...] >> Per me fare un framework come i lego significa sviluppare le >> funzionalità del framework come middleware WSGI riutilizzabili, e >> possibilmente in modo che il tutto funzioni anche se un dato middleware >> non è presente. > > Eh eh se fosse davvero così allora sì. Ma nella mia esperienza non > sempre è così. > Purtroppo è così, ed in questo caso resta sempre il dubbio se la colpa è di chi progetta una cosa oppure di chi la utilizza (male). Ciao Manlio Perillo ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Programmazione web
2008/4/25 Manlio Perillo <[EMAIL PROTECTED]>: > Si, ma nel modo sbagliato direi :). A parte il baco nell'implementazione, a cosa ti riferisci? > Ma ad esempio alcune delle cose che non mi piacciono di Django > probabilmente sarebbero state sviluppate meglio se avessere costruito il > tutto sopra WSGI fin dall'inizio e nel modo corretto. Esempio? -- Lawrence, stacktrace.it - oluyede.org - neropercaso.it "It is difficult to get a man to understand something when his salary depends on not understanding it" - Upton Sinclair ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Programmazione web
Lawrence Oluyede ha scritto: > 2008/4/25 Manlio Perillo <[EMAIL PROTECTED]>: >> Si, ma nel modo sbagliato direi :). > > A parte il baco nell'implementazione, a cosa ti riferisci? > 1) E' un abuso dei cookie, che non sono stati pensati per fare questo 2) Va anche bene rafforzare la sicurezza controllando l'IP del client, ma così non puoi supportare utenti Fastweb o che usano un proxy. 3) Tutto quello che fa mod_auth_tkt lo fa HTTP Digest, e molto meglio. Peccato per le implementazioni nei browsers correnti non ottimali, ma comunque si può usare, l'unico aspetto negativo è che gli utenti si devono loggare usando la finestra di dialogo del browser (e Safari ha anche un fastidioso bug che ne riduce ancora di più l'usabilità). E' possibile fare un login tramite form HTML usando Ajax, ma non tutti i browser lo supportano. Il logout invece lo si fa senza troppi problemi. >> Ma ad esempio alcune delle cose che non mi piacciono di Django >> probabilmente sarebbero state sviluppate meglio se avessere costruito il >> tutto sopra WSGI fin dall'inizio e nel modo corretto. > > Esempio? > Una su tutte: quasi tutto lo stato è mantenuto in variabili globali ed è strettamente legato al resto del framework. Questo significa che devi fare i salti mortali se ad esempio vuoi usare il sistema di templating di Django in altre applicazioni; infine significa anche che non puoi far girare due applicazioni nello stesso interprete. Un'altra cosa che non mi piace è l'idea "don't repeat youself" portata agli estremi, in cui "mischi" insieme concetti che magari è meglio tenere separati. Ad esempio nella definizione del modello mischi un pò di tutto: in un solo colpo per ciascun dato definisci sia il tipo di dato, sia il tipo di controller (ossia come il dato deve essere gestito nel form). Per non parlare poi delle "istruzioni" per l'interfaccia di admin, che IMHO non dovrebbero proprio stare dentro il modello. Ok, tutto questo ti fa scrivere meno codice, ma limita anche quello che puoi fare; francamente preferisco scrivere un pò di codice in più. Non commento l'ORM, perchè non è strettamente necessario usarlo; ho visto comunque applicazioni che usano l'ORM come fosse su un database in memoria e non in un database relazionale, magari su un server separato. Ciao Manlio Perillo ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Programmazione web
On Fri, Apr 25, 2008 at 11:47 PM, Manlio Perillo
<[EMAIL PROTECTED]> wrote:
> 1) E' un abuso dei cookie, che non sono stati pensati per fare questo
Sì conosco il problema ma se ad esempio hai bisogno del concetto di
logout (che implica uno stato) non te la cavi molto facilmente.
> 2) Va anche bene rafforzare la sicurezza controllando l'IP del client,
> ma così non puoi supportare utenti Fastweb o che usano un proxy.
Puoi dirgli di ignorare la gestione dell'IP
> 3) Tutto quello che fa mod_auth_tkt lo fa HTTP Digest, e molto meglio.
Vero, ma uno dei motivi per cui si introduce un cookie per
l'autenticazione è anche per fare logout.
> Peccato per le implementazioni nei browsers correnti non ottimali,
> ma comunque si può usare, l'unico aspetto negativo è che
> gli utenti si devono loggare usando la finestra di dialogo del
> browser (e Safari ha anche un fastidioso bug che ne riduce ancora
> di più l'usabilità).
Hai elencato le altre motivazioni per cui HTTP Digest è un po' snobbato
> E' possibile fare un login tramite form HTML usando Ajax, ma non
> tutti i browser lo supportano.
Appunto, inoltre devi garantire un fallback
> Il logout invece lo si fa senza troppi problemi.
Tipo? Se ti riferisci all'usare dei trick con JS e Ajax beh, siamo
daccapo sulla questione del fallback.
> Una su tutte: quasi tutto lo stato è mantenuto in variabili globali ed è
> strettamente legato al resto del framework.
Eh eh non mi pare. In Pylons sì che è così "in quasi tutto". Persino
gli oggetti request e response sono globali ad un modulo
> Questo significa che devi fare i salti mortali se ad esempio vuoi usare
> il sistema di templating di Django in altre applicazioni;
Non mi pare che Django sia stato pensato per essere usato da altre
parti. Puoi usare un altro sistema di templating in Django. La sua
forza sta nel non obbligarti ad usare qualsiasi cosa, non nell'essere
totalmente scomponibile (tra l'altro è parzialmente vero perché parti
di Django, come l'ORM si posson usare al di fuori. Idem la parte di
routing delle URL
> infine significa anche che non puoi far girare due applicazioni nello
> stesso interprete.
Questo è un problema del 99% dei framework eh
> Un'altra cosa che non mi piace è l'idea "don't repeat youself" portata
> agli estremi, in cui "mischi" insieme concetti che magari è meglio
> tenere separati.
Quì non siamo d'accordo, a me sembra, almeno a livello di API che sia
uno dei più puliti
> Ad esempio nella definizione del modello mischi un pò di tutto: in un
> solo colpo per ciascun dato definisci sia il tipo di dato, sia il tipo
> di controller (ossia come il dato deve essere gestito nel form).
Non ti seguo. Io non ho mai mischiato form e model. Se ti riferisci a
form_from_model, beh è uno shortcut che può essere utile quando ci sia
una corrispondenza tra come le informazioni sono rappresentate e
memorizzate. Ma il fatto che sia una funzione a sé stante ci fa
decisamente capire che i due siano indipendenti
> Per non parlare poi delle "istruzioni" per l'interfaccia di admin, che
> IMHO non dovrebbero proprio stare dentro il modello.
Concordo, infatti son state tolte nella branch newforms-admin che
finirà nel trunk. Es:
class Book(models.Model):
title = models.CharField(max_length=100)
author = models.ForeignKey(Author)
class BookOptions(admin.ModelAdmin):
list_display = ('title', 'author')
ordering = ('title',)
admin.site.register(Book, BookOptions)
Un model e una classe che gestice l'admin, se ti serve.
> Ok, tutto questo ti fa scrivere meno codice, ma limita anche quello che
> puoi fare; francamente preferisco scrivere un pò di codice in più.
> Non commento l'ORM, perchè non è strettamente necessario usarlo;
> ho visto comunque applicazioni che usano l'ORM come fosse su un database
> in memoria e non in un database relazionale, magari su un server separato.
Io le uniche limitazioni che ho trovato nella mia breve Django-vita
erano proprio nell'ORM. Il resto mi piace e con le dovute limature
Django non farà altro che crescere.
--
Lawrence, stacktrace.it - oluyede.org - neropercaso.it
"It is difficult to get a man to understand
something when his salary depends on not
understanding it" - Upton Sinclair
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
