[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