Store Statico o Store Virtuale

Differenze logico funzionali

Quando l’utente esegue la query prevista dalla grid stessa, il client invia la richiesta al server che esegue la query e ritorna l’insieme dei dati letti dal database al client.

Esistono due modalità (stabilite tramite codice con innesco da parte del client) di restituzione dei dati, una di queste restituisce per intero tutti i dati resi dalla query eseguita sul server che vengono inviati massivamente al client. In questo caso si parla di store statico.

Nel secondo caso, la query viene eseguita staticizzata e picklata sul server (quindi il server mantiene e conosce il numero totale delle righe rese dalla query) e l’invio dei dati avviene a blocchetti di 100 record mano a mano che l’utente scorre la lista dei dati resi dal server; lo scambio di richiesta ed invio fra il client ed il server avviene in modo trasparente dando l’impressione che siano tutti disponibili, in realtà esiste un automatismo che rende tutto fluido e trasparente, ma che condiziona il funzionamento ed il comportamento della grid stessa.

Questo sofisticato meccanismo sostituisce la classica pagina web cui siamo abituati che, nel caso in cui il numero di righe superi dei valori preimpostati, viene presentato un elenco di blocchi di pagine (numerato da 1 a n) con la possibilità di visualizzare il blocco di righe di una determinata pagina; in Genropy questo meccanismo viene reso trasparente ed innescato dagli spostamenti sulla griglia, dando però l’impressione che i dati siano tutti disponibili.

Il parametro che determina questo diverso comportamento è è virtualStore (con valore predefinito True), definito nel Metodo th_options .

Prima di passare ad alcuni esempi, va fatta un’ulteriore precisazione, in quanto il valore di default dello store statico o virtuale cambia in base al contesto.

  • nel casi di grid principali di una tabella (ipotizziamo la classica th_cliente sempre all’interno del progetto Sandbox ) lo store di default è impostato su virtuale in quanto il sistema, non sapendo preventivamente quanto possa essere pesante il contenuto della tabella, potremmo dire che si «autotutela»;

  • nel caso inevece di grid di tabelle in relazione (quindi ad esempio la form del cliente che mostra la griglia con le sue fatture) le griglie in relazione vengono caricate per default con store statico e questo comportamento è innescato direttamente dalla relazione che lega il cliente alla lista delle sue fatture.

In altre parole, anche di default, viene proposto l’utilizzo dello store più appropriato sulla base dai dati che devono essere presentati.

Vediamo ora qualche esempio concreto di come si impostano queste due modalità e come influenzano il comportamento della view.

Store virtuale (virtualStore=True)

class View(BaseComponent):
  def th_struct(self,struct):
      r = struct.view().rows()
      r.fieldcell('ragione_sociale')
      r.fieldcell('cliente_tipo_codice')
      r.fieldcell('indirizzo')
      r.fieldcell('comune_id')
      r.fieldcell('provincia')

  def th_order(self):
      return 'ragione_sociale'

  def th_query(self):
      return dict(column='ragione_sociale', op='contains', val='')

  def th_options(self):
      return dict(virtualStore=True)

Questo primo caso è facilmente riconoscibile in quanto la grid compare inizialmente vuota e viene popolata dopo avere eseguito la query.

../_images/storevirtuale.gif

Attivata la query, la grid viene popolata e scorrendo la lista verso il basso, sarà rinfrescata con i nuovi dati dando l’impressione che siano sempre stati caricati. In realtà viene calcolata solo la pagina «logica» in cui è posizionato il cursore verticale e visualizzato il contenuto corrispondente, tutto ciò in modo trasparente e fluido, dando l’impressione che i dati siano sempre stati lì: è solo un’illusione, in quanto dietro le quinte viene ricalcolata la pagina logica, vengono richiesti i dati al server, viene ripopolata la pagina e rinfrescata, il tutto in modo trasparente e senza che nulla debba essere detto o fatto per programmare o regolare questo processo.

Ovviamente questo processo (utile per qualunque tabella) si rende oltremodo efficiente nel caso di tabelle con moltissime righe il cui caricamento viene fatto solo «al bisogno».

Store statico (virtualStore=False)

class View(BaseComponent):
  def th_struct(self,struct):
      r = struct.view().rows()
      r.fieldcell('ragione_sociale')
      r.fieldcell('cliente_tipo_codice')
      r.fieldcell('indirizzo')
      r.fieldcell('comune_id')
      r.fieldcell('provincia')

  def th_order(self):
      return 'ragione_sociale'

  def th_query(self):
      return dict(column='ragione_sociale', op='contains', val='')

  def th_options(self):
      return dict(virtualStore=False)

Questo secondo caso (che deve essere voluto impostando il virtualStore a False) è altrettanto riconoscibile in quanto la toolbar non presenterà più il pulsante di lancio della query, che verrà lanciata automaticamente.

../_images/storestatico.gif

La visualizzazione di questo tipo di grid (e la presenza del box «auto») sta a significare che si tratta di un virtualstore statico, in altre parole, sta a significare che tutte le righe della tabella (sia si tratti di una tabella principale sia in relazione) sono state caricate sul client e sono immediatamente disponibili, tanto che il filtro (Auto) effettua una ricerca per testo contenuto in tutte le colonne della grid e filtra solo le righe che «in qualche colonna» contegono il testo di ricerca inserito.

È interessante osservare che, qualora si voglia effettuare la ricerca su una colonna specifica della tabella, sarà sufficiente cliccare sull’etichetta «Auto» per far apparire il menù delle colonne su cui si potrà effettuare una ricerca più puntuale.

Fatte queste importanti precisazioni che consentono di ottenere comportamenti diversi delle grid, si può procedere ad analizzare gli altri metodi e proprietà delle grid.

Autore della sezione: Valter Vettorello