Torne as suas aplicações Qodly dinâmicas e interactivas com estados

Os estados desempenham um papel crucial na criação de interfaces dinâmicas e responsivas em 4D Qodly Pro. Permitem controlar a exibição e o comportamento de widgets baseados em condições específicas, como o papel de um usuário, privilégios, ou dados de seu banco de dados.

Esse blog explora esse conceito, apresenta os diferentes tipos de estados, e ilustra seu uso através de exemplos da aplicação Performance Review para ajudá-lo a entender como aproveitá-los efetivamente.

Aplicação de análise de desempenho

O que é um estado no Qodly Studio?

Um estado representa uma configuração específica de uma página num determinado momento, definindo o seu aspeto e as suas funcionalidades.

Por exemplo, um estado pode ser utilizado para:

  • Mostrar ou ocultar elementos com base em condições definidas.
  • Aplicar estilos específicos.
  • Ajustar dinamicamente a interface do utilizador de acordo com funções, permissões ou dados.

Para obter uma visão geral completa, consulte a documentação oficial sobre estados.

Tipos de estado no Qodly Studio

O Qodly Studio oferece dois tipos de estados:

estado não condicional

Um estado não condicional é aplicado de forma estática, sem depender de uma condição dinâmica. Permite-lhe ativar ou desativar um widget de uma forma predefinida.

Exemplo: Mostrar um formulário apenas quando o utilizador clica num botão, sem verificar condições adicionais.

Estado condicional

Um estado condicional baseia-se na lógica definida pelo utilizador. Modifica a apresentação ou o estilo dos widgets com base em critérios como as funções do utilizador ou os valores da base de dados.

Exemplo: Ocultar o botão “Submeter” se a tarefa já estiver concluída ou ativar/desativar um campo com base na função do utilizador.

Exemplos de estados

Para ilustrar melhor a utilização dos estados, eis dois exemplos concretos da aplicação Avaliação do desempenho.

Exemplo 1: Restringir a edição com base no estado

Na aplicação Avaliação de desempenho, o estado de uma avaliação determina se um utilizador pode ver ou editar os dados.

  • Colaborador: Os dados são apenas de leitura se o estado for Concluído ou Fechar.
  • Gestor: Os dados são somente leitura se o status for Fechar.
  • RH: Acesso total aos dados, independentemente do estado.

 

Criar o estado “readOnly

Para restringir a edição de dados com base no estado de uma revisão, criamos um estado específico chamado“readOnly“.

Agora, selecione o estado “readOnly” que acabou de criar. Para garantir que o estado está ativo e que é o que pretende modificar, verifique se o seu nome aparece no canto inferior direito da área de edição da página.

blank

 

Configurar a exibição do widget

Para cada widget de entrada, modifique o atributo “disabled” para true para desativar a edição do campo

blank

Em seguida, renomeie os botões Editar para Exibir.

blank

Em seguida, oculte os botões Criar e Guardar, definindo a propriedade de visualização para nenhum.

blank

Além disso, aplique as mesmas modificações às caixas de diálogo modais abertas pelo botão Ver:

  • Desativar os campos de entrada.
  • Ocultar os botões de ação Guardar e Largar.
  • Renomear Cancelar para Fechar.

Se um botão estiver inadvertidamente oculto, utilize o painel Esboço no Qodly Studio para localizar e corrigir a configuração.

blank

Implementar a lógica de exibição

O próximo passo é implementar a lógica que ativa ou desativa o estado “readOnly” com base no estado da revisão e na função do utilizador.

A função do utilizador é armazenada nos dados da sessão. Por exemplo, um Gestor tem uma função dupla: atua como Gestor quando gere as revisões da sua equipa, mas como Colaborador quando gere as suas próprias revisões. Na barra de menus da aplicação, selecionar Colaborador atualiza o atributo de função no armazenamento para “colaborador“, enquanto selecionar Gestor atualiza-o para “gestor“.

Adicionamos um atributo computado à entidade Revisão:

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 função devolve verdadeiro se o utilizador só puder ver os dados e falso se tiver permissão para os modificar.

Nota: A função getUserInfo() fornece acesso ao armazenamento da sessão.

Ligar a condição ao estado “readOnly

Por fim, clique no botão Condições do estado “readOnly” para definir as regras de exibição.

blank

Adicione uma condição.

blank

 

Basta introduzir a fórmula: “selectedReview.isReadOnly is True”.

blank

Com esta configuração, a página alterna dinamicamente entre o modo só de leitura e o modo de edição sem necessitar de intervenção manual ou código complexo.

Exemplo 2: Visibilidade do botão de controlo com base no estado dos dados

Na aplicação Análise de desempenho, é apresentada uma barra lateral quando é selecionada uma análise. Os botões apresentados nesta barra lateral dependem de vários fatores:

  • Se o status é somente leitura ou leitura-escrita.
  • Se um documento PDF está disponível.
  • Se a função do utilizador é Gestor, Colaborador ou RH.
  • Se o PDF é mostrado.

Para tratar estes diferentes casos de forma eficiente, criamos estados para todas as combinações possíveis.

Para informação, a função é atribuída quando o utilizador inicia sessão e seleciona a página de RH, Gestor ou Colaborador. Esta informação é guardada no armazenamento da sessão. Esse conceito será aprofundado em um próximo post do blog que discutirá a navegação entre as várias páginas do aplicativo.

Criando estados para cada cenário

Para garantir uma experiência de usuário tranquila, definimos estados específicos que controlam a visibilidade do botão com base nas condições acima. Cada estado ajusta dinamicamente a interface para exibir apenas as ações relevantes.

Exemplos:

readOnly

blank

readOnlyPDF

blank

readWriteManager

blank

readWritePDFManager

blank

 

Guardar condições reutilizáveis

Para simplificar a gestão do estado e evitar lógica redundante, definimos condições nomeadas reutilizáveis:

  • Colaborador: userInfo.role é “Colaborador”
  • Gestor: userInfo.role é “Gestor”
  • RH: userInfo.role é “RH”
  • selected: selectedReview é não Null e selectedReview.pdfDocument é Null
  • selectedWithPDF: selectedReview.pdfDocument não é nulo
  • viewPDF: viewPdf é Verdadeiro
  • isReadOnly: selectedReview.isReadOnly é True
  • isReadWrite: selectedReview.isReadOnly é False

 

Para guardar as condições, clique no botão “…” e selecione “Guardar condição” no menu.

blank

Aplicar condições aos estados

Com estas condições predefinidas, a configuração dos estados torna-se muito mais fácil. Em vez de definir manualmente condições complexas para cada estado, basta fazer referência às condições guardadas. Isto garante clareza, consistência e facilidade de manutenção.

Por exemplo, para definir a visibilidade do estado “readWritePDFManager“, definimos a condição: selectedWithPDF, isReadWrite e Manager

blank

Cabe a você descobrir como os outros estados são configurados, e se tiver alguma pergunta, junte-se a nós no fórum 4D.

Essa abordagem garante que a interface se adapta dinamicamente a diferentes papéis de usuário e estados de revisão, fornecendo uma experiência de usuário intuitiva e eficiente.

Conclusão

Aproveitar os estados em 4D Qodly Pro é uma abordagem poderosa para personalizar a experiência do usuário e otimizar interfaces. Ao usá-los efetivamente, pode:

  • Adaptar a visibilidade de elementos com base em papéis e permissões.
  • Melhorar a interatividade e a relevância das ações disponíveis.
  • Conceber aplicações robustas adaptadas às necessidades reais dos utilizadores.

Para saber mais, consulte a nossa documentação completa sobre estados.

Como é que utiliza os estados nas suas aplicações Qodly? Compartilhe suas idéias ou perguntas no fórum 4D!

Vanessa Talbot
• Proprietário do produto - Vanessa Talbot entrou ao time 4D Program em Junho de 2014 como Proprietária do Produto e está a cargo de escrever as histórias dos usuários e depois traduzi-las em especificações funcionais. Seu papel também é garantir que a implementação da funcionalidade entregue cumpra com as necessidades do cliente. Desde sua chegada, trabalhou na definição de funcionalidades chaves em 4D. Trabalhou na maioria das novas funcionalidades multithread preemptivo e também em um tema muito complexo: a nova arquitetura para a aplicação engined. Vanessa é formada pela Telecom Saint-Etienne. Começou sua carreira no Instituto de Investigação Criminal como desenvolvedora do departamento audiovisual. Também trabalhou em meios de comunicação e no âmbito médico como especialista em assistência técnica, produção e documentação de novas funcionalidades.