[Python] Programmazione web

[Manlio Perillo]

Lawrence Oluyede ha scritto:
> [...]
> 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
> 

Ma resta comunque utilizzabile.

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

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

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

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

Appunto questo è il problema.
Se lo fosse stato forse l'API sarebbe stata leggermente migliore.

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


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.

In generale questo non è un problema, e ti aiuta ad evitare di scrivere 
una 20-ina di caratteri di codice.


Ma metti ad esempio che io ho uno schema di un database già creato e che 
voglia crearmi il model Django.

Ignorando i limiti del model di Django (solo chiave primarie semplici) 
come credi dovrebbe essere gestito un campo SQL TEXT?

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.


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

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

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

Vedi sopra, colpa mia che ero rimasto ad un API vecchia.
Buono a sapersi.

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


Ottimo, quindi finalmente hanno risolto un altra delle cose che non mi 
piaceva.

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

Si, questo lo credo anche io.



Ciao  Manlio Perillo