Feature: Excepciones para respuestas de error en criterios

[GonzaloFernandez20]

• Se agregaron excepciones para devolver al front un mensaje especifico en el caso de que uno de los criterios devuelva un false. De paso se modificaron los tests del validador para que pasen con los nuevos cambios.

• Tambien se agrego un metodo para que se chequee con la BD si un nombre de usuario ya esta en el sistema, cosa de que no hayan dos usuarios con el mismo nombre. (Igualmente se va a hacer mas adelante cuando ya tengamos toda la parte de BD lista, porque entiendo que es hacer un chequeo con la propia BD nomas)

• TODO: En el front deberiamos mostrar el error como un warning debajo del campo "Contrasenia", Que opinan? Me resulta extranio que al usuario se le muestre una alerta directamente.

• Foto:

[GonzaloFernandez20]

Para lo de la BD hasta ahora había entendido que íbamos a usar los repositorios como conexión con la BD. (No entendí si quieren hacer la conexión desde el controlador).

• Sisi totalmente, coincidimos en que los repositorios son la conexión con la BD, en alguno de los archivos la idea es tener un método que permita verificar si un username ya está registrado en el repositorio de usuarios, el controlador solo llamaría a este método cuando está validando que tanto usuario como contraseña sean validos al momento del registro de un nuevo usuario.

Les adjunto una imagen de cómo lo resolví (visualmente, el código está en Main).

• Banco, me parece bien como está planteado el visual, banco que hagamos así los warnings. Pueden/Quieren encargarse?

Estuve probando las pantallas y no me funcionaron InicioDeSesion y Registro. Al mandar el formulario, la consola del front me tiró el error "InicioDeSesion.js:83 Uncaught TypeError: Cannot read properties of null (reading 'addEventListener')". No sé si les pasó a ustedes también o todavía no miraron esas cosas, pero les aviso por las dudas que miren si hay algún error que se genere por el front.

• en Main creo q está bien que no funcione porque todavía no mergeamos la rama donde están los controladores. Ahora si en esa rama no están funcionando, hay algo raro, la última vez que lo probe estaba funcionando (Hoy a la mañana)

También, vi que estuvieron usando json y eso también lo hice distinto, más que nada para evitar tener que modificar el js utilicé las herramientas que da Spring Boot para recibir los parámetros. No creo que sea una diferencia mayor, podríamos dejar las dos maneras mientras usemos el Cliente Liviano, pero lo dejo por escrito para que después no se generen problemas. Me gustaría saber qué piensan todos al respecto.

• Usamos el formato Json más que nada para poder delegar lógica de instanciar, recordamos que nos dijeron que los controladores como tal no instancian, por ej en cosas como una heladera o un colaborador deberían llamar a un factory o builder y tener toda la lógica de instanciar concentrada ahí, pero si son pocos parámetros los que se reciben y su uso es conciso creo que no habría problema en usar los RequestParams que da springboot.

[sofiacachero]

Banco, me parece bien como está planteado el visual, banco que hagamos así los warnings. Pueden/Quieren encargarse?

Como ustedes usaron ResponseEntity para devolver una respuesta al front y yo no, realmente no sé cómo hacer para que aparezca el mensaje en su caso sin cambiarlo. Sí les puedo decir cómo lo hice.

En lugar de que el método Post devuelva un ResponseEntity usé String, además de que recibe el objeto Model. En este caso, lo que hice es agregar el atributo "mensaje" al objeto Model (model.addAttribute("mensaje", "Mensaje que deseen enviar al front")) y como valor de retorno el nombre de la pantalla (en todos mis casos coincidía también con el método Get) en la que quieren que aparezca el mensaje. En esa pantalla pueden poner el siguiente bloque donde quieran que aparezca el mensaje:

<div th:if="${mensaje}" class="alert" th:classappend="${mensaje.contains('Error') ? 'alert-danger' : 'alert-success'}"><p th:text="${mensaje}"></p></div>

El bloque, como podrán notar, sólo va a aparecer si existe un atributo "mensaje" al momento en que se renderiza la pantalla. También, va a aparecer en rojo si es un error (debe contener 'Error'), caso contrario en verde.

Si quieren que cuando se renderice la pantalla aparezcan algunos datos traídos del back, el retorno conviene que sea el mismo método que utilizaron para el Get, sólo que esta vez el modelo va a llevar el atributo "mensaje".

Les dejo por las dudas un muy breve tutorial en el que utilizaron Model y una página en la que encontré varios métodos que pueden serle aplicados, si quieren ver otros ejemplos: https://www.baeldung.com/spring-mvc-model-model-map-model-view https://www.geeksforgeeks.org/spring-mvc-model-interface/

en Main creo q está bien que no funcione porque todavía no mergeamos la rama donde están los controladores. Ahora si en esa rama no están funcionando, hay algo raro, la última vez que lo probe estaba funcionando (Hoy a la mañana)

No, lo probé en Features-Validador y luego en Ctrl-InicioDeSesion... Puse System.out.println("un mensaje") en el método Post de Iniciar Sesión y nunca llegó a la consola (después de haber enviado el formulario, por las dudas), además de que la pantalla se quedó donde estaba sin ningún mensaje. El único que hizo algo fue la Validación en Registro.