Qodly Studio per 4D: Interfacce utente dinamiche con stati di pagina

Tradotto automaticamente da Deepl

Con 4D 20 R6, Qodly Studio for 4D ha introdotto una nuova ed entusiasmante funzione: Stati di pagina. Forse vi siete già imbattuti nel nostro precedente post, ma vediamo cosa rende questa funzione così preziosa per le interfacce utente dinamiche.

Immaginate delle interfacce utente che si adattano istantaneamente ai diversi passaggi o contesti dell’utente.

Ecco alcuni casi d’uso comuni in cui gli Stati di pagina brillano:

  • Attivare o disattivare componenti in base alle azioni dell’utente (ad esempio, attivare il pulsante “Salva” solo quando tutti i campi obbligatori sono compilati).
  • Passare dalla modalità chiara a quella scura con una semplice levetta.
  • Limitare l’accesso alle azioni (lettura, aggiornamento, ecc.) in base ai privilegi dell’utente.

    Stati PIQS

    Stati della pagina: Una soluzione dinamica per le interfacce utente interattive

    Ma che cos’è esattamente uno Stato di pagina? Uno stato è definito dal modo in cui si differenzia dalla pagina originale di Qodly, nota come pagina base, consentendo di rendere visibili in modo condizionato gli elementi dell’interfaccia utente o di applicare stili diversi in base alle interazioni dell’utente. Tutto parte dalla pagina Base, il layout originale dell’interfaccia utente.

    C’è una nuova sezione Stati per gestire gli stati.

    Cominciamo con un semplice esempio.

    Questa pagina di Qodly ha una casella di stile con uno sfondo trasparente. È la pagina Base.

    blank

    Se si desidera presentare all’utente una variante della pagina Base, è sufficiente creare un nuovo stato, selezionarlo nell’elenco Stati e progettarlo.

    Qui è stato creato uno stato Verde, con uno sfondo verde invece dello sfondo trasparente della pagina Base.

    blank

    È stato creato anche unostato Viola, con uno sfondo viola invece dello sfondo trasparente offerto dalla pagina Base.

    blank

    Lo scopo è quello di attivare o disattivare uno stato in base alle situazioni che si verificano durante l’esperienza dell’utente.

    In una pagina Qodly, è possibile creare tutti gli stati necessari in base ai casi d’uso che l’utente finale incontrerà.

    È possibile attivare più stati contemporaneamente.

    Come si attivano o disattivano gli stati?

    L’attivazione o la disattivazione di uno stato può avvenire in tre modi:

    1. Utilizzando azioni standard
    2. Tramite il binding delle condizioni
    3. Da codice back-end sul server

    le azioni standard dello stato

    Grazie alle azioni standard, è possibile attivare/disattivare gli stati quando l’utente interagisce con la pagina.

    Nell’esempio seguente, l’interfaccia utente propone le modalità chiara e scura. Lo stato Light gestisce la modalità chiara con un lightMode CSS

    blank

    e lo stato Dark gestisce la modalità scura con un CSS darkMode.

    blank

    Di seguito è riportata la pagina di base. Quando l’utente fa clic sull’icona della luce, lo stato Light viene attivato e lo stato Dark viene disattivato.

    blank

    (E l’azione viceversa viene eseguita quando l’utente fa clic sull’icona scura: lo stato Dark è abilitato e lo stato Light è disabilitato).

    Ecco il risultato finale.

    blank

    Stati condizionali

    È qui che avviene la vera magia. Gli stati possono essere legati a condizioni, consentendo all’interfaccia utente di rispondere a criteri specifici, come i privilegi dell’utente o i valori dei dati. Lo stato viene attivato o disattivato dinamicamente in base alla valutazione della condizione come VERO o FALSO.

    In questo esempio, l’interfaccia utente mostra un elenco di prodotti e una sezione Dettagli prodotto che alla fine aggiorna il nome del prodotto selezionato.

    Sono stati creati due stati:

    • lo stato di sola lettura
    • lo stato Aggiorna

    blank

    È facile intuire che lo stato Update è necessario quando l’utente può aggiornare il prodotto selezionato, mentre lo stato ReadOnly è necessario quando l’utente può solo visualizzare i dati del prodotto.

    Di seguito è riportato lo stato Update. Nella sezione Dettagli prodotto, il campo Nome è abilitato e c’è un pulsante Salva.

    blank

    Ecco lo stato ReadOnly. Nella sezione Dettagli prodotto, c’è solo un campo Nome disabilitato.

    blank

    Gli stati ReadOnly e Update sono legati a una condizione. La possibilità di aggiornare un prodotto dipende dall’attributo aggiornabile del prodotto selezionato.

    Lo stato di sola lettura è abilitato se la condizione theProduct.updatable = false. Lo stato Aggiorna è abilitato se la condizione theProduct.updatable = true.

    blank

    blankEcco il risultato finale.
    blank

    Grazie all’editor di condizioni, potente e facile da usare , è possibile creare condizioni annidate per gestire la logica aziendale più complessa!

    Queste condizioni possono essere basate su criteri come i valori delle fontiQodly , se la sessione ha o non ha alcuni privilegi e altro ancora. Consultate la documentazione per saperne di più.

    Gestire gli stati dal server

    L’ultima cosa da tenere presente è che abilitare/disabilitare gli stati dal codice di back-end può essere utile quando alcune regole di business possono essere valutate solo sul back-end.

    Nella demo allegata, si può vedere un esempio di questo tipo. L’utente seleziona i prodotti. Quando l’importo totale dei prodotti selezionati è superiore o uguale a 300 dollari, viene attivato uno stato che impedisce la selezione dei prodotti.

    Questo avvienegrazie alle funzioniWeb Form.enableState() e Web Form.disableState().

    Ecco il codice sottostante. Lo stato LimitReached disabilita qualsiasi selezione da parte dell’utente.

    	If ($tempSelection.sum("price")>=300)
    		Web Form.enableState("LimitReached")
    		Web Form.disableState("Initial")
    	End if 

    Ecco il risultato finale.
    blank

    Volete vederlo in azione?

    Scaricate la demo Play In Qodly Studio allegata per imparare a utilizzare gli stati della pagina e a offrire un’interfaccia dinamica agli utenti finali.

    Avatar
    - Product Owner - Marie-Sophie Landrieu-Yvert è entrata a far parte del team 4D Product come Product Owner nel 2017. In qualità di Product Owner, è incaricata di scrivere le storie degli utenti e di tradurle in specifiche funzionali. Il suo ruolo è anche quello di assicurarsi che l'implementazione della funzionalità fornita soddisfi le esigenze del cliente.Marie-Sophie si è laureata presso la scuola di ingegneria ESIGELEC e ha iniziato la sua carriera come ingegnere presso IBM nel 1995. Ha partecipato a vari progetti (di manutenzione o di costruzione) e ha lavorato come sviluppatrice Cobol. In seguito ha lavorato come progettista UML e sviluppatore Java. Ultimamente i suoi ruoli principali erano l'analisi e la scrittura dei requisiti funzionali, il coordinamento dei team di business e di sviluppo.