Tab Table

Abbiamo un form, accessibile via web, che contiene una tabbed table; per comodità, diciamo che la tabella è costituita da tre tab (o linguette, se preferite) che chiameremo “Primo Tab”, “Secondo Tab”, “Terzo Tab” (originale, vero? Non posso farci niente, sono ingegnere e come tutti sanno per noi ingegneri la fantasia… “fanta” che? È un’aranciata?).
Nel “Secondo tab” è presente un campo, che chiameremo myList, di tipo Dialog List (ma il discorso resta identico per Radio Button e Check Box) per il quale è stata attivata l’opzione “Refresh fields on keyword change”, dal momento che il nostro “Secondo Tab” contiene campi e formule Hide-when che dipendono dal valore di myList.
Cambiamo il valore del campo, il documento si aggiorna, i valori e le formule pure, ma ecco la bella improvvisata: il focus torna al “Primo Tab” (o dove è stato impostato il focus al caricamento della pagina).
È possibile risolvere il problema con diversi workaround, ma il più semplice e diretto (nonché funzionante) è quello di utilizzare una breve riga di codice nell’evento onChange del campo myList.
Osservando il codice della pagina HTML (che Domino ha realizzato per noi) rappresentante il nostro form, è possibile notare che in corrispondenza dei titoli dei vari tab, diventati link che indirizzano il focus sul tab relativo, troviamo un codice di questo tipo:

return _doClick(‘1.0$TableRow’,this,’_self’,’#1.’);

dove 1 è l’identificativo numerico della tabella e 0 è il riferimento numerico del tab (i primi sono riferimenti 1-based, i secondi 0-based, per cui il “Secondo Tab” della prima tabella sarà il tab 1.1 e  così via).
Ecco quindi il codice che andrà inserito nell’evento onChange del campo myList, contenuto nel “Secondo Tab” della nostra tabella:

return _doClick(‘1.1$TableRow’,this,’_self’,’#1.’);

mente per un campo posizionato in un eventuale “Quarto Tab” dovremo scrivere:

return _doClick(‘1.3$TableRow’,this,’_self’,’#1.’);

Nel database di esempio wr_vs_tt.nsf ho predisposto due form (tabTable_nocode e tabTable) del tutto identici salvo il fatto che il primo rappresenta la versione flat (senza codice per il focus sui vari tab) in modo da avere percezione diretta del differente comportamento.
Entrambi i form contengono una tabella con tre tab (facilmente riconoscibili dal colore di sfondo) ciascuno dei quali contiene un campo di tipo Dialog List (contenente a sua volta tre valori) e tre righe di testo, ognuna visibile in relazione al valore selezionato nel campo.
Accedendo al database via browser, verrà visualizzato un frameset che consente di effettuare qualche sperimentazione in merito a quanto descritto.
Abbiamo detto che il metodo sopra riportato è “semplice e diretto”: fin troppo, dal momento che, naturalmente, non è mai consigliabile scrivere i riferimenti espliciti all’interno del codice.
Parametrizzando il tutto opportunamente in dipendenza dalle specifiche condizioni al contorno (motivo per cui mi sono limitato a un esempio diretto) sarà possibile aggiungere o eliminare tab senza doversi preoccupare di modificare il codice nell’evento onChange dei campi sparsi nei vari tab.
Un’ultima annotazione relativa al caso di più tabbed table all’interno dello stesso form: benché il codice sopra descritto sia anche in questo caso perfettamente funzionante, le cose sono leggermente complicate dalla presenza contemporanea di più tabelle.
Supponiamo infatti di avere tre tabelle, ciascuna con tre tab: il “Terzo Tab” della terza tabella contiene il nostro campo myList; secondo quanto scritto sopra, il codice da inserire nell’evento onChange diventa:

return _doClick(‘3.2$TableRow’,this,’_self’,’#3.’);

Cambiando il valore del campo, il documento si aggiorna, e la terza tabella avrà il focus sul “Terzo Tab”, ma la visualizzazione delle altre due tabelle verrà ripristinata al “Primo Tab”.
Supponendo di essere nella seguente situazione, con pagina web caricata a video:

  • prima tabella: focus sul “Secondo Tab”
  • seconda tabella: focus sul “Terzo Tab”
  • terza tabella: focus sul “Terzo Tab”

e volendo modificare il valore del campo myList nel “Terzo Tab” della terza tabella mantenendo anche il focus sui tab a video delle altre due tabelle, il codice esplicito diventerebbe:

return _doClick(‘3.2,2.2,1.1$TableRow’,this,’_self’,’#3.’)

Dovremo quindi trovare delle funzioni dinamiche di parametrizzazione in modo da calcolare al volo il posizionamento del focus sulle altre tabelle per poterlo ripristinare correttamente in fase di aggiornamento della pagina.
Probabilmente in casi simili la soluzione migliore sarebbe forse quella di ristrutturare il design del form in modo da non trovarsi nella situazione di avere campi con opzione “Refresh fields on keyword change” sparsi in vari tab di diverse tabelle (credo che il codice necessario per il workaround, per quanto funzionante, inizierebbe a diventare relativamente più complicato di quanto le circostanze richiederebbero; un codice può anche essere complicato, ma non deve mai essere inutilmente complicato) ma per form contenenti una singola tabbed table (che non significa necessariamente form semplici con pochi campi) la soluzione qui descritta può rappresentare un metodo piuttosto agile e veloce.
Fatemi sapere che ne pensate.
Buon lavoro a tutti!


Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *