[Python] Programmazione web

[Lawrence Oluyede]

On Fri, Apr 25, 2008 at 11:47 PM, Manlio Perillo
<manlio_perillo a libero.it> 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