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 _______________________________________________ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python