Creación del sistema de cuentas
Definición del modelo Player
En Django, cada tabla de base de datos se representa mediante una clase Python. Dentro de la carpeta de modelos del proyecto, creamos un nuevo submódulo para la entidad Player. Este submódulo incluirá un archivo __init__.py y un archivo player.py.
El contenido del archivo player.py es el siguiente:
from django.db import models
from django.contrib.auth.models import User
class Player(models.Model):
user = models.OneToOneField(User, on_delete=models.CASCADE)
photo = models.URLField(max_length=256, blank=True)
def __str__(self):
return str(self.user)
Este modelo define una relación uno a uno con el modelo User de Django y un campo opcional para la URL de la foto de perfil.
Registor del modelo en el panel de administración
Para gestionar los registros Player desde la interfaz de administración, editamos el archivo admin.py de la aplicación correspondiente:
from django.contrib import admin
from game.models.player.player import Player
admin.site.register(Player)
Luego, ejecutamos las migraciones para aplicar los cambios a la base de datos:
python3 manage.py makemigrations
python3 manage.py migrate
Ahora, al acceder al panel de administración, encontrareoms el modelo Player disponible para su gestión.
Diferenciación entre cliente web y aplicación nativa
En el constructor principal del juego, añadimos un parámetro platform que permite distinguir el origen de la petición:
export class AcGame {
constructor(id, platform) {
this.id = id;
this.$container = $('#' + id);
this.platform = platform;
this.menu = new AcGameMenu(this);
this.playground = new AcGamePlayground(this);
this.initialize();
}
initialize() {
}
}
Cuando la aplicación se ejecuta desde un entorno nativo (AcWingOS), se pasa el parámetro platform. En cambio, desde la web solo se proporciona el identificador id.
Solicitudes del cliente al servidor
Para que el frontend obtenga información del backend, debemos implementar tres componentes: vistas (views), rutas (urls) y JavaScript. Al inicio, es recomendable usar únicamente peticiones GET para facilitar la depuración.
Implementación de las vistas
Creamos un archivo getinfo.py dentro de game/views/settings/:
from django.http import JsonResponse
from game.models.player.player import Player
def getinfo_acapp(request):
player = Player.objects.first()
return JsonResponse({
'result': 'success',
'username': player.user.username,
'photo': player.photo,
})
def getinfo_web(request):
player = Player.objects.first()
return JsonResponse({
'result': 'success',
'username': player.user.username,
'photo': player.photo,
})
def getinfo(request):
platform = request.GET.get('platform')
if platform == "ACAPP":
return getinfo_acapp(request)
else:
return getinfo_web(request)
Configuración de las rutas
Modificamos el archivo game/urls/settings/index.py:
from django.urls import path
from game.views.settings.getinfo import getinfo
urlpatterns = [
path("getinfo/", getinfo, name="settings_getinfo"),
]
Al acceder a la URL /settings/getinfo/, la función getinfo procesa la solicitud y devuelve un objeto JSON con los datos del usuario.
JavaScript del front end
En el archivo settings/zbase.js se maneja la lógica para renderizar la interfaz y realizar peticiones al servidor. Para las funcionalidades de inicio de sesión, registro y cierre de sesión, cada operación requiere su propio conjunto de vista, ruta y código JavaScript.
Para la interacción con los elementos del formulario, primero se identifican mediante selectores:
this.$loginPanel = this.$settings.find(".game-settings-login");
Luego, se asocian eventos a los botones para alternar entre la vista de inicio de sesión y la de registro, todo esto ejecutado en el lado del cliente.
Para la autenticación, el JavaScript envía una petición GET con las credenciales del usuario a la URL correspondiente. La vista del servidor valida los datos y devuelve una respuesta JSON. El cierre de sesión y el registro siguen el mismo patrón de tres capas: vista, ruta y JavaScript.