32 Acción Update Secretarias del sistema de reserva de citas medicas con LARAVEL(PHP-MySql) FullStack
Duración: 20 minDescripción
🔄 Lección 32: Acción de Actualización (Update) de Secretarias
Título del Video: 32 Acción Update Secretarias del sistema de reserva de citas medicas con LARAVEL (PHP-MySql) FullStack
Esta lección se enfoca en implementar las acciones de Edición (edit) y Actualización (update) para el módulo de Secretarias, un proceso que involucra la modificación de datos en dos tablas (users y secretarias) a través de un único formulario.
1. ⚙️ Configuración de Rutas y Función Edit
La acción edit tiene como objetivo mostrar el formulario prellenado con los datos de la secretaria seleccionada [01:44].
- Ruta Edit: Se define una ruta de tipo GET que espera el ID de la secretaria (/admin/secretarias/{id}/edit) y se mapea a la función edit del controlador [02:06].
- Función edit($id) en el Controlador:
2. 🖼️ Diseño del Formulario de Edición (edit.blade.php)
La vista de edición reutiliza la estructura del formulario de create, pero con dos diferencias clave:
- Prellenado de Datos: Se utiliza la sintaxis $secretaria->campo o $secretaria->user->email para cargar los valores actuales en cada campo del formulario [04:47].
- Campos de Contraseña: Los campos de contraseña no se prellenan. Además, se elimina la regla required de la vista, ya que la contraseña solo debe actualizarse si el usuario ingresa nuevos valores [06:44].
3. 💾 Lógica de la Función Update (Actualización en Múltiples Tablas)
La función update se encarga de recibir los datos del formulario y actualizarlos en las tablas users y secretarias.
🔑 Configuración de la Ruta y Método
- Ruta Update: Se define una ruta de tipo PUT que también espera el ID (/admin/secretarias/{id}) y se mapea a la función update del controlador [07:49].
- Formulario: El formulario de edición debe usar el método @method('PUT') para simular la petición PUT/PATCH [09:16].
🛡️ Validación Personalizada
La validación para la actualización es compleja porque debe permitir que los campos únicos (CI y Email) mantengan su valor actual sin disparar un error de unicidad.
- Búsqueda Inicial: Antes de validar, se busca la secretaria con el ID recibido [12:17].
- Regla de Unicidad para CI: Se valida que el campo ci sea único en la tabla secretarias, exceptuando el registro actual ($secretaria->id) [12:48].
- Regla de Unicidad para Email: Se valida que el campo email sea único en la tabla users, exceptuando el ID del usuario relacionado ($secretaria->user->id) [13:05].
🔄 Proceso de Actualización
- Actualización de Secretaria (secretarias):
- Se utiliza la instancia de $secretaria ya buscada [13:52].
- Se asignan los nuevos valores de campos (nombres, apellidos, CI, celular, fecha de nacimiento, dirección).
- Se guarda con $secretaria->save().
- Actualización de Usuario (users):
- Se busca el usuario relacionado a través del user_id de la secretaria [15:10].
- Se asignan los nuevos valores para name y email.
- Contraseña Condicional: Se implementa una validación para actualizar la contraseña solo si el campo password se envió en el request [15:43]. Si no se envía una nueva contraseña, la anterior permanece inalterada.
- Se guarda con $usuario->save().
Resultado: Una vez completado, el usuario es redirigido al listado con un mensaje de éxito: "Se actualizó a la secretaria de la manera correcta" [16:20].
Lecciones
Apoya este proyecto
Si te gusta nuestro contenido, ¡apóyanos con una donación!
Donar por Airtm Donar por Binance¡Gracias por tu apoyo! ❤️