Lawrence Oluyede ha scritto:
Non mi riferivo al coding, ma a come organizzare la struttura delle
tabelle.
Ok ma anche questi dettagli possono venire fuori in fase di utilizzo.
Magari mentre clicchi e clacchi nell'html dici "cavoli ma sta roba a
che serve?" oppuer "perché non supporta questo?"
Mi rendo conto che dato il tipo di applicazione c'è poco da "decidere"
ma può essere un utile mind-setting
Ok.
Le icone di Python?
Cioè? 40 persone con la stessa icona è come 40 persona senza icona :D
Sempre meglio dei marcatori di default ;-).
Va anche deciso se, oltre al link alla pagine dei dettagli, inserire
solo l'username, il nome completo o del testo personalizzabile (ma non è
molto efficiente, diverso se potessimo usare SQLAlchemy).
Cioè? Non ho capito
Supponendo di usare SQLAlchemy, quello che si poteva fare era:
tabella: user -> classe User
tabella: profile -> classe Profile
La tabella profile definisce una backreference sulla tabella user
Se faccio una select sulla classe User, con l'eager loader attivato,
ottengo una lista di oggetti User, ciascuno dei quali ha un attributo
profile, che è un oggetto di tipo Profile.
A questo punto bastava fare:
info = user.profile.html_info()
Invece con Django si dovrebbe fare:
info = user.get_profile().html_info()
Ma in questo caso (a meno che io non stia dicendo sciocchezze) vengono
fattee N query al database.
Ovviamente, la soluzione banale è fare una select sulla tabella
profiles, invece che su users, ma non so se in questo modo è ancora
possibile fare in modo che il profilo sia un modulo "dinamico" e non
fisso (profilo per pythonisti, profilo per Linuxiani, etc).
Saluti Manlio Perillo
_______________________________________________
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
