Gli stati svolgono un ruolo cruciale nella creazione di interfacce dinamiche e reattive in 4D Qodly Pro. Essi consentono di controllare la visualizzazione e il comportamento dei widget in base a condizioni specifiche, come il ruolo di un utente, i suoi privilegi o i dati del database.
Questo blog esplora questo concetto, presenta i diversi tipi di stati e ne illustra l’uso attraverso esempi tratti dall’applicazione Performance Review, per aiutarvi a capire come sfruttarli in modo efficace.
Applicazione Performance Review
Che cos’è uno stato in Qodly Studio?
Uno stato rappresenta una configurazione specifica di una pagina in un determinato momento, definendone l’aspetto e le funzionalità.
Ad esempio, uno stato può essere utilizzato per:
- Mostrare o nascondere elementi in base a condizioni definite.
- Applicare stili specifici.
- Regolare dinamicamente l’interfaccia utente in base a ruoli, permessi o dati.
Per una panoramica completa, consultare la documentazione ufficiale sugli stati.
Tipi di stato in Qodly Studio
Qodly Studio offre due tipi di stati:
stato non condizionale
Uno stato non condizionale viene applicato staticamente, senza basarsi su una condizione dinamica. Consente di attivare o disattivare un widget in modo predefinito.
Esempio: Visualizzazione di un modulo solo quando l’utente fa clic su un pulsante, senza verificare ulteriori condizioni.
Stato condizionale
Uno stato condizionale si basa su una logica definita dall’utente. Modifica la visualizzazione o lo stile dei widget in base a criteri quali i ruoli dell’utente o i valori del database.
Esempio: Nascondere il pulsante “Invia” se l’attività è già stata completata o abilitare/disabilitare un campo in base al ruolo dell’utente.
Esempi di stati
Per illustrare meglio l’uso degli stati, ecco due esempi concreti tratti dall’applicazione Performance Review.
Esempio 1: Limitare la modifica in base allo stato
Nell’applicazione Performance Review, lo stato di una revisione determina se un utente può visualizzare o modificare i dati.
- Collaboratore: I dati sono di sola lettura se lo stato è Fatto o Chiuso.
- Manager: I dati sono di sola lettura se lo stato è Chiuso.
- HR: accesso completo ai dati, indipendentemente dallo stato.
Creare lo stato “readOnly
Per limitare la modifica dei dati in base allo stato di una revisione, creiamo uno stato specifico chiamato“Solo lettura”.
Ora, selezionare lo stato“readOnly” appena creato. Per assicurarsi che lo stato sia attivo e che sia quello che si desidera modificare, verificare che il suo nome appaia nell’angolo in basso a destra dell’area di modifica della pagina.
Configurare la visualizzazione dei widget
Per ogni widget di input, modificare l’attributo “disabled” in true per disabilitare la modifica del campo.
Quindi, rinominare i pulsanti Modifica in Visualizza.
Quindi, nascondere i pulsanti Crea e Salva impostando la proprietà display su none.
Inoltre, applicare le stesse modifiche alle finestre modali aperte dal pulsante Visualizza:
- Disabilitare i campi di input.
- Nascondere i pulsanti d’azione Salva e Lascia.
- Rinominare Annulla in Chiudi.
Se un pulsante viene nascosto inavvertitamente, utilizzare il pannello Outline di Qodly Studio per individuare e correggere la configurazione.
Implementare la logica di visualizzazione
Il passo successivo consiste nell’implementare la logica che attiva o disattiva lo stato di“sola lettura” in base allo stato della revisione e al ruolo dell’utente.
Il ruolo dell’utente è memorizzato nei dati di sessione. Ad esempio, un manager ha un doppio ruolo: agisce come manager quando gestisce le revisioni del suo team, ma come collaboratore quando gestisce le proprie. Nella barra dei menu dell’applicazione, la selezione di Collaboratore aggiorna l’attributo di ruolo in memoria a“collaboratore“, mentre la selezione di Manager lo aggiorna a“manager“.
Aggiungiamo un attributo calcolato all’entità 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
Questa funzione restituisce true se l’utente può solo visualizzare i dati e false se può modificarli.
Nota: la funzione getUserInfo() consente di accedere alla memorizzazione della sessione.
Collegare la condizione allo stato “readOnly” (solo lettura)
Infine, fare clic sul pulsante Condizioni dello stato“readOnly” per definire le regole di visualizzazione.
Aggiungere una condizione.
È sufficiente inserire la formula “selectedReview.isReadOnly is True”.
Con questa configurazione, la pagina passa dinamicamente dalla modalità di sola lettura a quella di modifica senza richiedere un intervento manuale o un codice complesso.
Esempio 2: Controllo della visibilità dei pulsanti in base allo stato dei dati
Nell’applicazione Performance Review, una barra laterale appare quando viene selezionata una revisione. I pulsanti visualizzati in questa barra laterale dipendono da diversi fattori:
- Se lo stato è di sola lettura o di lettura-scrittura.
- Se è disponibile un documento PDF.
- Se il ruolo dell’utente è Manager, Collaboratore o HR.
- Se il PDF è visualizzato.
Per gestire in modo efficiente questi diversi casi, creiamo stati per tutte le possibili combinazioni.
Per informazioni, il ruolo viene assegnato quando l’utente accede e seleziona la pagina HR, Manager o Collaboratore. Queste informazioni vengono memorizzate nella memoria della sessione. Questo concetto sarà ulteriormente approfondito in un prossimo post del blog, in cui si parlerà della navigazione tra le varie pagine dell’applicazione.
Creazione di stati per ogni scenario
Per garantire un’esperienza utente fluida, definiamo stati specifici che controllano la visibilità dei pulsanti in base alle condizioni di cui sopra. Ogni stato regola dinamicamente l’interfaccia per visualizzare solo le azioni pertinenti.
Esempi:
solo lettura
soloPDF
leggiScriviGestore
leggiScriviGestorePDF
Salvataggio di condizioni riutilizzabili
Per semplificare la gestione dello stato ed evitare la logica ridondante, definiamo condizioni riutilizzabili con nome:
- Collaboratore: userInfo.role is “Collaborator” (Collaboratore)
- Manager: userInfo.role è “Manager”.
- HR: ruoloInfo.utente è “HR
- selezionato: selectedReview non è Null e selectedReview.pdfDocument è Null
- selectedWithPDF: selectedReview.pdfDocument non è Null
- viewPDF: viewPdf è Vero
- isReadOnly: selectedReview.isReadOnly è True
- isReadWrite: selectedReview.isReadOnly è False
Per salvare le condizioni, fare clic sul pulsante “…” e selezionare “Salva condizione” dal menu.
Applicazione delle condizioni agli stati
Con queste condizioni predefinite, la configurazione degli stati diventa molto più semplice. Invece di impostare manualmente condizioni complesse per ogni stato, è sufficiente fare riferimento alle condizioni salvate. Questo garantisce chiarezza, coerenza e facilità di manutenzione.
Ad esempio, per definire la visibilità dello stato “readWritePDFManager“, si impostano le condizioni: selectedWithPDF, isReadWrite e Manager.
Sta a voi scoprire come sono configurati gli altri stati e, se avete domande, venite a trovarci sul forum 4D.
Questo approccio garantisce che l’interfaccia si adatti dinamicamente ai diversi ruoli degli utenti e agli stati di revisione, offrendo un’esperienza utente intuitiva ed efficiente.
Conclusione
L’utilizzo degli stati in 4D Qodly Pro è un approccio potente alla personalizzazione dell’esperienza utente e all’ottimizzazione delle interfacce. Utilizzandoli in modo efficace, è possibile
- Adattare la visibilità degli elementi in base ai ruoli e alle autorizzazioni.
- Migliorare l’interattività e la pertinenza delle azioni disponibili.
- Progettare applicazioni robuste e adeguate alle reali esigenze degli utenti.
Per saperne di più, consultate la nostra documentazione completa sugli stati.
Come utilizzate gli stati nelle vostre applicazioni Qodly? Condividete le vostre idee o domande sul forum 4D!