Capturar datos del usuario en una aplicación web con Yii empieza por entender cómo trabaja el controlador cuando recibe un formulario. Aquí verás cómo construir la acción que crea un usuario nuevo, recibe el post, valida y guarda, todo en pocas líneas. Es el primer paso de un flujo de tres etapas: controlador, active form y validación.
¿Qué hace el controlador cuando recibes user input en Yii?
El controlador es la pieza que decide qué pasa cuando alguien entra a una URL como miaplicacion.com/user/new. Su trabajo es preparar un sobre vacío para la vista, recibir lo que llega por post y orquestar la validación y el guardado.
En la práctica, creas un UserController partiendo de la misma estructura del BookController, pero apuntando a la carpeta de vistas de usuarios. Adentro defines una acción pública: public function actionNew(). Cada vez que alguien acceda a /user/new, esa acción se ejecuta.
¿Qué es una action en Yii? Es un método público dentro de un controlador que responde a una URL específica. Si se llama actionNew, se invoca al entrar a /controlador/new.
¿Por qué se crea un modelo vacío antes de mostrar el formulario?
El modelo es un contenedor de datos. Antes de que el usuario escriba nada, necesitas un sobre vacío que la vista pueda leer para saber qué campos pedir. Por eso, la acción arranca con $user = new User(); y ese objeto se manda al template como variable placeholder.
La vista lee el modelo, descubre que necesita username y password, y arma el formulario en consecuencia. Cuando el usuario lo envíe, ese mismo formulario regresará al actionNew por defecto, porque en Yii toda forma apunta como action al mismo controlador y acción que la generó.
¿Cómo detectar si el request trae datos del formulario?
A actionNew puedes llegar de dos formas: sin post, cuando alguien escribe la URL en el navegador, o con post, cuando ya hay un formulario lleno. Diferenciar ambos casos es clave.
La magia está en una sola línea: if ($user->load(Yii::$app->request->post())). Esto significa que el modelo intenta cargar datos del post que le correspondan. Si encuentra algo para él, devuelve verdadero y entras al bloque de procesamiento.
¿Qué hace load() en un modelo de Yii? Toma los datos del post que coinciden con los atributos del modelo y los asigna automáticamente. Si no hay nada relevante, devuelve falso.
¿Cuál es el flujo de validación y guardado?
Una vez que cargaste los datos, el flujo encadena dos verificaciones. Primero if ($user->validate()), que aplica las reglas de validación del modelo. Después if ($user->save()), que intenta persistir en la base de datos.
Los pasos quedan así:
- Cargar los datos del post en el modelo.
- Validar el contenido con las reglas definidas.
- Guardar en la base de datos si todo pasó.
- Manejar los errores cuando alguno de los pasos falla.
Estás trabajando con Active Record, pero el modelo puede guardar en otras entidades, como un archivo de texto. La lógica del controlador no cambia.
¿Cómo manejar errores y redireccionar tras guardar?
Si el modelo cargó y validó pero save() falla por una caída de base de datos o un error de SQL no contemplado, tiras una excepción: throw new \Exception('Error al salvar el usuario'). El throw corta la ejecución sin necesidad de un return explícito.
Cuando la validación falla, no hay return y el flujo cae al render final. Yii vuelve a mostrar el formulario con los datos que el usuario ya escribió y los mensajes de error en cada campo. Esa parte se conecta con la clase del active form.
Si todo salió bien, necesitas cortar la ejecución para que no se rerenderice el formulario. Ahí entra el patrón flash más redirect:
Yii::$app->session->setFlash('success', 'usuario guardado correctamente') para dejar un mensaje temporal.
return $this->redirect(['site/login']) para enviar al usuario al login después de crear su cuenta.
- El
render final solo se ejecuta cuando no hubo post o cuando la validación falló.
¿Qué queda dentro del render final?
La última línea de la acción es return $this->render('new.tpl', ['user' => $user]). Renderea el template new.tpl dentro de la carpeta de vistas de user y le pasa el modelo como variable.
Cuando es la primera visita, el modelo va vacío y la vista pinta un formulario limpio. Cuando hubo un intento fallido de validación, el modelo viaja con los datos que el usuario escribió y los errores asociados, así el formulario se repinta lleno y con feedback puntual.
En 15 líneas tienes una acción que recibe post, carga, valida, guarda, maneja excepciones, deja un flash message y redirige. La siguiente pieza es el formulario en la vista, donde verás cómo el active form convierte el modelo en HTML útil. ¿Cómo crees que cambiaría este flujo si en vez de crear un usuario estuvieras editando uno existente? Cuéntame en los comentarios.