Implementación de funcionalidades: Editar Empleado y Eliminar Empleado

Fecha: sábado 25 de abril de 2026

Hora de inicio: 9:30 a.m.

Hora de finalización: 5:38 p.m.

Horas trabajadas: 4 h 41 min

El plan para esta sesión era implementar las funcionalidades completas de editar y eliminar empleado. Fue la sesión más larga del proyecto hasta ahora, con bastante trabajo tanto en capa lógica como en presentación.

Actividades realizadas

9:30 a.m. – 10:35 a.m. — Función actualizar_empleado (modelo)

Empecé por la función en Python que conecta con el SP ActualizarEmpleado. La estructura es similar a las funciones que ya había hecho: abre la conexión, ejecuta el SP con cursor.execute, lee el resultset con el código de resultado y cierra la conexión en el finally.

Un detalle importante en esta función es el conn.commit() después del fetchone. Como ActualizarEmpleado hace un UPDATE dentro de una transacción, es necesario confirmar el cambio desde la capa Python también, de lo contrario la modificación no persiste en la base de datos. Esto ya lo había aprendido con funciones similares en la tarea 1.

10:35 a.m. – 11:58 a.m. — Vistas editar_empleado_view_get y editar_empleado_view_post (controlador)

Esta fue la primera vez que implementé una ruta con dos métodos HTTP distintos en Flask. GET para cargar el formulario prellenado con los datos actuales del empleado, y POST para procesar el formulario cuando el usuario guarda los cambios. Tuve que investigar cómo estructurar esto en Flask antes de escribir el código.

Lo que aprendí es que se pueden definir dos funciones separadas para la misma ruta, cada una con su propio decorador @route indicando el método correspondiente.

La vista GET hace tres cosas: valida la sesión, consulta los datos actuales del empleado (reutilizando consultar_empleado) para prellenar el formulario, y carga la lista de puestos para el dropdown.

La vista POST valida la sesión, obtiene los datos del formulario, aplica validaciones en capa lógica y llama a actualizar_empleado. Si el resultado es exitoso redirige al listado con un mensaje de confirmación; si no, redirige de vuelta al formulario con el mensaje de error correspondiente.

Al probar esta parte me encontré con el siguiente error:

werkzeug.routing.exceptions.BuildError: Could not build url for endpoint 'empleado.editar_empleado_view'

La causa era que en index.html el url_for referenciaba editar_empleado_view, pero las funciones del controlador se habían nombrado editar_empleado_view_get y editar_empleado_view_post. Lo corregí actualizando el url_for en index.html para usar el nombre correcto del endpoint GET.

1:00 p.m. – 1:53 p.m. — Diseño y creación de vista editar_empleado.html

Antes de programar el HTML, diseñé la vista en Figma siguiendo el diseño base que Johana había preparado para el proyecto. Eso me permitió tener claro qué componentes necesitaba antes de escribir el código.

Para el HTML tomé como base las vistas de Johana para mantener consistencia visual. La vista tiene un formulario con cuatro campos: nombre, identificación, puesto (dropdown) y saldo de vacaciones (solo lectura, no editable según el requerimiento). El dropdown de puestos se puebla con la lista que viene del controlador y marca como seleccionada la opción que corresponde al puesto actual del empleado.

Al probar noté que la validación del documento de identidad usaba isalpha(), lo que rechazaba documentos alfanuméricos válidos como 1673947992F. Lo corregí a isalnum() para aceptar letras, números o combinaciones.

Img1: Vista Editar Empleado finalizada.

1:53 p.m. – 1:58 p.m. — Configurar botón Actualizar en index.html

Ajuste rápido para conectar el botón "Actualizar" en el listado de empleados con la ruta correcta. Con esto la funcionalidad de editar quedó completamente integrada.

3:30 p.m. – 4:17 p.m. — Funciones registrar_intento_eliminar y eliminar_empleado (modelo y controlador)

Con el patrón ya claro de las funcionalidades anteriores, implementar eliminar fue más fluido. En el modelo escribí dos funciones separadas: registrar_intento_eliminar conecta con RegistrarIntentoEliminarEmpleado y solo registra en bitácora el momento en que el usuario ve la alerta de confirmación; eliminar_empleado conecta con EliminarEmpleado y hace el borrado lógico real.

En el controlador la lógica de eliminación tiene dos rutas: la vista GET (eliminar_empleado_view) que primero registra el intento en bitácora, luego consulta los datos del empleado y renderiza la pantalla de confirmación, y la vista POST (confirmar_eliminar_empleado_view) que ejecuta el borrado lógico real cuando el usuario confirma.

No hubo errores en esta parte, lo que atribuyo a que el patrón ya era familiar y reutilicé bastante estructura de las funcionalidades anteriores.

4:17 p.m. – 5:38 p.m. — Diseño y creación de vista eliminar_empleado.html + botón en index

Igual que con las vistas anteriores, primero diseñé en Figma y luego programé el HTML. La vista muestra los datos del empleado en modo lectura y un mensaje de confirmación.

El último commit del día fue ajustar el botón "Eliminar" en index.html para que redirigiera correctamente a la vista de confirmación. Con eso la funcionalidad quedó completamente integrada y probada.

Img2: Vista Eliminar Empleado finalizada.

Forma de trabajo del equipo

Nos mantuvimos en contacto por WhatsApp para consultas puntuales.

Referencias:

• Routes in Flask
• Combining Methods into Single Endpoints
• Tarea programada 1.