Assaggi di Genropy
Questo è il primo di una serie di post che avranno lo scopo di illustrare attraverso dei semplici esempi pratici alcuni concetti fondamentali dello sviluppo con Genropy. Tutti questi articoli includeranno codice sorgente e la parte di pagina viva corrispondente: puoi passare dalla visualizzazione del codice e della pagina usando gli appositi bottoni SOURCE e DEMO.
In questo primo assaggio realizzerò la schermata iniziale di un ipotetico gioco in cui i giocatori dovranno inserire il proprio nome e scegliere il loro colore preferito. Con questo esempio voglio spiegare i seguenti concetti:
- Il datastore
- Il puntatore dinamico e i triggering path
- I path gerarchici e relativi
Per approfondimenti e dettagli ti suggerisco di consultare anche il nostro corso base di Genropy.
Incominciamo
Una pagina di Genropy viene costruita dinamicamente sul browser da un engine Javascript che si occupa, tra le molte cose, di conservare uno spazio di memoria riservato per contenere i dati della pagina. Questo spazio si definisce datastore e ad esso accede in lettura e scrittura attraverso dei path separati da punti. Vediamo ora concretamente cosa significa.
Innanzitutto ho creato un box arrotondato (variabile player_box
) dentro il quale aggiungiamo un elemento formbuilder, che serve a definire dei campi con etichetta allineati automaticamente (variabile pl_form
).
In questa form definisco per il momento solo un campo di tipo textbox e nel suo parametro value mi riferisco al path gerarchico player.name
. Esso indica l’indirizzo all’interno del datastore in cui verrà scritto il valore inserito nel campo. Infine aggiungo un semplice div, il cui valore di innerHTML si riferisce al medesimo path a player.name
.
Avrai notato il carattere ^
che precede i path sia nel valore del campo che nel contenuto del div. Questo carattere viene chiamato puntatore dinamico o triggering pointer. Esso sta ad indicare che il path è monitorato da un gestore di eventi della pagina, il quale si occuperà di aggiornare automaticamente tutti gli elementi del DOM al variare dei loro attributi nel datastore.
Nel nostro caso fa sì che quando cambiamo il valore nel campo, il div aggiorni il suo contenuto. Definiamo quindi un path preceduto da un puntatore dinamico con il termine triggering path.
Colore dinamico
Qualsiasi parametro di un elemento di pagina può essere reso dinamico, basta che anziché avere un valore hardcoded, contenga un puntatore ad un path del datastore. Per dimostrarlo ho aggiunto nel secondo esempio un campo per selezionare il colore preferito del giocatore, il quale andrà scritto al path player.color
. Come campo utilizziamo il widget filteringSelect, il quale presenta un menu con tutte le opzioni selezionabili definite dal parametro values.
A scopo estetico ho spostato il div con nome del giocatore in cima al riquadro, in modo da formare una sorta di barra titolo. Noterai che sia il border_color
del riquadro, che lo sfondo border_color
del titolo si riferiscono ora al path player.color
. E poiché voglio che la pagina venga servita con la barra del titolo già colorata, uso l’elemento data per inizializzare il valore di player.color
con il valore gray.
Aggiungiamo il secondo giocatore
In questo terzo esempio ho aggiunto un riquadro per il secondo giocatore. Questo mi offre l’opportunità di parlarti dei path relativi e del perché è molto comodo che i path del datastore siano gerarchici. Noterai infatti che, anziché replicare tutto il codice relativo al box del giocatore, ho definito un metodo playerBox il quale effettua tutte le operazioni mostrate nell’esempio precedente. Tale metodo riceve come solo parametro container, ovvero un elemento contenitore che verrà riempito dal metodo stesso. Nel nostro caso si tratta di un div vuoto.
Noterai che questa volta anziché riferirmi ai path completiplayer.name
e player.color
, ho usato solamente .name
e .color
. Tutti i path che iniziano con il punto sono detti path relativi , ovvero espressi a partire da un path di riferimento, precedentemente definito su un elemento contenitore.
Questo path di riferimento si chiama datapath e notiamo infatti che viene messo come parametro dei due div che andranno a contenere i box, rispettivamente con valore player_one e player_two. Il vantaggio di usare path gerarchici e relativi è che mi permettono di avere i dati dei due giocatori separati in due diversi rami del datastore, potendo però replicare tutta la parte di grafica e di logica raccogliendola a fattore comune in un solo metodo.
Inneschiamo un elemento di script
In questo ultimo esempio ho aggiunto un semplice script che viene eseguito ogni volta che uno dei due nomi viene modificato e se entrambi i nomi sono stati inseriti manda a video un messaggio di benvenuto.
Prova a riempire il campo nome di entrambi i giocatori.
Per fare questo ho definito un elemento dataController, il quale serve a lanciare l’esecuzione dello script Javascript che trovi come primo parametro.
Lo script ha nel suo scopo due variabili p1
e p2
, le quali sono definite come parametri del dataController e lette ai path assolutiplayer_one.name
e player_two.name
. Il solo fatto di riferirsi a questi path con il puntatore ^
fa sì che ogni volta che uno dei nomi viene modificato si inneschi l’esecuzione dello script passando ad esso i valori come variabili nello scope dello script.
Fino a questo esempio avevamo visto come i triggering path provocassero l’aggiornamento istantaneo degli elementi di DOM al variare dei valori loro attributi, ora abbiamo visto che possono innescare script sul client e persino chiamate a funzioni remote sul server, passando ad essi i valori letti come variabili vere e proprie da utilizzare.
Se hai domande o appunti ti invito a partecipare alla discussione nei commenti oppure sui nostri canali social.
Ti aspetto al prossimo assaggio!