Lawrence Oluyede ha scritto:
Oggi prima di cominciare ad implementare le feature effettive (vedi la
form per l'aggiunta dell'utente) ho provato a usare un po' il model e
mi sono accorto di varie mancanze e problemi che ho sistemato. Ecco,
senza ordine significativo:
- Tag l'ho rinominato in Skill
Ok.
- ora i model hanno i vari "class Meta", "class Admin", "__str__" con
fields vari se e quando servono (questi si possono cambiare con l'uso
dell'admin perché tanto non impattano sulla tabella SQL, che è quella
che deve essere scolpita nella roccia per ora dato che non abbiamo un
tool per le migrazioni)
Ok.
- l'utente può essere creato anche _senza_ la geo_location (se Google
è down l'utente va creato comunque)
Adesso è già così.
- l'avatar è diventato un ImageField, ma lascerei questa feature come
ultima cosa da implementare (anzi la lascerei proprio per una release
successiva, se no che diamo :-P ?)
Si, non è importante,
Inoltre:
- il model GeoLocation è stato sostanzialmente riscritto perché
- dipende da google.py e questo non va bene (get_location sarà
chiamata dalla view, non dal model)
Qui non ti seguo.
Come vengono inseriti i dati in questo model?
- longitudine e latitudine non vanno memorizzati in json nel DB,
sono interi, li memorizzo come interi
Si, così è meglio, anche se ci sono da fare dei calcoli in più in ogni
vista.
- di conseguenza google.py e views.py di "geo" sono stati leggermente
modificati ma andranno sistemati, ampliati ecc ecc secondo la doc di
google maps
- bisogna sistemare le view e progettare le URL perché cosi non vanno
Se non ci sono obiezioni io faccio il commit e comincio a progettare
l'accoppiamento view/url.
In allegato c'è il mega diff.
Io vorrei vedere meglio il codice perchè non mi convince.
Hai testato il tutto?
Saluti Manlio Perillo
_______________________________________________
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
