[Python] Programmazione web

Lawrence Oluyede l.oluyede a gmail.com
Dom 27 Apr 2008 01:58:30 CEST


2008/4/26 Manlio Perillo <manlio_perillo a libero.it>:
>  > Hai elencato le altre motivazioni per cui HTTP Digest è un po' snobbato
>  >
>
>  Ma resta comunque utilizzabile.

Parzialmente usabile direi.

>  >>     E' possibile fare un login tramite form HTML usando Ajax, ma non
>  >>     tutti i browser lo supportano.
>  >
>  > Appunto, inoltre devi garantire un fallback
>  >
>
>  Ma, appunto si può farne a meno.

Non devi fare a meno di un fallback.

>  Con HTTP Digest hai a disposizione due campi, nonce ed opaque che puoi
>  gestire come stato lato client.
>
>  Basta gestirli al meglio per riuscire a gestire il logout (ovviamente il
>  client ti continua a mandare le credenziali, ma lato server puoi
>  verificare se è stato richiesto il logout ed agire di conseguenza -
>  questa tecnica non l'ho vista da nessun altra parte, quindi non sono
>  sicuro che non sia esente da problemi).

Non che l'approccio non sia interessante ma non puoi seriamente
pensare di mettere in produzione una cosa così sperimentale senza la
la sicurezza che una qualsiasi patch di un qualsiasi browser non ti
tolga il terreno da sotto i piedi. HTTP Digest è utile per
l'autenticazione ma così com'è non mi fiderei a dargli come incarico
il concetto di stato persistente. Per questo esistono i cookie, anche
se c'è chi li aborre. Io li uso solo per questo genere di
autenticazione

>  Mi riferivo al fatto che, ad esempio TextField nel Model indica *sia*
>  che il tipo di dato da usare nel database è di tipo testo, *sia* che il
>  controllo nel form è una textarea.

Ma anche no: http://www.djangoproject.com/documentation/newforms/#charfield


>  Mica puoi metterti ad indovinare se debba essere usato un <input
>  type="text"> o <textarea>, chiaramente questa è una informazione che
>  devi fornire *a parte*, e, a quanto ho capito - magari sbaglio - con
>  Django non è possibile.

Ti sbagli, i model sono una cosa, le form sono un'altra. Le classi son
separate e gestibili separatamente.

>  Ma effettivamente vedo che basta scrivere un newform e si risolve tutto.

Le newforms esistono da più di un anno eh, e le oldforms sono
deprecate da altrettanto tempo. Io nemmeno mi ricordo come si usavano
le oldforms :-)

>  Questo non toglie, comunque, che fino a qualche tempo fa c'era questo
>  limite (per non parlare della non gestione di Unicode).

Manlio, se vuoi giudicare un framework almeno fallo in base alle sue
feature attuali, non a quelle di una vita fa. È come quelli che
giudicano male MySQL pensando che sia fermo ancora alle 3.0 :D

Django è totalmente Unicode dal 4 luglio 2007:
http://code.djangoproject.com/changeset/5609




-- 
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


Maggiori informazioni sulla lista Python