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 - 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) - l'utente può essere creato anche _senza_ la geo_location (se Google è down l'utente va creato comunque) - 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 ?) 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) - longitudine e latitudine non vanno memorizzati in json nel DB, sono interi, li memorizzo come interi - 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. -- Lawrence http://www.oluyede.org/blog http://www.neropercaso.it
megadiff.diff
Description: Binary data
_______________________________________________ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
