Indice articolo

Una delle caratteristiche più importanti di un software è la capacità di descrivere se stesso e il suo funzionamento. Se questo software è un framework (un insieme di strumenti e regole usate per costruire soluzioni software), questa carattersitica è basilare.

 Sme.UP ERP, oltre ad essere un ERP, mette a disposizione proprio degli strumenti per personalizzare o costruire da zero soluzioni applicative, gli stessi strumenti usati da chi costruisce le soluzioni già rilasciate in Sme.UP ERP.

Ha quindi delle funzioni di autodescrizione: vediamo come velocizzare lo sviluppo e scovare gli errori tramite le funzioni di debug di Web.UP.

Per attivare la modalità debug è necessario usare lo Switch nella barra del titolo (esso è visibile solo se attivato nella cofigurazione o dopo aver messo la password di sviluppatore tramite Ctrl-Shift-F9)

In sistema proporrà una serie di bottoni, prima invisibili, con diverse funzionalità .

Nel caso della scheda nell’esempio, la sezione di sinistra (Cartelle) e quella a destra (LAB) non erano presenti nella visualizzazione normale, ma lo sono in quella di debug. Questo perchè erano nascoste (dim=0)

Quindi in questo caso nella modalità debug potrò verificare anche eventuali sezioni nascoste.

Per ogni scheda potrò utilizzare attraverso la funzione di debug::

  • Il debug generale dell’applicazione (debug utils)
  • Il debug specifico per ogni sezione di scheda (debug info di sezione)

Debug Utils

Il debug utils presente in tutte le schede consente di visualizzare:

1-le variabili globali del contesto LOO.VAR

2-Info e Utils  con una serie di informazioni tra cui la sessione AS400 a cui sono collegato, lo Sme.UP provider, il Device di tipo W – WEB

Con i comandi PING Stop e PING Start posso fermare e successivamente far ripartire i PING. Questo è importante in fase di debug dei job su as400. In caso contrario se in fase di debug dovesse arrivarmi un ping la sessione verrebbe chiusa in automatico perchè non riceverebbe risposta ai ping.

Selezionando inoltre Job INFO posso accedere a una sezione con i relativi dati di job tra cui:

  1. utente collegato
  2. da quanto tempo sono collegato
  3. numero della sessione

3-Initial XML con tutte le variabili e messaggi iniziali

4-Last Fun, ultime funzioni lanciate

5-Login XML che indica le fasi del login e la durata

6-Main Tree che specifica come è composta una scheda. In questo caso particolare possiamo notare l’albero della scheda che è formato da un componente W -Web.UP principale che contiene al suo interno una scheda EXD con due sezioni:

  • sezione SPL Spotlight
  • sezione Scheda EXD a sua volta divisa in un albero TRE e  in una Label LAB

Debug di Sezione

Nel debug specifico di ogni singola sezione avrò a disposizione:

  • INFO con tutte le funzioni e variabili
  • XML della scheda specifica
  • Albero dei componenti di quella scheda (se scheda)
  • EXD Styles, cioè gli stili G.STY definiti per quella scheda e la loro preview
  • WEB.UP Styles cioè gli stili G.STY globali, definiti utilizzabili in Web.UP
  • SCRIPT della scheda
  • Extended Info – eventuali componenti aggiuntivi utili al debug, specifiche per componente

Messaggi Growl

In fase di debug per ogni azione che eseguo abbiamo a disposizione una serie di messaggi GROWL  che mi permettono di visualizzare le funzioni e i dinamismi lanciati.

Selezionando il sottomenù DEBUG dell’Area di Notifica vengono elencate nel dettaglio tutte le azioni eseguite in ordine cronologico dall’evento più vecchio a quello più recente.

Selezionando una FUN posso visualizzare la relativa Funzione e XML.

Esempio di debug di un componente: l’Input Panel

La funzione del Debug risulta molto efficace nel caso di Input Panel

Nel debug dell’Input pannel posso accedere alla sezione:

1-EXTENDED INFO per verificare la FUN chiamata, la comunicazione tra client e server, la risposta XML del Client e la costruzione dell’Input Panel

2-SETUP

3-LAYOUT

Nel caso di inserimento degli elementi di ricerca è possibile visualizzare le relative FUN che vengono lanciate e la decodifica dell’oggetto.

in fase di inserimento dei dati nell’input pannel possiamo inoltro accede e verificare le fun e il relativo xml di risposta alla ricerca.

Verifica dei Dinamismi

Sempre nella sezione di debug dell’area dinamismi è possibile consultare tutti i dinamismi lancia e le loro informazioni

Nell’esempio vediamo che il dinamismo non è abilitato, quindi è presente ma non ha effetti. Si vede anche l’espressione da valutare per l’abilitazione.

Vediamo l’evento che lo fa scattare (ChangeRow)

Vediamo le variabili implicite, cioè quelle create in automatico anche se non dichiarate ([T1], [P1], [K1], tutte le colonne della matrice, le variabili [FROM.xx ecc…)

Il contenutio di questo articolo è ripreso anche nel seguente video: