Códice | Entradas sobre «thymeleaft»

Notificaciones con Thymeleaft

JavGuerra — Wed, 03 Jul 2024 00:00:00 GMT

Etiquetas: #código, #java, #spring boot, #bootstrap, #thymeleaft

Cuando una aplicación realiza operaciones potencialmente críticas como editar, guardar o borrar datos de una base de datos, es conveniente notificar al usuario el éxito o fracaso de las operaciones. Esta entrada presenta una solución básica de cómo mostrar notificaciones en la plantilla Thymeleaft.

Se asume que el lector tiene conocimientos generales de Spring Boot, Thymeleaft y Bootstrap para aplicar el contenido.

Planteamiento

La idea es destinar una área de la visualización en la aplicación para las notificaciones, y activar este área sólo cuando se deban mostrar, dando opción al usuario a cerrarlas una vez leídas. Este área puede crearse como un fragmento (th:fragment) e incluirse en las plantillas en las que se requiera, o en todas las plantillas asociadas a las vistas de la aplicación.

Será necesaria una variable que sirva de «llave» para mostrar estas notificaciones o no, y otra para indicar el tipo de mensaje (info, danger…). Como enviar el mensaje desde cada método de erutado de nuestros controladores es algo trabajoso, lo adecuado es usar un filtro de sesión http que me permitirá crear las variables donde guardaré el contenido del mensaje y el tipo de mensaje a mostrar.

Por último, gestionaré el borrado del contenido de la notificación para que esta deje de mostrarse al cambiar de página Para ello necesitaremos otra variable que indique si la notificación ya se ha mostrado.

Programando notificaciones

Para crear las notificaciones, necesitaremos:

Crear un fragmento que servirá para incluir el texto de la notificación en nuestras vistas.
Inicializar las variables de sesión que contendrán la notificación y el tipo de notificación.
Actualizar el valor de las variables de notificación para que estas se muestren.
Eliminar la notificación al cambiar de página.

El fragmento

He creado un fragmento de código llamado messageAlert.html que he incluido en mi carpeta fragments dentro de templates en resources. Este es un ejemplo que puede modificarse a voluntad para adaptar su diseño a la aplicación donde se usará.

<div th:fragment="messageAlert" th:if="${session.message != ''}" class="container">

    <div class="alert alert-dismissible fade show" role="alert"
        th:classappend="${session.messageType} == 'danger'? 'alert-danger' : 'alert-info'">

        <svg xmlns="http://www.w3.org/2000/svg" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" width="24" height="24">
            <path stroke-linecap="round" stroke-linejoin="round" d="M14.857 17.082a23.848 23.848 0 0 0 5.454-1.31A8.967 8.967 0 0 1 18 9.75V9A6 6 0 0 0 6 9v.75a8.967 8.967 0 0 1-2.312 6.022c1.733.64 3.56 1.085 5.455 1.31m5.714 0a24.255 24.255 0 0 1-5.714 0m5.714 0a3 3 0 1 1-5.714 0M3.124 7.5A8.969 8.969 0 0 1 5.292 3m13.416 0a8.969 8.969 0 0 1 2.168 4.5" />
        </svg>&nbsp;&nbsp;

        <span class="align-middle" th:text="${session.message}"></span>

        <button class="btn-close" data-bs-dismiss="alert" aria-label="Cerrar"></button>
    </div>
</div>

Con th:if="${session.message != ''}"determino si este fragmento se mostrará o no. Si el valor de la variable de sesión llamada message está vacío, es que no hay nada que mostrar, de otra forma, el fragmento se mostrará.

Con th:classappend="${session.messageType} == 'danger'? 'alert-danger' : 'alert-info'" determino qué tipo de alerta de Boostrap mostrar, si una destinada a informar (recuadro con fondo azul) o una destinada a alertar de un fallo (recuadro con fondo rojo). Esto lo consigo mediante la variable de sesión messageType.

Tras el icono SVG que se mostrará en el aviso, se incluye el mensaje de la notificación con th:text="${session.message}" dentro de la etiqueta span.

Con el button, ayudado por Bootstrap, el usuario puede cerrar la notificación.

Para incluir este fragmento en la vista donde deseo que se muestre la notificación, uso:

<div th:replace="~{fragments/messageAlert :: messageAlert}"></div>

Inicializando las variables message y messageType

Como he comentado, voy a usar variables de sesión http para guardar el contenido del mensaje y el tipo de mensaje. Para ello creo un filtro de sesión que compruebe, por cada petición http, si existe una sesión y si las variables de sesión están creadas.

He incluido el siguiente componente en /Utils/SessionFilter.java:

@Component
public class SessionFilter implements Filter {

    @Override
    public void init(FilterConfig filterConfig) throws ServletException {}

    @Override
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
            throws IOException, ServletException {

        HttpServletRequest httpRequest = (HttpServletRequest) request;
        HttpServletResponse httpResponse = (HttpServletResponse) response;

        HttpSession session = httpRequest.getSession(true);

        if (session!= null) {

            // Variables para las notificaciones

            if (session.getAttribute("message") == null)
                session.setAttribute("message", "");

            if (session.getAttribute("messageType") == null)
                session.setAttribute("messageType", ""); 
                // Valores: "danger" u otro cualquiera = "info".

        }

        chain.doFilter(request, response);
    }

    @Override
    public void destroy() {}
}

Con HttpSession session = httpRequest.getSession(true); Obtengo la sesión, y si no existe, se creará una nueva. Esto ocurre porque he incluido el valor true en .getSession(true).

Si existe la sesión (que, salvo error, ya debería existir), compruebo que las variables message y messageType estén inicializadas, y si no lo están las inicializo a "".

Tras esto, ya podremos usar session.getAttribute() y session.setAttribute() para leer y para actualizar el valor de las variables de sesión desde nuestros servicios o controladores, como veremos.

Usando mensajes

Pensemos en un servicio que guarde el contenido de un formulario para crear un cine. Sería algo similar a esto:

@Slf4j
@RequiredArgsConstructor
@Service
public class CinemaServiceImpl implements ICinemaService {

    private final CinemaRepository cinemaRepo;

    // Otras propiedades y métodos de la clase aquí

    @Override
    @Transactional
    public Cinema save(Cinema cinema) {
        log.info("save {}", cinema);

        try {
            return cinemaRepo.save(cinema);

        } catch (Exception e) {
            log.error("Error al guardar el cine: ", e);

            return null;
        }
    }
}

Como se ve, la clase CinemaServiceImpl implementa la interfaz ICinemaService, inyecta el repositorio CinemaRepository y tiene un método que guarda un cine. cinema es enviado al método save desde el controlador que lo usa, y el método devuelve el cine guardado o null si se produjo un error.

A continuación muestro cómo se verá el método al incluir los mensajes de éxito o error:

@Slf4j
@RequiredArgsConstructor
@Service
public class CinemaServiceImpl implements ICinemaService {

    private final HttpSession session;
    private final CinemaRepository cinemaRepo;

    // Otras propiedades y métodos de la clase aquí

    @Override
    @Transactional
    public Cinema save(Cinema cinema) {
        log.info("save {}", cinema);

        try {
            Cinema newCinema = cinemaRepo.save(cinema);

            String message = "Cine " + newCinema + " guardado.";

            session.setAttribute("message", message);
            session.setAttribute("messageType", "info");

            return newCinema;

        } catch (Exception e) {
            log.error("Error al guardar el cine: ", e);

            session.setAttribute("message", "El cine no ha podido guardarse.");
            session.setAttribute("messageType", "danger");

            return null;
        }
    }
}

Con session.setAttribute("message", message); se cambia el valor de la variable message, y con session.setAttribute("messageType", "info"); se hace lo propio con la variable messageType. Lo mismo ocurre en caso de error.

A tener en cuenta: en String message = "Cine " + newCinema + " guardado correctamente."; hay que estar seguro de que la entidad Cinema sobrescribe (@Override) el método toString() para poder usarlo como String.

El resultado es algo como lo que se muestra a continuación.

Lo que se ve es lo que hemos definido en el fragmento messageAlert.html que hemos incluido en la plantilla de la vista.

Mensajes encadenados

Si realizamos más de una gestión crítica desde un mismo controlador, como, por ejemplo, actualizar la información de un cine, y si este no está está operativo (p.ej. si ha cerrado temporalmente), entonces desactivar todas las salas de ese cine para que no se muestren en la aplicación, podemos encadenar los mensajes de ambos servicios. Para ello debemos leer el valor de la variable message en el segundo servicio, el que se ocupe de desactivar las salas, y añadir el aviso al nuevo mensaje, ya que sólo disponemos de un mensaje que puede ser mostrado a la vez:

String message = (String) session.getAttribute("message");
session.setAttribute("message", message + " Salas desactivadas correctamente.");

Cerrando la notificación al cambiar de página

Como sabemos, la notificación puede cerrarse haciendo clic en la X de cierre, o bien cerrarse cuando cambiamos de página. Al cambiar de página, el filtro SessionFilter se ejecutará, y para que ocurra lo que queremos es necesario incluir una nueva variable y mas comprobaciones, como se muestra a continuación:

@Component
public class SessionFilter implements Filter {

    @Override
    public void init(FilterConfig filterConfig) throws ServletException {}

    @Override
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
            throws IOException, ServletException {

        HttpServletRequest httpRequest = (HttpServletRequest) request;
        HttpServletResponse httpResponse = (HttpServletResponse) response;

        HttpSession session = httpRequest.getSession(true);

        if (session!= null) {

            // Variables para las notificaciones

            if (session.getAttribute("message") == null)
                session.setAttribute("message", "");

            if (session.getAttribute("messageType") == null)
                session.setAttribute("messageType", ""); 
                // Valores: "danger" u otro cualquiera = "info".

            // Cierre de notificaciones al cambiar de página

            if (session.getAttribute("messageActivated") == null)
                session.setAttribute("messageActivated", false);

            if ((boolean) session.getAttribute("messageActivated")) {
                session.setAttribute("message", "");
                session.setAttribute("messageActivated", false);
            }

            if (!Objects.equals((String) session.getAttribute("message"), ""))
                session.setAttribute("messageActivated", true);
            
        }

        chain.doFilter(request, response);
    }

    @Override
    public void destroy() {}
}

En estos tres nuevos bloques de sentencias if , primero compruebo que la variable de sesión messageActivated está inicializada, como hacía con las otras variables de sesión, y si no lo está, la inicializo a false.

Como cada vez que se muestra una página en la aplicación se lanza SessionFilter, en el siguiente bloque de sentencias compruebo si messageActivated está activado (true), y si lo está, la desactivo, y vacío message para que no vuelva a mostrarse la notificación. Recordemos que el fragment messageAlert.html sólo muestra la notificación si su contenido no es "".

En el último bloque, si message contiene texto y es la primera vez que se va a mostrar la notificación, el bloque anterior no la habrá borrado. Entonces activo messageActivated para que la notificación pueda ser eliminada la siguiente vez que se muestre una página.

Como se aprecia, messageActivated actúa como indicador de borrado, y en este proceso es determinante el orden en el que se hacen las comprobaciones.

Con esto, ya tenemos activo nuestro propio sistema de notificaciones para Thymeleaft.

Adaptando este método sería posible, por ejemplo, generar notificaciones que permitan consultar al usuario si quiere llevar a cabo o no una tarea determinada, como p.ej. "¿Desea borrar el cine? [Sí] [No]".

BONUS: Aviso de cookies

Es fácil realizar los cambios para, por ejemplo, notificar un aviso de cookies con un botón de aceptar que permanezca abierto hasta que el usuario lo cierre, o incluso poner un banner, o cualquier aviso temporal que requiera nuestra aplicación. Hagamos el proceso de ejemplo de un aviso de cookies.

El planteamiento cambia un poco. Si vamos a emplear ambos métodos, el de notificar lo que ocurre en la aplicación y el aviso de cookies, debemos usar una variable propia que actúe de «llave» para la cookie.

La notificación estará disponible en la vista actual y en todas aquellas vistas que tengan el fragmento de código de la cookie incluido en la plantilla hasta que se lo indiquemos. Como no podemos eliminar el contenido de la notificación desde Thymeleaft, y no sabemos el momento en el que el usuario eliminará la ventana de notificación, la variable de sesión que guarda la notificación se manejará desde el backend, mediante un controlador y una ruta que nos permita cambiar su valor.

El filtro

Comienzo añadiendo la nueva variable cookieWarning de sesión al filtro:

@Component
public class SessionFilter implements Filter {

    @Override
    public void init(FilterConfig filterConfig) throws ServletException {}

    @Override
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
            throws IOException, ServletException {

        HttpServletRequest httpRequest = (HttpServletRequest) request;
        HttpServletResponse httpResponse = (HttpServletResponse) response;

        HttpSession session = httpRequest.getSession(true);

        if (session!= null) {

            // Variables para las notificaciones

            if (session.getAttribute("message") == null)
                session.setAttribute("message", "");

            if (session.getAttribute("messageType") == null)
                session.setAttribute("messageType", ""); 
                // Valores: "danger" u otro cualquiera = "info".

            // Cierre de notificaciones al cambiar de página

            if (session.getAttribute("messageActivated") == null)
                session.setAttribute("messageActivated", false);

            if ((boolean) session.getAttribute("messageActivated")) {
                session.setAttribute("message", "");
                session.setAttribute("messageActivated", false);
            }

            if (!Objects.equals((String) session.getAttribute("message"), ""))
                session.setAttribute("messageActivated", true);

            // Gestión de la cookie

            if (session.getAttribute("cookieWarning") == null)
                session.setAttribute("cookieWarning", true);

        }

        chain.doFilter(request, response);
    }

    @Override
    public void destroy() {}
}

En este caso, la variable tendrá valor true por defecto, lo que indica que el fragmento de aviso de cookies debe mostrarse. Cuando la cerremos, este valor cambiará a false.

El fragmento

Podemos llamar al fragmento que mostrará la notificación cookieWarnig.html, e incluirlo en todas nuestras páginas mediante:

<div th:replace="~{fragments/cookieWarning :: cookieWarning}"></div>

Este es su código:

<div th:fragment="cookieWarning" th:if="${session.cookieWarning}" class="container mt-3 sticky-top">

    <form th:action="@{/cookie}" method="POST">

        <input type="hidden" th:name="returnUrl" th:value="${returnUrl}">

        <div class="alert alert-warning alert-dismissible fade show shadow d-flex justify-content-between" role="alert">

            <svg xmlns="http://www.w3.org/2000/svg" fill="none" viewBox="0 0 24 24" stroke-width="1.5" stroke="currentColor" width="24" height="24">
                <path stroke-linecap="round" stroke-linejoin="round" d="M10.34 15.84c-.688-.06-1.386-.09-2.09-.09H7.5a4.5 4.5 0 1 1 0-9h.75c.704 0 1.402-.03 2.09-.09m0 9.18c.253.962.584 1.892.985 2.783.247.55.06 1.21-.463 1.511l-.657.38c-.551.318-1.26.117-1.527-.461a20.845 20.845 0 0 1-1.44-4.282m3.102.069a18.03 18.03 0 0 1-.59-4.59c0-1.586.205-3.124.59-4.59m0 9.18a23.848 23.848 0 0 1 8.835 2.535M10.34 6.66a23.847 23.847 0 0 0 8.835-2.535m0 0A23.74 23.74 0 0 0 18.795 3m.38 1.125a23.91 23.91 0 0 1 1.014 5.395m-1.014 8.855c-.118.38-.245.754-.38 1.125m.38-1.125a23.91 23.91 0 0 0 1.014-5.395m0-3.46c.495.413.811 1.035.811 1.73 0 .695-.316 1.317-.811 1.73m0-3.46a24.347 24.347 0 0 1 0 3.46" />
            </svg>&nbsp;&nbsp;
            
            <span class="align-middle"><strong>Atención:</strong> Este sitio usa cookies. Lea la Política de privacidad.</span>

            <button type="submit" class="btn btn-sm btn-outline-primary" data-bs-dismiss="alert" aria-label="Confirmar">OK</button>
        </div>
    </form>
</div>

Nuestra notificación de cookie se verá así:

La comprobación th:if="${session.cookieWarning}" hará que se muestre o no este fragmento, osea, que se muestre o no la notificación de cookies.

Como se aprecia, se incluye un formulario que actuará cuando el usuario cierre la notificación. Con el botón button type="submit", mediante el formulario, llamo al controlador que va a desactivar la notificación de cookie a través la ruta indicada en el formulario: <form th:action="@{/cookie}" method="POST">.

Con <input type="hidden" th:name="returnUrl" th:value="${returnUrl}"> indico, a través de la respuesta de formulario al controlador, a qué página debo dirigirme después de realizar la operación, pues, como dije, no sabemos en qué momento el usuario cerrará la notificación. Esto me permitirá volver a la página donde estaba una vez se procese el cambio del valor de la variable de sesión de la cookie.

Suelo usar de forma genérica returnUrl para indicar la ruta porque es útil para, por ejemplo, cuando llamo a un formulario y quiero saber dónde debo ir una vez enviado el contenido del formulario, como en este caso. Por ejemplo, si nuestra aplicación maneja cines, y añadimos, editamos o borramos un cine, mediante returnUrl puedo indicar al método @PostMapping qué vista mostrar tras realizar estas operaciones. Para poder hacerlo, cuando usé las vistas de crear, editar o borrar mencionadas, añado esta variable al modelo con:

model.addAttribute("returnUrl", "cinemas");

donde cinemas es la ruta a la que se debe llegar una vez el formulario de la ruta a la que vamos se procese. El método se vería así:

@GetMapping("/create")
public String createForm(Model model) {

    model.addAttribute("cinema", new Cinema());
    
    model.addAttribute("returnUrl", "cinemas");

    return "cinema/cinema-form";
}

En la carpeta controllers, creo el controlador CookieController siguiente:

@Controller
public class CookieController {

    @PostMapping("/cookie")
    public String closeCookiePolicy(HttpSession session,
        @RequestParam(value = "returnUrl", required = false) String returnUrl) {

        session.setAttribute("cookieWarning", false);

        if (!stringIsEmpty(returnUrl)) {
            return "redirect:" + returnUrl;
        } else {
            return "redirect:/";
        }
    }
}

Así, a través de la ruta /cookie puedo cambiar el valor de cookieWarning con: session.setAttribute("cookieWarning", false); y luego volver a la ruta deseada si hemos pasado el parámetro returnUrl. Ahora la notificación ya no se mostrará más.

Es importante que la ruta /cookie esté definida en nuestra configuración de seguridad. Si estamos usando Spring Security, en SecurityConfig.class debe haber algo como esto:

@Bean
public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
    http
        .authorizeHttpRequests(authRequest -> authRequest

            // otras configuraciones

            .requestMatchers(HttpMethod.POST, "/cookie").permitAll()

            // otras configuraciones

            .anyRequest().authenticated()
        )

        // otras configuraciones

        return http.build();
}

Con .requestMatchers(HttpMethod.POST, "/cookie").permitAll() la ruta /cookie es ahora visible y ya podemos usarla desde el fragmento para cerrar nuestra notificación.

Un ejemplo

Puedes ver el código que implementan estos métodos, tanto las notificaciones como los mensajes fijos de cookies, en el repositorio de la aplicación Cartelera DAW.

Repositorio de Cartelera DAW

Spinner loader en Thymeleaft

JavGuerra — Mon, 08 Jul 2024 00:00:00 GMT

Etiquetas: #código, #java, #spring boot, #thymeleaft

A veces, el tiempo de respuesta del servidor es alto, y el usuario puede sentir que la aplicación web no está funcionando bien. Aquí explico cómo usar un spinner loader o animación de carga propia, generada con CSS, que se active al cargar la página y permanezca activa hasta que se muestre completamente.

Esta entrada hace uso y adapta los contenidos ya explicados anteriormente en este blog en Spinner loader asíncrono, pero en este caso se simplifica el proceso al plantear una solución que no se basa en eventos asíncronos.

Manos a la obra

Lo que voy a hacer es mostrar el cargador cada vez que entramos en una página, y hasta que esta se carga completamente. Usaré JavaScript para activarlo y desactivarlo.

Necesitaré un espacio donde mostrar la animación de carga y el CSS que defina esta animación.

El fragmento

Para incluir el código necesario en nuestras vistas con Thymeleaft, creo un fragmento que llamo spinner.html como este:

<div th:fragment="spinner">
    <dialog id="zone">
        <div class="spinner" aria-label="Cargando..."></div>
    </dialog>

    <script>
        const zone = document.querySelector('#zone');

        // Activa la ventana modal
        let domContentLoadedCallback = function() {
            zone.showModal();
            document.removeEventListener('DOMContentLoaded', domContentLoadedCallback);
        };

        // Desactiva la ventana modal
        let loadCallback = function() {
            zone.close();
            window.removeEventListener('load', loadCallback);
        };

        document.addEventListener('DOMContentLoaded', domContentLoadedCallback);
        window.addEventListener('load', loadCallback);
    </script>
</div>

Puedo incluir este fragmento en cualquier parte de la plantilla Thymeleaft con:

<div th:replace="~{fragments/spinner :: spinner}"></div>

Realmente no importa en qué parte de la plantilla incluyamos el fragmento, pues va a hacer uso de dialog, una etiqueta HTML que define una ventana modal que se muestra en el centro exacto de la ventana del navegador.

<dialog id="zone"><div class="spinner" aria-label="Cargando..."></div></dialog>

Este simple código define una ventana modal identificada como zone y un div que servirá para mostrar el cargador definido a través de la clase spinner.

Mediante el código JavaScript posterior, selecciono la ventana modal zone sobre la que voy a actuar, y luego defino dos eventos, el primero hará que se muestre el cargador y el segundo que se desactive.

El primer evento se dispara cuando el HTML se ha cargado completamente (DOMContentLoaded), y el segundo cuando todos los contenidos referenciados en la página son cargados (load). Entre el primer y el segundo evento, el cargador es visible.

Con zone.showModal(); se activa la ventana modal, y con zone.close(); se desactiva. En realidad, el cargador está ahí en todo momento, pero no está visible en todo momento.

Dentro de cada función que gestiona el evento he incluido también el código para quitar el evento una vez usado.

El CSS

Con el siguiente código:

#zone {
  border: none;
  background: none;
}

#zone:focus {
  outline: none;
}

.spinner {
  margin: 0 auto;
  border: 5px solid moccasin;
  width: 36px;
  height: 36px;
  border-radius: 50%;
  border-left-color: DarkOrange;

  animation: spin 1s ease infinite;
}

@keyframes spin {
  0% { transform: rotate(0deg); }
  100% { transform: rotate(360deg); }
}

No debemos olvidar incluir algo como:

<link rel="stylesheet" href="/css/estilo.css">

en el head de las plantillas donde vayamos a usar el cargador, cambiando estilo.css y su ruta según corresponda.

El modal identificado como #zone se verá sin fondo y sin borde, osea, totalmente transparente. En él es donde se muestra el cargador. #zone tendrá el tamaño del cargador, y aparecerá centrado tanto vertical como horizontalmente en la pantalla, manteniéndose centrado aún haciendo scroll.

Con .spinner describo el aspecto del spinner loader, e indico que debe animarse infinitamente girando 360 grados cada segundo.

Realmente se trata de colorear el borde a un div, poner un color distinto al borde de uno de sus lados, redondear sus esquinas para que el div parezca un círculo y luego hacerlo girar constantemente. Simple y efectivo.

Y no necesitamos nada más. Ahora, cada vez que se cargue una página, veremos el cargador durante el tiempo que tarda en cargarse completamente.

No se recomienda abusar del cargador, ya que este puede centrar la atención del usuario, por lo que usado con moderación, en las páginas que son susceptibles de retrasar su carga, añadimos un efecto interesante y útil a nuestra aplicación y damos información al usuario de lo que ocurre.

Uso en formularios

Cuando enviamos un formulario o hacemos una petición que el backend va a tardar en procesar, también podemos activar la visualización del cargador hasta que cambie la vista. Para ello podemos añadir un evento a nuestro formulario de la siguiente manera:

<form id="myForm" th:action="@{/setCity}" method="POST">
    
    ...

    <button id="send" type="submit">Guardar</button>
</form>

<script>
    document.getElementById('send').addEventListener('click', function(event) {
        event.preventDefault();
        zone.showModal();
        document.getElementById('myForm').submit();
    });
</script>

Una vez identificados el formulario myForm y el botón de enviar send, mediante JavaScript asocio un evento que permitirá que, al hacer click en el botón de guardar, se active la ventana modal.

Con event.preventDefault(); capturo el evento de envío del formulario para poder intercalar la activación de la ventana modal con zone.showModal(); antes de enviar el formulario definitivamente con document.getElementById('myForm').submit();.

Es necesario que el fragmento spinner.html se haya incluido en la página. De otra forma podemos incluir el código del cargador ya mencionado en cualquier parte de nuestra página:

<dialog id="zone"><div class="spinner" aria-label="Cargando..."></div></dialog>

Como ya sabemos que vamos a cambiar de vista al enviar el formulario, no es necesario desactivar el evento click del formulario, pero si estamos haciendo comprobaciones el en frontend, es posible que necesitemos hacerlo cunado mostremos errores, lo que implica código de comprobaciones adicional. Si estamos usando @Valid en nuestro backend, esto no será necesario.

Un ejemplo

Puedes ver el código que implementa esta solución en el repositorio de la aplicación Cartelera DAW.

Enlaces recomendados

Info sobre la etiqueta <dialog>.
Artículo «Cómo crear un spinner loader con CSS»

Cartelera DAW

JavGuerra — Thu, 20 Jun 2024 00:00:00 GMT

Etiquetas: #portfolio, #web, #java, #spring boot, #bootstrap, #thymeleaft, #spring security, #accesibilidad, #responsive

Recientemente he presentado mi proyecto fin de estudios de Formación Profesional de Grado Superior DAW. Era algo que llevaba aparcado durante demasiado tiempo y finalmente esta etapa se ha cerrado.

El proyecto ha consistido en una aplicación web monolítica, desarrollada en Java, usando el framework Spring Boot, y ha sido desplegada en el servicio de Railway.com.

El proyecto

El proyecto Cartelera DAW desarrolla una plataforma web para mostrar información cinematográfica cuyos usuarios potenciales son los espectadores y las distribuidoras de películas, cines y salas de proyección.

La plataforma, que está basada en Java y Spring Boot, utiliza un patrón Modelo-Vista-Controlador y una arquitectura cliente-servidor, haciendo uso del IDE IntelliJ IDEA, de Maven para la gestión del proyecto, de Git y GitHub para el versionado de código, de MySQL e Hibernate para la gestión de la base de datos y de una configuración LAMP dockerizada para las pruebas. Para el despliegue se utilizaron tecnologías como Docker y metodologías CI/CD. Para el frontend se ha empleado el gestor de plantillas Tymeleaft y Bootstrap.

Adicionalmente se proponen una serie de estrategias comerciales para garantizar la sostenibilidad del modelo empresarial del proyecto.

Se elaboró una memoria de 70 páginas y una presentación.

El objetivo era aprender y usar tecnologías nuevas no estudiadas en DAW.

La calificación final ha sido de 9 de 10, y se ha llevado a cabo en un periodo de tres semanas.

La formación previa

Pero el proyecto no partía de cero. Durante los meses de enero y febrero, y hasta el 9 de marzo de 2023, participé en un curso de especialización en Java + Spring de la Fundación Adecco dentro del Proyecto Digital School Erasmus+

Se trataba de una formación mentorizada que incluía un trabajo en grupo para desarrollar una aplicación web. En mi grupo de trabajo me encargué de la coordinación del equipo mediante Trello y de la planificación de las funcionalidades de la aplicación y las propuesta de mejora de la app. El grupo se llamaba Cinéfilos, y Cartelera DAW bebe de la estructura simple de aquella práctica que me sirvió para entender cómo funciona el framework.

El proyecto ahora presentado ha cambiado mucho desde aquella versión, tanto en su estructura como en su diseño. Partía de un código inconcluso donde sólo se habían implementado los CRUDs básicos, con fallos de integridad y sin funcionalidades mínimas, pero ahora la aplicación ha sido probada y revisada en profundidad, y cuenta con características que refuerzan sus funcionalidades.

En el curso, así como en la práctica, obtuve una calificación de 10/10.

Características

Además de los requisitos solicitados para el MVP, en la app se ha implementado:

Seguridad de rutas
Registros de usuario
Validaciones de formularios
Automatizaciones
Documentación con JavaDoc
Implementación de Logs
Notificaciones
Despliegue dockerizado

Cuenta con:

Portada dinámica
Diseño responsive
Diseño accesible
Aviso legal y privacidad
Aviso de cookies
Ayuda en línea
Spinner loader

Desarrollo y despliegue

Tanto en el desarrollo como en el despliegue ha jugado un papel importante Docker.

La BBDD MySQL y PHPMyAdmin han sido lanzados usando contenedores gestionados con la herramienta Portainer.

El despliegue se lleva a cabo tomando el código fuente y, mediante un dockerfile, construyendo la imagen del contenedor que es lanzado en el servidor.

Spring Boot contiene un servidor Tomcat encargado de servir las páginas de la aplicación.

Indicaciones de instalación

Tras clonar el repositorio, es necesario crear un usuario en la BBDD relacional llamado «cartelera-daw» con el password que deseemos. Estos datos, así como el puerto por defecto de la app (8082), pueden ser introducidos en el fichero «aplication.propieties», en la carpeta resources.

Cada vez que se inicia la aplicación, esta recarga los datos en la BBDD.

Una vez iniciada la aplicación en local, se puede acceder a ella en la dirección: http://localhost:8082

El acceso al panel de administración requiere de usuario y contraseña. Por defecto, la aplicación tiene un usuario «admin» y su contraseña es «admin».

ADVERTENCIA: Se recomienda que, tras el primer acceso, la contraseña de admin sea cambiada o se cree una nueva cuenta de usuario desde la que eliminar la cuenta «admin».

Licencia

Sobre el código fuente: GNU GENERAL PUBLIC LICENSE Version 3

Enlaces

Recursos TIC

JavGuerra — Wed, 11 Dec 2024 00:00:00 GMT

Etiquetas: #portfolio, #web, #java, #spring boot, #bootstrap, #thymeleaft, #spring security, #accesibilidad, #responsive, #selenium, #api, #swagger, #javadoc, #junit, #mockito, #docker, #jacoco, #github actions, #ci-cd, #sonarqube

Recientemente he cursado una formación con Adecco, y este es mi proyecto fin de estudios, que ha consistido en desarrollar una aplicación que permita gestionar recursos TIC y listas de recursos, para realizar los tests correspondientes, aplicando los conocimientos aprendidos, y que ha sido desplegada en el servicio de Railway.com.

El proyecto

La plataforma, que está basada en Java y Spring Boot, utiliza un patrón Modelo-Vista-Controlador y una arquitectura cliente-servidor, haciendo uso del IDE IntelliJ IDEA, de Maven para la gestión del proyecto, de Git y GitHub para el versionado de código, de MySQL, H2 y el ORM Hibernate para la gestión de la base de datos y de una configuración LAMP dockerizada para las pruebas.

Para el frontend se ha empleado el gestor de plantillas Tymeleaft y Bootstrap.

Para los tests se ha usado JUnit, Mockito, Selenium. la API se ha probado con Swagger y las estadísticas se han generado con JaCoCo y SonarQube.

Para el despliegue se utilizaron tecnologías como Docker y metodologías CI/CD con GitHub Actions.

La planificación y codificación se han llevado a cabo usando Trello.

Destacados

Además de los requisitos del MVP, se han incluido las siguientes funcionalidades:

Diseño responsive, “mobile first”
Web accesible AA. Testada con WAVE
Seguridad por diseño
Confirmaciones de borrado
Implementación de login de usuarios
Integra el editor TinyMCE
Provee API REST e interfaz Swagger
Incluye aviso legal, privacidad y cookies
Documentación la aplicación con JavaDoc
Usa el protocolo OpenGraph para RR.SS.
Manifest para móviles (PWA)
Desarrollada con Linux + Docker LAMP
Despliegue

Video

El proyecto fue presentado a empresas de tecnología, y se puede ver en el vídeo de la presentación del proyecto aquí:

Indicaciones de uso

Requisitos

Para ejecutar el proyecto se requiere:

Java 23 o superior
Maven
MySQL
Docker

Configuración

Actualmente la aplicación se ejecuta localmente en el puerto 8082.

Puede construirse un contenedor Docker con la imagen de la aplicación ejecutando el fichero docker.sh que hace uso de docker-compose para lanzar la aplicación y la BBDD que requiere.

Para generar un informe de cobertura de testing, se puede ejecutar el comando mvn site y acceder a él en el directorio target/site/jacoco/index.html.

Códice | Entradas sobre «thymeleaft»

Notificaciones con Thymeleaft

Planteamiento

Programando notificaciones

El fragmento

Inicializando las variables message y messageType

Usando mensajes

Mensajes encadenados

Cerrando la notificación al cambiar de página

BONUS: Aviso de cookies

El filtro

El fragmento

Cerrando la notificación de cookie

Un ejemplo

Spinner loader en Thymeleaft

Manos a la obra

El fragmento

El CSS

Uso en formularios

Un ejemplo

Enlaces recomendados

Cartelera DAW

El proyecto

La formación previa

Características

Desarrollo y despliegue

Indicaciones de instalación

Licencia

Enlaces

Recursos TIC

El proyecto

Destacados

Video

Indicaciones de uso

Requisitos

Configuración

Autores

Licencia

Enlaces