Respuesta larga: p
que he encontrado The Missing Manual posterior de gran valor para este tipo de problema, ya que explica muchas de las características de los perfiles de Django y sistemas de registro de Django.
me gustaría sugerir el uso de multi table inheritance en el único perfil que se permite establecer a través de la AUTH_PROFILE_MODULE
Por ejemplo
#models.py
class Profile(models.Model):
#add any common fields here (first_name, last_name and email come from User)
#perhaps add is_student or is_teacher properites here
@property
def is_student(self):
try:
self.student
return True
except Student.DoesNotExist:
return False
class Teacher(Profile):
#teacher fields
class Student(Profile):
#student fields
django-registro utiliza señales para notificarle de un registro. Debería crear el perfil en ese momento, por lo que está seguro de que las llamadas a user.get_profile() siempre devolverán un perfil. El código de señales utilizado es
#registration.signals.py
user_registered = Signal(providing_args=["user", "request"])
Lo que significa que al manipular la señal se tiene acceso a la solicitud realizada. Por lo tanto, cuando envíe el formulario de registro, incluya un campo que identifique qué tipo de usuario crear.
#signals.py (in your project)
user_registered.connect(create_profile)
def create_profile(sender, instance, request, **kwargs):
from myapp.models import Profile, Teacher, Student
try:
user_type = request.POST['usertype'].lower()
if user_type == "teacher": #user .lower for case insensitive comparison
Teacher(user = instance).save()
elif user_type == "student":
Student(user = instance).save()
else:
Profile(user = instance).save() #Default create - might want to raise error instead
except KeyError:
Profile(user = instance).save() #Default create just a profile
Si desea añadir nada al modelo que se crea, que no está cubierto por los valores predeterminados de campo, a la hora del registro se puede tirar, obviamente, que a partir de la solicitud.
tiene un tip o allí: P – jonasespelita