Haga que sus aplicaciones Qodly sean dinámicas e interactivas con estados

Los estados juegan un papel crucial en la creación de interfaces dinámicas y reactivas en 4D Qodly Pro. Le permiten controlar la visualización y el comportamiento de los widgets basándose en condiciones específicas, como el rol de un usuario, sus privilegios o los datos de su base de datos.

Este blog explora este concepto, presenta los diferentes tipos de estados, e ilustra su uso a través de ejemplos de la aplicación Performance Review para ayudarle a entender cómo aprovecharlos eficazmente.

Aplicación Performance Review

¿Qué es un estado en Qodly Studio?

Un estado representa una configuración específica de una página en un momento dado, definiendo su apariencia y funcionalidades.

Por ejemplo, un estado se puede utilizar para:

  • Mostrar u ocultar elementos en función de condiciones definidas.
  • Aplicar estilos específicos.
  • Ajustar dinámicamente la interfaz de usuario en función de roles, permisos o datos.

Para una visión completa, consulte la documentación oficial sobre los estados.

Tipos de estados en Qodly studio

Qodly Studio ofrece dos tipos de estados:

estado no condicional

Un estado no condicional se aplica estáticamente, sin depender de una condición dinámica. Permite activar o desactivar un widget de forma predefinida.

Ejemplo: mostrar un formulario sólo cuando el usuario hace clic en un botón, sin comprobar condiciones adicionales.

Estado condicional

Un estado condicional se basa en una lógica definida por el usuario. Modifica la visualización o el estilo de los widgets en función de criterios como las funciones del usuario o los valores de la base de datos.

Ejemplo: ocultar el botón «Enviar» si la tarea ya se ha completado o habilitar/deshabilitar un campo en función del rol del usuario.

Ejemplos de estados

Para ilustrar mejor el uso de los estados, he aquí dos ejemplos concretos de la aplicación Performance Review.

Ejemplo 1: Restringir la edición en función del estado

En la aplicación Performance Review, el estado de un Review determina si un usuario puede ver o editar los datos.

  • Colaborador: los datos son de sólo lectura si el estado es Terminado o Cerrado.
  • Gestor: los datos son de sólo lectura si el estado es Cerrado.
  • RRHH: acceso total a los datos, independientemente del estado.

 

Crear el estado «readOnly»

Para restringir la edición de datos en función del estado de una revisión, creamos un estado específico llamado «readOnly«.

Ahora, seleccione el estado«readOnly» que acaba de crear. Para asegurarse de que el estado está activo y es el que quiere modificar, compruebe que su nombre aparece en la esquina inferior derecha del área de edición de la página.

blank

 

Configurar la visualización del widget

Para cada widget de entrada, modifique el atributo «disabled» a true para desactivar la edición del campo

blank

A continuación, cambie el nombre de los botones Edit por View.

blank

A continuación, oculte los botones Create y Save definiendo la propiedad de visualización a none.

blank

Además, aplique las mismas modificaciones a los diálogos modales abiertos por el botón View:

  • Desactive los campos de entrada.
  • Oculte los botones de acción Save y Drop.
  • Renombre Cancel como Close.

Si un botón se oculta inadvertidamente, utilice el panel Outline de Qodly Studio para localizar y corregir la configuración.

blank

Implementar la lógica de visualización

El siguiente paso es implementar la lógica que activa o desactiva el estado«readOnly» en función del estado de la revisión y del rol del usuario.

El rol del usuario se almacena en los datos de sesión. Por ejemplo, un gerente tiene un doble rol: actúa como Gestor cuando gestiona las revisiones de su equipo pero como Colaborador cuando gestiona las suyas propias. En la barra de menús de la aplicación, al seleccionar Colaborador se actualiza el atributo de rol en el almacenamiento a «colaborador«, mientras que al seleccionar Gestor se actualiza a «gestor«.

Añadimos un atributo calculado a la entidad Review:

exposed Function get isReadOnly() : Boolean
  var $status : Boolean:=False
  If (ds.getUserInfo()#Null)

   If ((ds.getUserInfo().role="Collaborator") && (This.ID_Status>2))
    $status:=True
   End if

   If ((ds.getUserInfo().role="Manager") && (This.ID_Status>3))
    $status:=True
   End if
  End if

  return $status

Esta función devuelve true si el usuario sólo puede ver los datos y false si puede modificarlos.

Nota: la función getUserInfo() da acceso al almacenamiento de la sesión.

Vincule la condición al estado «readOnly»

Por último, haga clic en el botón Condiciones del estado«readOnly» para definir las reglas de visualización.

blank

Añada una condición.

blank

 

Simplemente introduzca la fórmula «selectedReview.isReadOnly is True».

blank

Con esta configuración, la página pasa dinámicamente entre el modo de sólo lectura al de edición sin necesidad de intervención manual ni código complejo.

Ejemplo 2: Controlar la visibilidad de los botones en función del estado de los datos

En la aplicación Performance Review, aparece una barra lateral cuando se selecciona una evaluación. Los botones que se muestran en esta barra lateral dependen de varios factores:

  • Si el estado es sólo lectura o lectura-escritura.
  • Si hay un documento PDF disponible.
  • Si el rol del usuario es Gestor, Colaborador o RRHH.
  • Si se muestra el PDF.

Para manejar estos diferentes casos de manera eficiente, creamos estados para todas las combinaciones posibles.

Para información, el rol se asigna cuando el usuario se conecta y selecciona la página de RRHH, Gestor o Colaborador. Esta información se guarda en el almacenamiento de la sesión. Este concepto se desarrollará en una próxima entrada del blog que tratará sobre la navegación entre las distintas páginas de la aplicación.

Creación de estados para cada escenario

Para garantizar una experiencia de usuario fluida, definimos estados específicos que controlan la visibilidad de los botones en función de las condiciones anteriores. Cada estado ajusta dinámicamente la interfaz para mostrar sólo las acciones relevantes.

Por ejemplo

readOnly

blank

readOnlyPDF

blank

readWriteManager

blank

readWritePDFManager

blank

 

Guardar condiciones reutilizables

Para simplificar la gestión de estados y evitar lógica redundante, definimos condiciones con nombre reutilizables:

  • Colaborador: userInfo.role es «Colaborador».
  • Gestor: userInfo.role es «Gestor».
  • HR: userInfo.role es «HR».
  • selected: selectedReview no es Null y selectedReview.pdfDocument es Null
  • selectedWithPDF: selectedReview.pdfDocument no es Null
  • viewPDF: viewPdf es True
  • isReadOnly: selectedReview.isReadOnly es True
  • isReadWrite: selectedReview.isReadOnly es False

 

Para guardar las condiciones, haga clic en el botón «…» y seleccione «Guardar condición» en el menú.

blank

Aplicar condiciones a los estados

Con estas condiciones predefinidas, la configuración de los estados es mucho más sencilla. En lugar de definir manualmente condiciones complejas para cada estado, simplemente hacemos referencia a las condiciones guardadas. Esto garantiza claridad, coherencia y facilidad de mantenimiento.

Por ejemplo, para definir la visibilidad del estado «readWritePDFManager«, establecemos la condición: selectedWithPDF, isReadWrite y Manager

blank

Depende de usted averiguar cómo se configuran los otros estados, y si tiene alguna pregunta, únase a nosotros en el foro de 4D.

Este enfoque asegura que la interfaz se adapte dinámicamente a los diferentes roles de usuario y estados de revisión, ofreciendo una experiencia de usuario intuitiva y eficiente.

Conclusión

Aprovechar los estados en 4D Qodly Pro es un enfoque poderoso para personalizar la experiencia del usuario y optimizar las interfaces. Utilizándolos eficazmente, usted puede:

  • Adaptar la visibilidad de los elementos en función de los roles y permisos.
  • Mejorar la interactividad y la relevancia de las acciones disponibles.
  • Diseñar aplicaciones sólidas adaptadas a las necesidades reales de los usuarios.

Para obtener más información, consulte nuestra documentación completa sobre los estados.

¿Cómo utiliza los estados en sus aplicaciones Qodly? Comparta sus ideas o preguntas en el foro 4D.

Vanessa Talbot
• Propietario de producto - Vanessa Talbot llegó al equipo de 4D Program en junio de 2014. Como Propietario de producto, está a cargo de escribir las historias de los usuarios y luego traducirlas a especificaciones funcionales. Su papel es también asegurarse de que la implementación de la funcionalidad entregada cumpla con las necesidades del cliente. Desde su llegada, ha trabajado en la definición de funcionalidades claves en 4D. Ha trabajado en la mayoría de las nuevas funcionalidades de multi hilo apropiativo y también en un tema muy complejo: la nueva arquitectura para la aplicación engined. Vanessa es licenciada por Telecom Saint-Etienne. Comenzó su carrera en el Instituto de Investigación Criminal como desarrolladora del departamento audiovisual. También ha trabajado en medios de comunicación y en el ámbito médico como experta en soporte técnico, producción y documentación de nuevas funcionalidades.