%%(display:none)
{{{
WikiUp
}}}
/%
[{TableOfContents }]\\
!!! Obiettivi\\
Il progetto Web.up si propone di creare gli strumenti idonei alla costruzione di siti web con contenuto dinamico legato al gestionale Sme.up. Il concetto di informazione dinamica è legato alla metodologia di reperimento delle informazioni contenute in una pagina HTML: normalmente tutta l'informazione di una pagina statica è cablata nel codice HTML della pagina stessa. Al contrario una pagina dinamica contiene informazioni costruite nel momento stesso in cui un utente remoto ne richiede la visualizzazione: sono quindi informazioni che rispecchiano lo stato di un sistema nel preciso istante in cui viene richiamato.

Le specifiche di progetto possono essere riassunte brevemente nei seguenti punti:
* Definire una serie di strumenti per l'accesso ad informazioni gestionali dall'interno di pagine web. Il gestionale di riferimento per il progetto è Sme.up.\\
* Identificazione di una serie di moduli di base a cui possano essere associate delle funzioni dinamiche fondamentali (ad esempio, la lettura di attributi associati ad un oggetto o l'esecuzione di una funzione complessa come la visualizzazione di una distinta o l'inserimento di un nuovo ordine).\\
* Completa indipendenza tra gli oggetti dinamici e la parte statica delle pagine web. I moduli dinamici devono il più possibile essere indipendenti dal codice HTML statico e il loro utilizzo non deve richiedere competenze superiori a quelle normalmente in possesso ad un progettista di pagine web statiche. Le problematiche relative al collegamento con il programma gestionale devono essere nascoste al progettista Web.up.\\
* Gli oggetti dinamici devono essere caratterizzati da forte atomicità: ogni oggetto può essere identificato in base a tre elementi fondamentali; le informazioni richieste (input), la funzione svolta e il tipo di risultato prodotto (output). Questi tre elementi fondamentali devono essere esaustivi nel definire le proprietà e le metodologie di utilizzo dell'oggetto dinamico. Per l'uso corretto di un oggetto dinamico non devono di norma essere conosciute caratteristiche tecniche intrinseche al funzionamento dell'oggetto stesso.\\
* La struttura del progetto deve consentire in ogni momento lo sviluppo di nuovi moduli dinamici o la semplice modifica dei moduli esistenti. I moduli devono essere il meno possibile correlati tra loro per evitare che modifiche su uno di essi si possa ripercuotere negativamente sugli oggetti eventualmente collegati.\\

!!! Struttura dell'ambiente operativo di Web.up\\

[{Image src='immagini/MBDOC_VIS-WE_002/WE_V001.png' caption='' }]
La figura rappresenta una la configurazione più diffusa tra quelle possibili e riassume, a grandi linee, la conformazione classica di un ambiente client-server dedicato all'e-business, nell'ipotesi di attestare i dati sensibili su una piattaforma AS/400. Questa configurazione prevede un server Internet (normalmente una macchina Windows) su cui girano tutti i moduli necessari alla gestione del sito, ma sul quale non vi sono dati replicati.
Tutte le informazioni sensibili sono su AS/400 e sono accessibili attraverso il solo modulo 6 (incluso in Web.up), dedicato all'interazione tra l'ambiente Java e il gestionale Sme.up. L'utente remoto non può in alcun modo accedere all'AS/400, che pertanto deve essere protetto in modo sicuro e, allo stesso modo, anche gli utenti registrati devono poter eseguire solo le operazioni di loro competenza. La sicurezza di tutto il sistema potrebbe essere ulteriormente aumentata ricorrendo all'utilizzo di un Firewall opportunamente configurato (non mostrato in figura).

Analizziamo le singole parti che compongono la struttura mostrata in figura.
# __Client__    -->    si tratta normalmente di un personal computer, dotato di Browser compatibile con le specifiche HTTP 1.1.\\
La situazione più frequente vede un sistema operativo Windows (di sicuro il più diffuso in ambito workstation) con installato un browser di ultima generazione (tipicamente Microsoft Internet Explorer  o Mozilla Firefox). A livello di client, non è richiesta l'installazione di nulla che non sia già normalmente incluso nel sistema operativo o nel browser e le specifiche del progetto Web.up non richiedono il supporto di Java, né l'installazione di ulteriori programmi.\\
\\
# __Rete TCP/IP__    -->    Web.up può essere installato su qualsiasi rete che supporti il protocollo TCP/IP. E' importante sottolineare che il prodotto può essere installato anche su reti locali, sia Ethernet che Token Ring (anche se ormai in disuso).\\
\\
# __Server HTTP__    -->    è un programma da installare sul server per ottenere il supporto del protocollo di comunicazione HTTP, previsto come un servizio standard del TCP/IP per la pubblicazione delle pagine HTML su rete Internet.\\
Il server HTTP abilita e gestisce l'accesso di un utente remoto al sito Internet di un'azienda e controlla, attraverso lo scambio di messaggi HTTP con il client remoto, la navigazione e l'accesso alle pagine HTML.\\
Il server HTTP ha numerose funzioni, tra le quali fornire al client le pagine HTML richieste, gestire l'autenticazione degli utenti e l'accesso alle pagine riservate e tenere traccia delle pagine visitate, permettendo l'analisi delle statistiche di accesso.\\
I principali server HTTP commerciali sono Internet Information Server di Microsoft (incluso tra gli applicativi di base delle piattaforme Windows di categoria server), Apache di Apache Corporation (server distribuito in modalità open source e molto diffuso, sia su piattaforma Linux/Unix, che Windows), HTTP Server di IBM (derivato da Apache e disponibile per Windows NT, Linux, Unix e OS/400). Web.up può funzionare con uno qualsiasi dei server web citati, sia su piattaforma Windows che su piattaforma Unix/Linux. Non è previsto il supporto per piattaforma OS400.\\
\\
# __Application server__    -->    è un programma da installare sul server web, che lavora solo in stretta congiunzione a un server HTTP. Un Application Server è un particolare componente software che, in unione ad un server http, consente la costruzione dinamica delle pagine HTML. Ad oggi esistono vari application server (gratuiti e commerciali) e tecnologie, che consentono la dinamicizzazione di un sito web. Web.up basa il suo funzionamento sulla piattaforma operativa Java e quindi richiede un application server compatibile con questa essa e in grado di implementare gli standard previsti dal protocollo J2EE, definito da Sun Microelectronics. A questo proposito, tra i prodotti in commercio, il più importante è certamente WebSphere Application Server di IBM, offerto in varie versioni e per diverse piattaforme operative. Altre soluzioni sono JRun della Allaire e Resin della Caucho Tecnology. Tra le soluzioni gratuite, distribuite come open source, la più importante è Tomcat, un application server completo e stabile disponibile per tutte le piattaforme. Altri articoli gratuiti validi, ma sicuramente meno diffusi rispetto a Tomcat sono Jetty e Orion.\\
\\
# __Database locale__    -->    questo elemento non è indispensabile al funzionamento di Web.up, ma la sua presenza può essere comunque molto utile per supportare il log di sistema di Apache o raccogliere informazioni statistiche del salvataggio di informazioni persistenti. Da ribadire comunque che la presenza di un database engine non è comunque richiesta per il corretto funzionamento di Web.Up.\\
\\
# __Modulo Web.up__    -->    E' il modulo base di Web.up, quello che consente la comunicazione tra il server web e il gestionale attestato su AS/400 (tipicamente Sme.up, ma non solo). Questo modulo implementa tutte le funzionalità dinamiche del prodotto (vedere il manuale di Web.up per maggiori dettagli). Web.up è interamente scritto in linguaggio Java e per il suo funzionamento fa uso di tecnologie web legate a questo ambiente di sviluppo (servlet, JSP); richiede pertanto che sul server web di destinazione sia installata una Java Virtual Machine e una ambiente operativo in grado di supportare le specifiche J2EE (vedi la voce Application Server).\\
\\
# __AS/400__    -->    è la macchina di riferimento per il progetto Sme.up, i cui unici requisiti richiesti sono la presenza del gestionale Sme.up e l'installazione e la corretta configurazione di una scheda di rete con supporto del TCP/IP. La comunicazione tra server web e gestionale AS/400 avviene attraverso servizi attestati su protocollo TCP/IP ed è una componente fondamentale del funzionamento di Web.up: per questo motivo il canale di comunicazione tra server web e AS/400 deve garantire buone prestazioni e una disponibilità di banda ottimale. In caso contrario, potrebbe verificarsi un decadimento delle prestazioni globali del sistema, soprattutto delle interrogazioni web, che richiedono un forte scambio di informazioni con il gestionale. Con la configurazione di sistema mostrata in figura, il supporto Java su AS/400 non è richiesto.\\
\\
# __Java Virtual Machine__    -->    rappresenta l'ambiente operativo delle procedure di Web.up, scritte in linguaggio Java. Per questo è necessaria, sul server web, l'installazione e configurazione di una Java Virtual Machine entro la quale eseguire le procedure Java necessarie al funzionamento del prodotto. La Java Virtual Machine viene fornita gratuitamente da Sun MicroSystem ed è anche scaricabile da internet. Per il corretto funzionamento di Web.up è necessaria una versione 1.4.2 della JVM (o superiore).\\

!! Risorse Hardware e Software richieste\\
Dopo aver illustrato sommariamente la struttura di un'installazione Web.up, è utile vedere uno schema riassuntivo dei prerequisiti hardware e software necessari per un'installazione tipica del prodotto (server http + application server + java virtual machine su singolo PC in ambiente Windows).

!! Requisiti hardware minimi\\
* Processore recente\\
* Almeno 1 Gbyte di memoria installata (consigliati 2 GB o superiori, soprattutto con i server Windows di ultima generazione)\\
* 200 MB di spazio libero su HD (per i soli programmi necessari al funzionamento di Web.up. Non tiene conto dello spazio occupato dai siti web)\\

In questo contesto si fa riferimento ad un'installazione tipica di Web.up e non si tiene conto di dispositivi hardware e software necessari per incrementare la sicurezza e migliorare l'affidabilità del sistema, come gruppi di continuità, sistemi automatici di backup dei dati, strutture di polling per la gestione di grossi carichi di lavoro, ecc...
Generalmente la presenza di questi dispositivi non influenza il funzionamento di base di Web.up e non richiede accorgimenti particolari per l'installazione del prodotto.

!!! Requisiti software minimi\\
* Sistema operativo Windows NT/2000/XP/2003 in versione Professional.\\
Le versioni non Professional di Windows possono essere ugualmente utilizzate, ma prevedono una serie di limitazioni sia sul numero di siti web gestibili che sul numero di connessioni concorrenti. Per questo si consiglia caldamente l'utilizzo di una versione Professional.
* Server HTTP. Molti application server (vedi punto successivo) inglobano al loro interno un server HTTP già reimpostato, che può essere utilizzato in alternativa ad un server stand alone.\\
* Application Server. Tra gli application server commerciali è di solito consigliato Resin di Caucho tecnology, che unisce buone prestazioni ad un prezzo decisamente contenuto. Websphere application server di IBM è un altro ottimo prodotto commerciale, ma è pensato per un target di applicazioni più alto rispetto alle tipiche installazioni Web.up. Tra i prodotti open source la preferenza va data senza dubbio a Tomcat, che, pur essendo un prodotto completamente gratuito, ha raggiunto una maturità tecnica e una stabilità tali da renderlo competitivo anche al confronto di concorrenti commerciali.  Tutti i prodotti citati contengono anche un server http che può essere usato in alternativa ad un server esterno.\\
* Java Virtual Machine in versione 1.4.2 o superiore.\\

Un esempio di installazione Web.up basata interamente su prodotti commerciali potrebbe essere:
* Windows XP Professional\\
* Internet Information Server (preinstallato insieme al sistema operativo)\\
* Caucho Resin in versione Standard (con modulo di connessione a IIS)\\
* Java Virtual Machine in versione 1.4.2 o superiore\\

All'estremo opposto,  ecco un esempio di installazione interamente gratuita:
* Sistema operativo Linux (una qualsiasi distribuzione recente)\\
* Apache Web Server (generalmente già presente nella distribuzione)\\
* Tomcat ver. 4.0 o superiore\\
* Java Virtual Machine in versione 1.4.2 o superiore\\
Ovviamente sono possibili soluzione ibride, che fanno uso di prodotti commerciali e di prodotti open source.

!!! Profilo tipico dell'utilizzatore di Web.up\\
Il profilo tipico dell'utilizzatore di Web.up è quello di un progettista di siti web utente mediamente evoluto, con buone conoscenze delle problematiche di sviluppo di siti statici e una conoscenza di base del gestionale Sme.up, in particolar modo in relazione all'organizzazione dell'informazione.

!!! Caratteristiche fondamentali\\
I requisiti tecnici fondamentali su cui è stata posta particolare enfasi sono i seguenti:
* semplicità di utilizzo. Le funzionalità dinamiche offerte da Web.up devono essere accessibili in maniera semplice e il più possibile simile alle metodologie tipiche dello sviluppo di pagine HTML statiche. Al progettista del sito non deve essere richiesta alcuna conoscenza di problematiche tecniche legate allo sviluppo di pagine a contenuto dinamico.\\
* Atomicità. Web.up mette a disposizione dell'utente una serie di moduli dedicati all'implementazione di una serie di funzionalità dinamiche. Il concetto fondamentale è che ogni modulo svolge una sola funzione dinamica ben definita, che può essere semplice (come la lettura di una singola informazione) oppure complessa (come l'esecuzione di una funzione gestionale): la comprensione delle sue funzioni può richiedere la conoscenza delle metodologie di organizzazione delle informazioni all'interno di Sme.up, ma non deve richiedere la conoscenza di tecnologie per il web dinamico.\\
* Massima libertà nella costruzione della parte statica delle pagine web. I moduli dinamici devono essere facilmente inseribili in qualsiasi pagina html anche preesistente, senza richiedere particolari modifiche al codice html statico. Le informazioni dinamiche prodotte dal singolo modulo devono, a loro volta, poter essere presentate nel formato grafico prescelto dall'utente, in modo da rendere le parti a contenuto dinamico esteticamente coerenti con il resto della grafica web.\\

!!! Breve presentazione della struttura dell'informazione nel gestionale Sme.up\\
Web.up è stato pensato principalmente per la presentazione in ambito Internet di dati provenienti dal gestionale Sme.up. Per questo motivo è importante capire, almeno a grandi linee, come sono organizzati i dati gestionali all'interno di Sme.up visto che questa organizzazione si ripercuote pesantemente sui meccanismi di utilizzo dei Tag di Web.up.
Il concetto fondamentale in Sme.up è quello di oggetto: un oggetto è una entità di interesse gestionale, cioè una entità che può avere associate informazioni di interesse gestionale. Un esempio di oggetto potrebbe essere un cliente, un articolo oppure un documento. I singoli oggetti gestionali sono classificati con una struttura a tre livelli, chiamati Tipo, Parametro e Codice. Un esempio renderà meglio l'idea del funzionamento:
esempio 1: un cliente può essere classificato nel seguente modo:
Tipo = CN   decodifica = Contatto
Parametro = CLI  decodifica = Cliente
Codice = 00001 decodifica = Bianchi Mario
La definizione dei tre parametri definisce in modo univoco un oggetto Sme.up, nel caso dell'esempio un cliente specifico. Ovviamente, se lo scopo è quello di ottenere una lista di tutti i clienti si dovrà richiedere una lista di oggetti filtrata in modo da visualizzare solo quelli che hanno Tipo = CN e Parametro = CLI.
La figura 2 mostra in forma grafica un esempio dell'organizzazione a livelli dei dati in Sme.up.

[{Image src='immagini/MBDOC_VIS-WE_002/WE_V002.png' caption='' }]Figura 2: Visualizzazione ad albero della struttura a 3 livelli dei dati nel gestionale Sme.up

Ad ogni oggetto Sme.up sono assegnate delle informazioni aggiuntive memorizzate all'interno di Attributi. Gli attributi si dividono in impliciti e specifici per l'oggetto: i primi sono attributi definiti per default da Sme.up per un dato tipo di oggetto, mentre i secondi sono attributi che possono essere definiti a piacere in modo di consentire la memorizzazione di informazioni aggiuntive oltre a quelle previste dagli attributi standard.

Esempio: dato l'oggetto "Cliente Bianchi Mario", definito da Tipo = CN, Parametro=CLI e Codice=0001, gli attributi possono contenere informazioni come Indirizzo, Partita Iva e qualsiasi altra informazione utile a definire completamente lo stato dell'oggetto "Cliente Bianchi Mario".
A loro volta gli attributi possono essere un oggetto Sme.up: l'attributo "Fornitore" associato a un oggetto articolo può essere un oggetto di tipo fornitore e avere degli attributi associati. Questo consente una forma di "navigazione" tra gli oggetti: da un oggetto Articolo con un attributo Fornitore, a sua volta oggetto coni attributi che possono essere interrogati.
Infine, esistono degli attributi il cui valore non è memorizzato, ma calcolato nel momento stesso in cui si richiede il valore dell'attributo (ad esempio l'attributo "Disponibilità" di un oggetto Articolo).
Una richiesta di lettura di questo attributo scatena l'esecuzione di un apposito programma capace di determinare la disponibilità attuale di quell'articolo. Il metodo con cui viene letto l'attributo è sempre lo stesso, sia che l'attributo è memorizzato che calcolato e l'utente finale non percepisce alcuna differenza di comportamento nei due casi.
Gli attributi hanno anche un'importanza fondamentale nella definizione dei filtri sulle ricerche: una tipica ricerca di oggetti potrebbe essere filtrata sia per tipologia di oggetti che per valore di un loro attributo specifico (es.: ricerca degli oggetti di tipo cliente con il valore Italia nell'attributo Nazione).
L'ultimo concetto importante di cui si parlerà in questa brevissima presentazione è quello di "Funzione Applicativa": ad ogni oggetto Sme.up possono essere associate delle funzioni specifiche, in modo da poter eseguire operazioni gestionali di vario tipo (come la visualizzazione della distinta base di un articolo o l'immissione di un nuovo ordine).
Web.up fornisce gli strumenti necessari per navigare all'interno della struttura dati di Sme.up e per fornire a queste informazioni una visualizzazione compatibile con il formato HTML delle pagine Web pubblicabili su un sito Internet.

!!! Il concetto di risalita\\
L'organizzazione dei dati su tre livelli, tipica di Sme.up, consente di definire il concetto di risalita, ampiamente utilizzato nel gestionale e con ripercussioni pesanti sull'organizzazione dei dati all'interno del framework Web.up. Un esempio pratico è la visualizzazione di una pagina HTML per mostrare il dettaglio di un oggetto Sme.up di Tipo = AR, Parametro = ART e Codice = A01.
L'approccio più semplice è sicuramente quello di scrivere una pagina HTML specifica per l'oggetto e visualizzarla ogni qual volta venga richiesto il dettaglio. Al contrario, la risalita consente un approccio per livelli: in pratica, il motore di risalita ha il compito di determinare la pagina da visualizzare, cercando nel sito la pagina di dettaglio codificata come DET-AR-ART-A01, cioè quella relativa all'oggetto specifico. Se non esiste, viene cercata la pagina di dettaglio con codice DET-AR-ART, riferita all'oggetto generico di Tipo=AR e Parametro=ART. Se nemmeno questa pagina viene trovata, si sale ancora di un livello e si cerca la pagina DET-AR, relativa a tutti gli oggetti che hanno Tipo = AR.

I vantaggi di un meccanismo di risalita di questo tipo sono:
* __Consente di lavorare per eccezioni__: il formato delle pagine di dettaglio è definito partendo prima dalla definizione delle pagine relative a una famiglia di oggetti e poi definendo le pagine di formato per quegli oggetti che, per le loro caratteristiche particolari, si distinguono dal resto degli oggetti della stessa famiglia. Questo approccio semplifica molto il lavoro: se si hanno 100 oggetti di un determinato tipo, dei quali 99 sono sostanzialmente identici nel comportamento e uno solo ha caratteristiche particolari, sarà sufficiente descrivere solo due pagine di formato, una relativa ai 99 oggetti "normali" e un'altra relativa all'oggetto speciale.\\
* __La definizione di pagine di formato a livello di famiglia__ semplifica molto la manutenzione del sito. Se viene creato un nuovo oggetto di tipo determinato, esso assumerà per default la pagina di formato definita per gli oggetti della sua famiglia, senza bisogno di scrivere appositamente una nuova pagina .\\
Ovviamente, il meccanismo di risalita comporta anche delle limitazioni operative, che vincolano in parte la libertà di costruzione de sito Web. In particolare:
** il motore di risalita deve identificare le pagine in base alla funzione e al tipo di oggetto a cui si riferiscono. Per questo motivo, il nome delle pagine di formato non è libero, ma costruito secondo un preciso codice parlante (ad esempio, la pagina DET-AR-ART-A01 contiene il formato della pagina di dettaglio relativa all'oggetto AR-ART-A01, così come la pagina LIS-CN-CLI definirà il formato di una lista di oggetti di tipo CN-CLI);\\
** le pagine di formato devono essere dislocate in apposite directory, la cui definizione è inserita nel file di configurazione di Web.up. Questa limitazione è necessaria per far in modo che Web.up sappia sempre dove cercare le pagine durante la risalita.\\
__N.B.__: Il meccanismo di risalita può essere aggirato in ogni momento, evitando l'utilizzo dei Tag preposti: in questo caso si perderanno i benefici del meccanismo, ma si potrà costruire il proprio sito senza tenere conto dei limiti.

!!! Suddivisione funzionale e caratteristiche tecniche dei moduli di Web.up\\

!! Modulo per la protezione degli accessi ai dati\\
L'accesso alle informazioni dinamiche da presentare sul sito Web deve essere regolato, a discrezione del progettista, da una protezione basata su una password di accesso, con lo scopo di determinare, in una fase successiva dello sviluppo, la categoria a cui può essere ascritto l'utente autorizzato e le funzioni di cui può disporre all'interno del sito in funzione.

La protezione sugli accessi interviene ogni qual volta venga richiesta la visualizzazione di una pagina con contenuti dinamici, cioè informazioni fornite dal programma gestionale Sme.up reperite attraverso Web.up. La richiesta di visualizzazione di una qualsiasi pagina dinamica provoca l'automatica comparsa di un pannello per l'immissione delle password che impedisce la navigazione finché non viene introdotta una password valida. Una volta che un utente si è registrato, potrà navigare liberamente fino al momento in cui si disconnette. La validità di un'autenticazione va dal momento in cui l'utente si identifica correttamente al momento in cui abbandona la navigazione sul sito dinamico.

La protezione del sito può essere abilitata o disabilitata intervenendo sulle impostazioni del file di inizializzazione.

Le informazioni necessarie all'autenticazione di un utente possono essere mantenute in vari modi: in un database locale attestato sul server Web, su un database esterno, in una tabella del gestionale Sme.up (quindi su AS/400).

Possono essere definiti tre livelli di protezione:
1. Sito web protetto da password di ingresso e con gestione delle informazioni utente di interesse statistico: il sito può essere accessibile solo agli utenti registrati forniti di password valida e il progettista può decidere le informazioni sull'utente che ritiene opportuno salvare (dati anagrafici oppure statistici, come le pagine visitate o la frequenza delle visite)
2. Sito web non protetto ma con gestione delle informazioni utente di interesse statistico: il sito è normalmente accessibile a tutti ma vengono raccolte ugualmente una serie di informazioni statistiche sul lavoro svolto dal singolo utente. Di norma all'utente non viene richiesta un'identificazione, ma viene riconosciuto in base alle informazioni sul collegamento reperibili dallo standard HTTP.
3. Sito web non protetto e senza gestione delle informazioni. Il sito è di libero accesso e nessuna informazione statistica viene gestita.

Quando un utente si collega alla parte dinamica, tutte le informazioni su di lui e le tracce sulla sua navigazione vengono mantenute all'interno di un oggetto "Sessione utente" basato sul meccanismo dei Cookies HTTP: è quindi richiesto che l'utente remoto utilizzi un browser con questa funzionalità e che la funzione di accettazione dei Cookies non sia disabilitata. Web.up è comunque in grado di controllare automaticamente lo stato di abilitazione dei Cookies e generare le opportune segnalazioni.

!! Pagine dinamiche fondamentali\\
Le pagine dinamiche generate da Web.up possono essere catalogate in uno dei cosiddetti tipi fondamentali, con un raggruppamento in base alla loro funzionalità logica. In estrema sintesi, i tipi di pagine dinamiche finora identificati sono:
* Pagine di dettaglio (pagine dinamiche che visualizzano le informazioni di dettaglio relative a un oggetto Sme.up di tipo definito).  Per visualizzare una pagina di dettaglio viene attivato il meccanismo di risalita, che determina il formato per mostrare il dettaglio di un oggetto. I file che definiscono il contenuto delle pagine di dettaglio hanno un nome parlante del tipo DET-Tipo-Parametro-Codice e sono dislocate nell'apposita directory definita nel file di inizializzazione di Web.up.\\
* Pagine di menù: sono pagine dinamiche contenenti un menù basato su elementi dinamici. Il contenuto di un menù dinamico, cioè le sue voci, è conosciuto a priori, ma non sono noti i link a cui esso punterà.  Questo concetto è strettamente legato al concetto di risalita: infatti, se una delle voci del menù punta a una pagina di dettaglio, non è possibile conoscere a priori quale sarà la pagina da visualizzare perché questa dovrà essere calcolata dal motore di risalita. Quindi, il link a cui punterà quella voce del menù dovrà essere calcolato inserendo l'opportuno Tag dinamico.\\
* Pagine di lista: sono pagine che mostrano una lista di oggetti omogenei.  A differenza dei menù, la pagina di lista lavora solo con oggetti di tipo completamente omogeneo, cioè tutti oggetti di una stessa famiglia di Sme.up (ad esempio, una lista di clienti o una lista di articoli di un certo tipo). Per ogni voce di lista viene mostrata una piccola scheda di dettaglio, il cui formato è completamente definito da un file di formato caricato esternamente. Le pagine di lista possono poi essere arricchite con funzionalità di paginazione e di filtro sui contenuti.\\

Esiste un'ulteriore sottoclassificazione delle liste:
1. Liste di visualizzazione: liste che si limitano alla visualizzazione degli oggetti appartenenti a una famiglia specifica (è il caso classico di lista con soli scopi di visualizzazione);
2. Liste di selezione: liste orientate alla selezione di un oggetto. Esse mostrano una lista di oggetti in modo che l'utente ne possa selezionare uno. La selezione viene poi tornata alla pagina Web specificata. Le liste di selezione possono anche essere visualizzate in formati particolari come il combobox o il radiobutton;
3. Liste di attributi: liste che mostrano la lista dei valori associati ad uno specifico attributo di un oggetto. A livello grafico esse non si distinguono dalle liste di oggetti, ma la differenza si concentra solo a livello logico: le liste di visualizzazione mostrano gli oggetti di una famiglia, mentre quelle di attributi mostrano la lista di valori che può essere assunta da un attributo di un oggetto. Ad esempio, se l'articolo ha un attributo Colore, la lista degli attributi visualizzerà i colori (o meglio, gli oggetti di tipo colore) disponibili  per quello specifico oggetto.

* Modulo per l'implementazione di filtri di selezione: di norma viene legato a liste di oggetti e consente l'introduzione di condizioni con cui deve essere filtrata la visualizzazione di una lista di elementi di un determinato tipo. I filtri operano normalmente a livello di attributi e permettono di selezionare in una lista di oggetti solo quelli con particolari condizioni sul valore degli attributi. Le condizioni possono essere di vario tipo, dalla semplice uguaglianza a confronti logici più complessi.\\

* Modulo per la visualizzazione di funzioni su oggetti Sme.up: come già detto in precedenza, una delle caratteristiche degli oggetti Sme.up è quella di essere associati a funzioni operative identificate da un codice e specifiche per il tipo di oggetto. Normalmente queste funzioni sono riferite ad operazioni di interrogazione complesse, che non possono essere risolte con la lettura di un semplice attributo. Il modulo di Web.up dedicato alle funzioni applicative consente l'esecuzione di queste funzioni sull'oggetto specificato e la visualizzazione in formato HTML del risultato prodotto dall'elaborazione. Allo stato attuale, il risultato dell'elaborazione viene sempre mostrato come tabella HTML, il cui formato viene definito direttamente dal gestionale Sme.up, mediante un protocollo specifico, che definisce la struttura e il suo contenuto.\\

* Pagine a formato libero: si tratta di tutte le pagine dinamiche che non rientrano in uno dei casi coperti dai moduli descritti in precedenza. Sono pagine il cui formato è liberamente costruibile dal progettista e che possono contenere qualsiasi combinazione di contenuto statico e dinamico. All'interno di esse è possibile inserire qualsiasi Tag di Web.up necessario per la definizione dinamica del contenuto.\\

! Costruzione di una pagina dinamica\\
In precedenza abbiamo visto come sono catalogate le pagine dinamiche in funzione del loro contenuto e della funzione a loro associata. Si è anche detto che, al di là del significato a loro associato, tutte le pagine dinamiche possono avere un formato libero: ad esempio, la pagina di dettaglio dell'oggetto AR-ART-A01 ha la precisa funzione di mostrare le informazioni specifiche di questo oggetto e, per garantire il meccanismo di risalita, deve essere posta in una precisa directory; il suo formato è però completamente definibile dal progettista del sito che decide il tipo di informazioni sull'oggetto da mostrare all'utente finale e il formato con cui queste informazioni vengono visualizzate. Web.up fornisce pertanto un meccanismo semplice per costruire le pagine dinamiche a proprio piacimento, utilizzando degli opportuni TAG.
I concetti alla base di questo meccanismo sono:
* Lo sviluppo di pagine con contenuto dinamico deve essere reso il più possibile simile allo sviluppo di pagine interamente statiche. A questo fine, Web.up fornisce dei TAG che possono essere pensati come una estensione del linguaggio HTML.\\
* L'inserimento di una funzione dinamica in una pagina Web si ottiene inserendo nel codice HTML la stringa di testo che definisce il TAG. La sintassi del Tag è definita ed è delimitata dal resto del codice HTML attraverso l'utilizzo di opportuni delimitatori (per default i delimitatori sono <% e % >, ma è prevista la possibilità di personalizzare la scelta). In fase di elaborazione della pagina, il motore di Web.up sostituirà automaticamente il Tag con il testo generato dall'esecuzione della funzione associata al Tag stesso.\\
* La sintassi di un TAG è pensata in modo da fornire al motore di Web.up tutte le informazioni necessarie all'esecuzione della funzione dinamica richiesta: deve quindi indicare chiaramente la natura della funzione da svolgere e fornire tutte le informazioni necessarie alla sua esecuzione. Il tipico formato di un TAG di Web.up è quindi <%NOMEFUN  PAR1="Valore1"  PAR2="Valore2"...%>, dove NOMEFUN è il codice della funzione richiesta e PAR, PAR2, ... sono i parametri richiesti dalla funzione per il suo funzionamento.\\
Funzioni dinamiche diverse richiedono parametri in numero e tipo differenti, che sono a loro volta suddivisi in obbligatori e facoltativi: i primi sono quelli strettamente necessari per la corretta esecuzione della funzione e devono pertanto essere sempre valorizzati, pena una segnalazione di errore. I secondi sono invece non strettamente necessari e servono in genere per settare condizioni di contorno non indispensabili per la corretta esecuzione della funzione.
* Il motore dinamico di Web.up riconosce le pagine dinamiche in funzione della loro estensione. Normalmente le pagine HTML statiche hanno estensione __.html__ o __.htm__; le pagine contenenti dei Tag di Web.up hanno invece estensione __.inc__ (scelta non ancora definitiva). Queste ultime possono essere utilizzate all'interno di un sito Web come le normali pagine HTML statiche: possono pertanto essere richiamate o definite come target di un link. A differenza delle pagine statiche, una pagina dinamica deve essere elaborata dal motore di Web.up prima di poter essere visualizzata, in modo che tutti i Tag dinamici in essa contenuti possano essere eseguiti correttamente e sostituiti con del testo conforme allo standard HTML. Questa elaborazione non deve essere richiesta esplicitamente, ma eseguita automaticamente ogni volta si richieda la visualizzazione di una pagina con estensione __.inc__.\\
__N.B.__: In ogni caso la pagina che arriva sul browser dell'utente remoto è sempre costituita da puro codice HTML (in parte statico e in parte prodotto on the fly dai moduli dinamici).
* Ad ogni utente che si collega al sito dinamico viene associata una SESSIONE di lavoro, che contraddistingue tutta la sequenza di pagine dinamiche che l'utente visita durante la sua navigazione. Essendo la sessione univoca per ogni utente che si collega, è possibile utilizzarla per salvare tutte le informazioni che si vogliono raccogliere sullo stato della navigazione effettuata dallo specifico utente (ad esempio, mantenere la lista di pagine dinamiche che l'utente ha visitato dopo che si è connesso).\\
* Di norma il risultato dell'esecuzione di un Tag produce del testo che viene inserito nella pagina HTML in sostituzione del Tag stesso. Dove possibile, l'esecuzione del Tag non genera del codice HTML in modo da lasciare al progettista HTML la piena libertà di decidere come inserire i dati letti nella pagina Web. In alcuni casi il Tag deve generare forzatamente del codice HTML che si integra con quello della pagina di destinazione: è prevista una personalizzazione del codice generato per migliorare l'adattabilità di questo codice allo stile della pagina in cui andrà inserito.\\

!! Sicurezza ed autorizzazioni\\
Web.up consente la semplice costruzione di pagine caratterizzate da contenuto dinamico letto da un sistema gestionale in tempo reale. Questo contesto rende importanti in controllo degli accessi al sito dinamico, nonché la gestione delle autorizzazioni sulle funzioni offerte agli utenti remoti.
Il controllo effettuato da Web.up si basa sui seguenti punti:
* Esiste un controllo sugli accessi automaticamente associato alle pagine con estensione __.inc__ (le pagine a contenuto dinamico di Web.up). Se il sito è di tipo protetto (opzione settabile nel file di configurazione), non appena un nuovo utente richiede la visualizzazione di una qualsiasi pagina dinamica, viene proposta una finestra per l'inserimento di codice utente e relativa password. L'accesso al sito è concesso solo introducendo una coppia utente-password corretta (richiesta solo la prima volta); in caso contrario viene mostrata una pagina che segnala il mancato riconoscimento.\\
* Gli utenti sono gestiti per GRUPPI e NOMI: i gruppi servono per creare famiglie logiche di utenti (ad esempio, un gruppo DISTRIBUTORI potrebbe raccogliere tutti gli utenti che sono riconosciuti come distributori). Al tempo stesso, un utente può non appartenere a nessun gruppo specifico, ma avere un'autorizzazione a livello personale (queste autorizzazioni sono sempre prioritarie rispetto a quelle derivate dall'appartenenza a uno specifico gruppo).\\
* L'inserimento di codice e password consente l'identificazione di un utente e la definizione delle autorizzazioni concesse all'utente in funzione del suo profilo personale e dell'appartenenza ad un gruppo specifico.\\

Le autorizzazioni hanno effetto su due livelli distinti:
* a livello di Tag: ogni Tag di Web.up possiede due specifici parametri denominati WTX_GRUPPO e WTX_UTENTE con lo scopo di limitare l'esecuzione del Tag ai soli utenti di una data categoria. Ad esempio, il Tag <%FUNZIONEXY  PAR1=XY PAR2=ZX WTX_GRUPPO=CLIENTI%> verrà eseguito dal motore dinamico solo se l'utente collegato appartiene al gruppo specificato nella voce WTX_GRUPPO e, nella fattispecie, se l'utente è cliente. Se l'utente non appartiene al gruppo CLIENTI, il Tag viene ignorato. Analogamente, il Tag <%FUNZIONE2 PAR1=XY PAR2=ZX UTENTE=PIPPO%> verrà eseguito solo per l'utente PIPPO, mentre per tutti gli altri è come se non esistesse.\\
* a livello di server: ad ogni funzione offerta da un Tag di Web.up è associata una specifica funzione svolta da Sme.up e sottomessa al meccanismo di autorizzazione previsto. Per questo, uno stesso Tag può avere risultati diversi a seconda dello stato delle autorizzazioni relative alla funzione associata e dell'utente che in quel momento sta richiedendo l'esecuzione della funzione.\\

!! Le variabili di sessione\\
! Cos'è una variabile\\
In Web.up è stato introdotto il concetto di VARIABILE: essa può essere intesa come un contenitore in cui il progettista del sito può salvare un'informazione in modo che essa sia disponibile in ogni momento all'interno della sessione di lavoro. Ad esempio, il TAG <%WTX_SETVAR  WTX_VAR="CODCLI" WTX_VALUE="AP00156"%> salva il valore AP00156 nella variabile identificata dal codice CODCLI. Questo valore è salvato nella sessione utente quindi, dopo che è stato settato, può essere riletto e utilizzato in qualsiasi altra pagina del sito. L'utilità di questo meccanismo è quella di dare la possibilità al progettista di salvare un'informazione che potrebbe dimostrarsi utile per recuperare in una delle pagine dinamiche visualizzate successivamente (ad esempio, memorizzare il nome dell'utente collegato e portarselo dietro in tutte le pagine successive). La lettura del valore salvato in una variabile avviene in due modi distinti; il primo metodo fa uso di un Tag di lettura simile a quello di set, del tipo:
<%WTX_GETVAR WTX_VAR="CODCLI"%>
In pratica, il motore dinamico sostituisce questa stringa con il valore della variabile, nella fattispecie con la stringa AP00156. Esiste anche una forma di lettura semplificata, del tipo:
<%#CODCLI#%>
del tutto corrispondente alla precedente, ma più adatta all'utilizzo all'interno di stringhe. Un esempio di utilizzo di questo formato potrebbe essere il seguente:
Il codice cliente di riferimento  è <%#CODCLI#%>
che viene risolta dal motore dinamico nel seguente modo:
Il codice cliente di riferimento è AP00156
Il campo di validità di una variabile si estende ad una sessione: visto che per ogni utente viene creata una sessione specifica, le variabili settate nella sessione di un utente A saranno visibili solo da questo utente ma non da un utente B, anche se questi è collegato contemporaneamente ad A. Le variabili non sono persistenti al di fuori della sessione: quando l'utente abbandona la navigazione tutte le variabili sono perse.
P.S. è previsto lo sviluppo di un meccanismo per rendere le variabili persistenti anche al di fuori della sessione, salvandole in un database di supporto. Questo meccanismo dovrebbe consentire anche lo scambio di informazioni tra sessioni utente distinte (anche se la cosa potrebbe non avere particolari utilità a livello pratico) ma soprattutto di memorizzare informazioni che possono poi essere ripescate in automatico quando l'utente ritorna a collegarsi al sito.

! Accessibilità alle variabili\\
Le variabili definite dall'utente sono normalmente accessibili sia in lettura che in scrittura. Attraverso l'uso degli appositi Tag, l'utente può creare, modificare, cancellare o leggere una qualsiasi variabile. Esistono però delle variabili particolari la cui accessibilità può essere limitata alla sola lettura o addirittura che possono essere completamente inaccessibili all'utente finale. Questo tipo di variabili ad accessibilità ridotta viene riconosciuto dalle lettere iniziali del loro nome, secondo il seguente schema:
* Variabili di sola lettura: il loro nome inizia sempre con il carattere $. Sono variabili il cui valore è normalmente assegnato dal sistema e che pertanto possono essere solamente lette. Il valore di queste variabili non può essere in alcun modo modificato dall'utente e tanto meno possono essere cancellate.\\
* Variabili di servizio: il loro nome inizia sempre con i caratteri $$. Sono variabili di servizio, create e valorizzate dal motore di Web.Up per soli fini interni di elaborazione dei dati. Pur figurando nella lista delle variabili disponibili, queste variabili non sono utilizzabili in alcun modo dall'utente e tutti i Tags per la gestione di variabili non funzionano quando vengono invocati per una variabile di questo tipo.\\
A seguito di quanto detto in precedenza è ovvio che un utente non potrà mai creare una variabile assegnandogli un nome che inizi per il carattere $.

! Le variabili predefinite\\
Le variabili predefinite sono variabili di sistema che per la loro natura particolare sono automaticamente assegnate dal motore di Web.up. A differenza delle variabili normali, esse non devono essere assegnate dall'utente, ma valorizzate automaticamente dal motore dinamico ad ogni apertura di una una pagina dinamica. Alcune di queste variabili predefinite sono accessibili in sola lettura (pertanto il loro nome inizia per $), mentre altre, pur avendo un valore predefinito, possono essere modificate liberamente dall'utente. Allo stato attuale, le variabili di default definite sono le seguenti:
1 WTX_TIPO: definisce il tipo dell'oggetto Sme.up associato alla pagina dinamica.
Visto che la maggioranza delle pagine dinamiche si riferiscono a un oggetto di Sme.up si è pensato di rendere automaticamente reperibili all'interno di una pagina le informazioni che consentono di identificare la tipologia dell'oggetto di riferimento. Un esempio: una pagina di dettaglio dovrà mostrare delle informazioni relative ad uno specifico oggetto di Sme.Up, identificato da un Tipo, un Parametro e un Codice. Per questo motivo, nella costruzione della pagina dinamica, ogni qual volta è necessario far riferimento al tipo dell'oggetto è possibile riferirsi al valore della variabile predefinita WTX_TIPO. TIPO il cui valore potrà essere letto attraverso il Tag <%WTX_GETVAR WTX_VAR="WTX_TIPO"%> oppure nella forma breve <%#WTX_TIPO#%>. Ovviamente, se la pagina non fa riferimento ad un tipo di oggetto particolare il valore della variabile TIPO sarà vuoto.

2 WTX_PARAMETRO: analogamente a WTX_TIPO, definisce il Parametro dell'oggetto Sme.up associato alla pagina dinamica.

3 WTX_CODICE: analogamente ai precedenti, definisce il Codice dell'oggetto Sme.up associato alla pagina dinamica.

4 $WTX_USER_CODE: variabile di sola lettura, è il codice dell'utente che sta navigando, cosi come identificato al momento della richiesta della password. Ovviamente è valorizzato solo se il sito prevede l'identificazione degli utenti al loro ingresso.

5 $WTX_USER_GRUPPO: variabile di sola lettura, è il gruppo in cui è stato classificato l'utente in fase di identificazione. Anche questo vale solo se il sito è sotto autorizzazione.

6 $WTX_USER_LINGUA: variabile di sola lettura, è la lingua di default definita per l'utente.

7 $WTX_USER_DEC: breve descrizione dell'utente, come definita su AS/400.

8 $WTX_SYSTEM: variabile di sola lettura, contiene l'indirizzo TCP/IP o il nome mnemonico della macchina AS/400 su cui devono essere reperiti i dati.

9 $WTX_SYSUSER: variabile di sola lettura, contiene il codice utente utilizzato per la connessione con l'AS/400 su cui devono essere reperiti i dati.

10 $WTX_SYSLIB: variabile di sola lettura, contiene la libreria AS/400 in cui è presente il programma server per la connessione.

11 $WTX_SYSPGM: variabile di sola lettura, contiene il nome del programma AS/400 dedicato alla connessione.
Altre variabili potrebbero essere definite successivamente e aggiunte a quelle ora esistenti.

! Uso delle variabili per la costruzione di pagine dinamiche relative a oggetti generici.\\
Uno dei problemi da risolvere nella costruzione di pagine di formato riferite a famiglie di oggetti è non sapere a priori quale sarà l'oggetto per cui verrà invocata la pagina.
Ad esempio, la pagina dinamica DET-AR.inc definisce il formato di visualizzazione per un generico oggetto di Tipo = AR, quindi potrebbe essere utilizzata sia per la visualizzazione dell'oggetto AR-ART-A01 che per l'oggetto AR-ATR-A02. In queste condizioni l'unica cosa certa è che la pagina si riferirà a un oggetto di Tipo = AR, ma non c'è modo di conoscere il Parametro e il Codice dell'oggetto con cui verrà invocata la pagina. Questo fatto potrebbe creare problemi nella scrittura dei Tag, che potrebbero richiedere l'inserimento del Parametro, nonostante non sia notoi.
Il problema può essere risolto attraverso l'utilizzo delle variabili predefinite: consentono la costruzione di pagine dinamiche non riferite a un oggetto specifico.
Il meccanismo è abbastanza semplice: supponiamo di voler inserire in una pagina dinamica un Tag che visualizza la decodifica di un oggetto: si tratta di un tipico Tag che, per funzionare, richiede l'individuazione di un oggetto specifico, cioè di una terna di valori Tipo-Parametro-Codice. Se, come nel caso dell'esempio precedente, a priori conosciamo solo il tipo dell'oggetto di riferimento, l'unico modo per scrivere il Tag è:

<%WTX_DSPOBJDEC WTX_TIPO="AR" WTX_PARAMETRO="#WTX_PARAMETRO# "  WTX_CODICE="#WTX_CODICE#"%>

In pratica, la funzione WTX_DSPOBJDEC usa come Tipo il valore AR noto a priori mentre per Parametro e per Codice usa i valori reperibili nelle rispettive variabili di sistema. Dato che esse vengono valorizzate non appena la pagina viene aperta, il Tag opererà sempre con valori ben definiti, nonostante nella definizione del formato sia scritto in forma generica. Iil Tag precedente si legge al seguente modo: "leggi la decodifica dell'oggetto di Tipo = AR e avente per Parametro e Codice i valori passati al momento dell'invocazione della pagina".

! Parametri passati a una pagina dinamica\\
L'uso delle variabili è possibile risolvere anche il problema della lettura dei parametri passati a una pagina dinamica in fase di invocazione. Il protocollo HTTP prevede la possibilità di passare valori a una pagina HTML, usando una locuzione del tipo:

<LINK HREF="VediOrdine.inc?numordine=0002&cliente=A01>

In questo esempio, la pagina __VediOrdine.inc__ (dinamica, perché con estensione inc) viene invocata passandogli due parametri valorizzati, definiti rispettivamente numordine e cliente. Il problema nasce dal fatto che, mentre lo standard HTTP prevede il passaggio di parametri, il linguaggio HTML non prevede alcun meccanismo per la lettura dei parametri passati. Il problema può essere risolto solo usando degli script o implementando qualche tecnica dinamica (ASP, JSP o Servlet).  Web.up fornisce un modo semplice per accedere, all'interno di una pagina dinamica, al valore assegnato ai parametri di chiamata: in pratica, tutti i parametri passati a una pagina dinamica al momento della sua apertura sono automaticamente convertiti in variabili e utilizzabili come tali. Pertanto all'interno della pagina __DettaglioCliente.inc__ si avranno a disposizione le variabili NUMORDINE e CLIENTE, il cui valore corrisponde a quello assegnato al momento della chiamata e leggibile attraverso l'utilizzo dei Tag di lettura delle variabili. Queste variabili esistono solo nella pagina DettaglioCliente.inc e vengono cancellate non appena la pagina è stata costruita: pertanto, se si prevede di usare il valore di queste variabili anche in pagine successive è necessario salvarle in opportune variabili temporanee con l'utilizzo degli appositi Tag.

!!! Cache\\
Per migliorare le prestazioni globali del sistema, è stato introdotto in Web.up un meccanismo di __cache dinamica__. L'idea di base è semplice: in un sistema completamente dinamico ogni richiesta di informazione viene servita attraverso una richiesta di lettura inviata al gestionale in tempo reale. Questa soluzione garantisce che l'informazione sia sempre la più aggiornata possibile e che rispecchi sempre la situazione reale nel gestionale; è quindi una soluzione ovvia per tutte quelle informazioni caratterizzate da un'elevata variabilità temporale. Ovviamente una soluzione dinamica costringe a continue letture sul gestionale ed è quindi pesante in termini di tempi di elaborazione e traffico di dati indotto.
Per questo può essere necessario tentare un'ottimizzazione nella gestione delle informazioni (nella realtà non tutte le informazioni sono caratterizzate da ampia variabilità temporale, ma ci sono informazioni che si mantengono pressoché inalterate per lunghi periodi di tempo oppure per le quali non è importante un aggiornamento capillare, ma è accettabile un criterio di aggiornamento meno restrittivo. Per esse può risultare utile un meccanismo di cache nelle letture).
Il principio di funzionamento è semplice: la prima volta che l'informazione viene richiesta, la lettura viene fatta sul gestionale con le solite modalità. Il risultato della lettura viene però salvato in una cache dove rimane disponibile per un eventuale riutilizzo nel caso di richieste dello stesso tipo di quella originaria. Il vantaggio è quello di ridurre il numero di interrogazioni sul gestionale: fintantoché l'informazione permane nella cache, nessuna lettura dello stesso tipo verrà pi- indirizzata al gestionale con il risultato di ridurre il traffico dei dati sulla rete e velocizzare l'operazione (la lettura da cache è sempre pi- veloce della lettura remota su gestionale). Ovviamente lo svantaggio è quello di perdere in parte i vantaggi della dinamicità di lettura: fino a quando i dati rimangono in cache la lettura darà sempre la stessa risposta (quella salvata in cache) e non si renderà conto di eventuali variazioni del dato che sono nel frattempo pervenute sul gestionale. Queste brevi considerazioni fanno capire come il meccanismo di cache può migliorare molto l'efficienza globale del sistema ma richiede sempre una attenta pianificazione, intesa come scelta attenta delle condizioni operative che garantiscono i migliori risultati con il minimo di controindicazioni.

!! La cache in Web.up\\
All'interno di Web.up la cache è stata implementata a livello di singolo Tag. In pratica, il risultato derivante dall'esecuzione di uno specifico Tag può essere salvato all'interno di una cache basata su file system e riutilizzato ogni volta che un Tag dello stesso tipo viene nuovamente richiesto. Ovviamente il meccanismo di caching prevede tutta una serie di parametri che consentono di ottimizzare la logica di funzionamento alla tipologia dei dati e alle esigenze specifiche del sito dinamico che si sta sviluppando.
In particolare il meccanismo di ottimizzazione si basa sui seguenti elementi:

Condizioni di esecuzione del Tag: il riutilizzo delle informazioni salvate in cache deve essere controllato a livello di condizioni di sistema. Cioè è necessario controllare sempre le condizioni di contorno alla esecuzione di un Tag e controllare che il riutilizzo del risultato avvenga solo quando le condizioni di contorno sono le stesse. Ad esempio, in un sistema protetto lo stesso tag può dare risultati diversi a seconda di chi sia l'utente collegato in quel momento. Per questo motivo il motore ci cache deve tener conto del nome utente e garantire il riutilizzo delle informazioni solo quando il livello di autorizzazione dei richiedenti è effettivamente lo stesso.

Politica di cache: in ogni momento è possibile decidere quali Tag sono assoggettati a cache e quali invece continuano a mantenere il loro normale comportamento dinamico. L'impostazione è a due livelli; il primo prevede l'impostazione delle condizioni di caching a livello di sito globale a cui fa seguito la specificazione delle eccezioni legate ai singoli Tag. L'approccio è abbastanza aperto: ad esempio, si può decidere che tutti i Tag presenti nel sito dinamico vengano sottoposti a cache secondo delle condizioni uguali per tutti e poi specificare che alcuni Tag posti in alcune pagine particolari abbiano condizioni diverse (ad esempio non vadano in cache o ci vadano con condizioni diverse da quelle del sistema globale). Oppure seguire un approccio opposto, cioè non specificare alcuna condizione globale ma specificare uno per uno i soli Tag che devono andare in cache.
TTL (time to live): definisce il tempo di permanenza di un dato nella cache. Una volta che una informazione viene salvata nella cache viene mantenuta per un tempo pari al TTL. Per tutto questo periodo una richiesta di informazione da parte del sistema dinamico verrà servita pescando i dati dalla cache. Alla scadenza l'informazione presente in cache viene cancellata e una successiva richiesta di dati verrà servita attraverso una normale lettura dinamica. Ovviamente anche il TTL può essere specificato a livello globale o per ognuno dei singoli Tag sottoposti a cache.
Il motore di caching presente in Web.up lavora ad alto livello ed esegue in automatico tutta una serie di operazioni necessarie alla corretta gestione del meccanismo di caching. Ad esempio, il risultato di un tag viene salvato nella cache tenendo conto di tutta una serie di condizioni aggiuntive come autorizzazione dell'utente, lingua, condizioni in cui il tag è stato eseguito.

! Configurazione della cache di Web.up\\
Come già detto in precedenza la configurazione della cache in Web.up è a due livelli, uno globale e uno a livello di singolo Tag.

__Configurazione a livello globale__
Le impostazioni di cache vengono impostate a livello di sito dinamico e quindi valgono per tutti i Tag dinamici che verranno inseriti in quel sito. Queste impostazioni devono essere specificate all'interno del file di configurazione di Web.up e definite per ognuno dei siti virtuali in esso configurati. Vediamo una esempio di configurazione, estratto dal file di configurazione di Web.up:
*********************************************************\\
CacheRoot=C:/cache/agenda
TimeToLive=5
TimeUnit=MIN
CachePolicy=ALL
*********************************************************\\
L'impostazione a livello di singolo sito virtuale prevede quattro valori da impostare:
1 CacheRoot: è la directory in cui verranno salvati i file di cache. Il meccanismo di cache di Web.Up si attesta su file system e quindi è necessario specificare quale sarà la directory che conterrà fisicamente la cache. Si tenga conto che nel caso di siti complessi, con molti Tag dinamici e tempi di permanenza in cache molto lunghi è possibile che la directory di cache occupi grandi spazi di memoria fisica.

2 TimeToLive: tempo di permanenza di un dato in cache. È il tempo che deve intercorrere prima che una dato in cache venga considerato scaduto e quindi eliminato. Il tempo viene calcolato a partire dal momento in cui la prima lettura dinamica è stata salvata nella cache: da quel momento in poi, tutte le successive chiamate dello stesso tipo vengono servite dalla cache fino a quando non è intercorso un tempo pari al TTL.

3 TimeUnit: specifica l'unità di misura del tempo specificato nel parametro TimeToLive. I valori possibili sono: SEC (secondi), MIN(minuti), HOUR (ore) e DAY (giorni).

4 CachePolicy: definisce la politica di cache a livello di sito globale. I valori possibili sono due:
ALL: tutti i tag dinamici presenti nel sito sono assoggettati al meccanismo di cache. Sono esclusi solo i Tag per cui non è prevista la cache e quei tag per cui si specificano delle condizioni personalizzate diverse da quelle globali del sistema.
ONLY_SPECIFIED: vengono assoggettati a cache solo quei Tag per cui è esplicitamente richiesto attraverso le impostazioni a livello di Tag. Se a livello di singolo Tag non si specifica nulla il Tag non va in cache.

! Configurazione a livello di singolo Tag\\
Nel punto precedente si sono analizzate le condizioni di configurazione globale della cache. In questo paragrafo si analizzano invece le condizioni di configurazione della cache applicabili a livello di Tag. È importante specificare una cosa: le condizioni definite a livello di Tag sono prioritarie rispetto a quelle globali; quando si valuta l'esecuzione di uno specifico Tag, il motore di Web.Up tenta prima di determinare le condizioni di cache dello specifico Tag e solo in mancanza di queste valuta le condizioni globali.
Le impostazioni di cache legate al singolo Tag possono essere definite attraverso l'impostazione di alcuni attributi specifici del Tag: questi nuovi attributi sono definiti e riconosciuti da tutti i Tag di Web.up, anche se per alcuni vengono ignorati perché relativi a Tag per cui non ha senso il concetto di cache.
Vediamo la lista degli attributi dei Tag relativi alla gestione della cache:
1 WTX_CACHE: specifica se il Tag deve essere assoggettato a cache oppure no. Il valore di questo parametro è prioritaria rispetto alle impostazioni globali del sito. La seguente tabella riassume la logica con cui il motore Web.up decide se un Tag deve andare in cache oppure no basandosi sul confronto del valore di CachePolicy definito a livello di sistema e del valore dell'attributo WTX_CACHE del Tag in esame.

[{Image src='immagini/MBDOC_VIS-WE_002/WE_V003.png' caption='' }]
1 WTX_TTL: Time to live. Concettualmente è la stessa cosa del parametro analogo definito a livello di sistema. Definisce il tempo di permaneza del risultato del Tag nella Cache. Il valore del TTL definito a livello di Tag è prioritario rispetto a quello globale; ciò consente di tarare caso per caso i tempi di permanenza in cache ed ottimizzare il meccanismo in funzione della tipologia di informazioni legate e al contesto operativo globale. Il formato del parametro WTX_TTL è una stringa formata da un numero seguito da una lettera che indica l'unità di tempo, del tipo:
numero + unità di tempo (S,M,H,D)
1 WTX_SCOPE: serve per aggirare il meccanismo delle autorizzazioni. In generale il motore di cache tiene conto dell'utente attivo nel momento in cui viene richiesta l'esecuzione della Tag e ripropone i risultati salvati in cache solo se l'utente che effettua la richiesta è lo stesso ( o solo se appartiene allo stesso gruppo di autorizzazioni). Questo meccanismo può però essere pesante in alcune situazioni: ad esempio quando ci si trova in un sito protetto e si esegue un Tag dinamico che tratta solo informazioni non protette. In queste condizioni può essere utile forzare il motore di cache a non utilizzare le impostazioni utente e salvare il cache le informazioni senza associare ad esse alcun utente di riferimento. In questo modo si garantisce che l'informazione salvata in cache potrà essere riutilizzata ogni volta che serve a prescindere dalle autorizzazioni. L'uso di questo attributo ha senso solo all'interno di siti protetti da autorizzazione e va fatto solo quando si è certi che l'informazione non è protetta: l'uso improprio di questo attributo può portare a forzature del meccanismo di protezione di Web.Up e va fatta con cautela. La sintassi di questo attributo è:
WTX_SCOPE="ALL"

!!! Classificazione dei TAG disponibili in Web.up\\
I Tag disponibili in Web.up possono a loro volta essere suddivisi in macrocategorie, a seconda del tipo di funzionalità svolta.

!! Tag per la creazione di link dinamici verso pagine dinamiche fondamentali\\
Questa famiglia raggruppa tutti i Tag orientati alla creazione di link verso pagine dinamiche fondamentali. La definizione di questi link è frutto di un'elaborazione di tipo dinamico: mentre in un sito statico un link unisce sempre la pagina di partenza con quella a cui si vuole saltare, in un sito dinamico la pagina di arrivo potrebbe non essere nota a priori, ma calcolata di volta in volta, a seconda delle condizioni operative. Tipico è il caso in cui si applica il meccanismo di risalita, di cui si è già detto in precedenza: se si vuole introdurre in una pagina HTML un link ad una pagina di dettaglio, è necessario ricorrere a un Tag dinamico perché non è nota a priori la pagina di formato da utilizzare. Il Tag di link riceverà tutte le informazioni necessarie e, in base ad esse, attiverà il meccanismo di risalita per determinare la pagina a cui indirizzare il link. Normalmente l'utilizzo dei Tag di questa famiglia è richiesto solo se nella definizione del sito si decide di far uso dei meccanismi di risalita.
I principali Tag di questa categoria sono i seguenti:
1 WTX_LNKOBJDET: inserisce un link verso una pagina di Dettaglio, calcolata dinamicamente.
2 WTX_LNKOBJLST: inserisce un link verso una pagina di Lista
3 WTX_LNKFUN: inserisce un link verso una pagina che mostra il risultato di una funzione.
4 WTX_LNKMNU: inserisce un link verso una pagina di menù  (P.S.: probabilmente verrà eliminato)
5 WTX_LNKOBJSLC: inserisce un link verso una Lista di selezione oggetto.
6 WTX_LNKOAVLST: inserisce un link verso una pagina di lista di attributi.
7 WTX_LNKOAVSLC: inserisce un link verso una pagina di selezione attributi.
8 WTX_LNKFLT: inserisce un link verso una pagina di visualizzazione di un filtro.

!! Tag per la costruzione del contenuto delle pagine dinamiche\\
Questi Tag che possono essere utilizzati, all'interno di un file di estensione __*.inc__,  per l'inserimento di oggetti dinamici e ad ognuno corrisponde una precisa funzione dinamica, che normalmente attiva la lettura o la scrittura di informazioni di tipo gestionale verso Sme.up.
I principali Tag di questa famiglia sono i seguenti:
1 WTX_DSPOBJLST: inserisce nella pagina una lista di oggetti di tipo predefinito, leggendola dal gestionale. Il formato di visualizzazione della lista è definibile dal progettista del sito.
2 WTX_DSPOBJSLC: inserisce nella pagina una lista di selezione di oggetti di tipo visualizzato. L'oggetto selezionato viene tornato ad una pagina prefissata.
3 WTX_DSPOBJCMB: simile al Tag WTX_DSPOBJSLC, consente una selezione di un oggetto mostrando la lista sotto forma di combobox.
4 WTX_DSPOBJRAD: come WTX_DSPOBJCMB ma la lista di oggetti viene mostrata nel formato radiobutton
5 WTX_DSPOAVLST: inserisce nella pagina la lista degli attributi di un oggetto specificato.
6 WTX_DSPOAVSLC: inserisce nella pagina una lista per la selezione di un attributo di un oggetto specificato.
7 WTX_DSPOAVCMB: simile al Tag WTX_DSPOBJSLC, consente la selezione di un attributo di un oggetto mostrando la lista nel formato combobox.
8 WTX_DSPOAVRAD: come WTX_DSPOAVCMB ma mostra la lista di attributi sotto forma di radiobutton.
9 WTX_DSPOAV: permette la lettura del valore associato ad uno specifico attributo di un oggetto. Oltre al valore permette la lettura di informazioni sul tipo e sulla natura dell'attributo.
10 WTX_DSPOBJDEC:  legge dal gestionale la decodifica di un oggetto specificato.
11 WTX_DSPFLT: inserisce nella pagina un form per la definizione di un filtro di ricerca. Vengono mostrati i campi di filtro in modo che l'utente possa riempirli. I valori immessi verranno poi utilizzati per filtrare una lista di oggetti.
12 WTX_DSPOBJICN: inserisce nella pagina il riferimento ad una icona associata ad un oggetto Sme.up predefinito. Le icone sono attestate in una precisa directory identificata nel file di inizializzazione di Web.up.
13 WTX_DSPOBJIMG: inserisce nella pagina il riferimento a un'immagine associata ad un oggetto Sme.up predefinito. Le immagini sono attestate in una precisa directory identificata nel file di inizializzazione di Web.Up.
14 WTX_DSPTXTSRC: inserisce nella pagina un campo di immissione associato ad una famiglia di oggetti. Fornisce tutti i meccanismi di ricerca e filtro sulla lista di oggetti selezionabili.
15 WTX_DSPOBJLNK: visualizza il codice oggetto creando un link alla pagina di dettaglio e inserendo i collegamenti alla interrogazione delle funzioni, dei parametri e dei numeri associati.

!! Tag per la gestione delle variabili\\
Questi Tag consentono il salvataggio e la lettura di una variabile salvata a livello di sessione.
I principali Tag di questa categoria sono i seguenti:
1 WTX_SETVAR: Assegnamento di variabile
2 WTX_GETVAR: Lettura di variabile
3 WTX_DLTVAR: Cancellazione di una variabile dalla sessione corrente.

!! Tag per il controllo di flusso\\
Questi Tag consentono di controllare il flusso di esecuzione della pagina HTML dinamica e definire pagine dinamiche il cui aspetto finale dipende dal risultato dalle condizioni imposte dal progettista.
1 WTX_IF: Implementazione della funzione logica IF. Esegue in alternativa due diverse parti di codice in funzione del risultato di una condizione di tipo logico.

!! Tag per l'esecuzione di azioni e funzioni\\
Questi tag consentono l'esecuzione di azioni predefinite su oggetti gestionali (si tratta tipicamente di operazioni di scrittura, gestione o modifica di dati gestionali eseguite dal gestionale).

1 WTX_DSPFUN: mostra il risultato di una funzione applicata ad un oggetto. Il risultato è mostrato sotto forma di tabella HTML il cui aspetto e contenuto è interamente definito dal gestionale. La funzione è una di quelle predefinite sul gestionale e salvate nella apposita tabella.

2 WTX_EXEFUN: richiede al gestionale l'esecuzione di una funzione specifica. Viene mostrato all'utente un pannello di immissione per l'inserimento dei dati di input richiesti dalla funzione (la cui lista è definita dal gestionale). I dati immessi vengono controllati ed inviati al modulo gestionale che esegue fisicamente la funzione; in caso di errore viene generato un messaggio per l'utente.

!!! Dettaglio Tag per la creazione di link dinamici verso pagine dinamiche fondamentali\\
!! WTX_LNKOBJDET\\
! Descrizione\\
Tag per la visualizzazione del link ad una pagina di dettaglio di un oggetto Sme.up.
Il formato della pagina linkata è descritto nel file DET-tipo-parametro-codice-formato.inc
presente nella directory destinata alle pagine di dettaglio (impostabile nel file di configurazione).
La ricerca del file avviene tramite una risalita così definita:
1- DET-tipo-parametro-codice-formato.inc
2- DET-tipo-parametro-codice.inc
3- DET-tipo-parametro.inc
4- DET-tipo.inc
5- DET.inc

! Sintassi\\
<%WTX_LNKOBJDET WTX_TIPO="..." WTX_PARAMETRO="..." WTX_CODICE="..." WTX_PAGFMT="..."%>

- TIPO, PARAMETRO, CODICE: valori obbligatori che definiscono l'oggettoSme.up cui è riferito il link
- FORMATO: il valore, facoltativo,identifica il tipo di vista associata all'oggetto
! Output\\
Ritorna il link alla pagina di dettaglio per l'oggetto specificato da TIPO, PARAMETRO, CODICE nel FORMATO richiesto.

! Struttura\\
Struttura modello standard (http://test.smea.it/pagineTest/wtx_lnkobjdet.inc?&wtx_rsltag=&wtx_strtag=)

! Esempi\\
Dettaglio articolo codice A01
WTX_TIPO=AR, WTX_PARAMETRO=ART, WTX_CODICE=A01 (http://test.smea.it/servlet/ServletTag?WTX_WBP=WTX_LNKOBJDET&WTX_TIPO=AR&WTX_PARAMETRO=ART&WTX_CODICE=A01)

!! WTX_LNKOBJLST\\
! Descrizione\\
Tag per la visualizzazione del link a una pagina di lista di un oggetto Sme.up.
Il formato della pagina linkata è descritto nel file LST-formato.inc, presente nella directory destinata alle pagine di lista (impostabile nel file di configurazione).
Gli attributi su cui filtrare la lista vengono decisi dal gestionale Sme.up tramite tabella JAA.

! Sintassi\\
<%WTX_LNKOBJLST WTX_TIPO="..." WTX_PARAMETRO="..." WTX_PAGFMT="..."
WTX_DACODICE="..." WTX_ACODICE="..." WTX_ METODO="..." WTX_FILTRO[n]="..." WTX_CODFILTRO"..."%>

- TIPO, PARAMETRO: valori obbligatori che definiscono l'oggetto Sme.up cui  il link è riferito.
Formato
Tipo di vista associata all'oggetto
- DACODICE: Limite iniziale
- ACODICE: Limite finale
- METODO: Metodo di accesso al file
CCA - Codice/Compreso/Avanti
CCI - Codice/Compreso/Indietro
CEA - Codice/Escluso/Avanti
CEI - Codice/Escluso/Indietro
DCA - Descrizione/Compreso/Avanti
DCI - Descrizione/Compreso/Indietro
DEA - Descrizione/Escluso/Avanti
DEI - Descrizione/Escluso/Indietro
- FILTRO[1-5]: Valori di filtro

! Output\\
Ritorna il link alla pagina di lista per l'oggetto specificato da TIPO, PARAMETRO
nel PAGFMT richiesto e con i limiti impostati

! Struttura\\
Struttura modello standard (http://test.smea.it/pagineTest/wtx_lnkobjlst.inc?&wtx_rsltag=&wtx_strtag=)

! Esempi\\
Lista Articoli generici - 1 elemento per riga - pulsanti di paginazione
WTX_TIPO=AR, WTX_PARAMETRO=ART, WTX_PAGFMT=001 (http://test.smea.it/servlet/ServletTag?WTX_WBP=WTX_LNKOBJLST&WTX_TIPO=AR&WTX_PARAMETRO=ART&WTX_PAGFMT=001)

!! WTX_LNKFUN\\
! Descrizione\\
Tag per la visualizzazione del link a una pagina che contiene una funzione di tipo DSPFUN applicata a un oggetto Sme.up.
Il formato della pagina linkata è descritto nel file FUN-categoria-CodiceFunzione-Tipo-Parametro.inc presente nella directory destinata alle pagine di funzione (impostabile nel file di configurazione).
La ricerca del file avviene tramite una risalita così definita:
1- FUN-Categoria-CodiceFunzione-Tipo-Parametro.inc
2- FUN-Categoria-CodiceFunzione-Tipo.inc
3- FUN-Categoria-CodiceFunzione.inc
4- FUN-Categoria.inc
5- FUN.inc

! Sintassi\\
<%WTX_LNKFUN WTX_TIPOFUNZIONE="..." WTX_CODICEFUNZIONE="..." WTX_TIPO="..." WTX_PARAMETRO="..." WTX_CODICE="..."
WTX_METODO="..." WTX_ROWFMT="..." WTX_INPUT="..."%>

-WTX_TIPOFUNZIONE: Categoria della funzione (ad esempio J-AR)
- WTX_CODICEFUNZIONE: Codice della funzione
- WTX_TIPO: Tipo dell'oggetto di cui si richiede la funzione
- WTX_PARAMETRO: Parametro dell'oggetto di cui si richiede la funzione
- WTX_CODICE: Codice dell'oggetto di cui si richiede la funzione
- WTX_METODO: Metodo di composizione tabella.
Valori possibili:
- CRTAUT: tabella composta da server
- CRTLIB: tabella a composizione libera, necessario  il parametro ROWFMT
- WTX_ROWFMT: Formato della riga tabella da usare nel caso di composizione libera.
- WTX_INPUT = Campo libero di input (va nella D2)

! Output\\
Ritorna il link alla pagina di funzione per l'oggetto specificato da TIPO, PARAMETRO,CODICE per la funzione richiesta.

! Struttura\\
Struttura modello standard (http://test.smea.it/pagineTest/wtx_lnkfun.inc?&wtx_rsltag=&wtx_strtag=)

! Esempi\\
Creazione link alla pagina della funzione J_020 di categoria J-AR per l'oggetto AR-ART-A01
<%WTX_LNKFUN WTX_TIPOFUNZIONE="J-AR" WTX_CODICEFUNZIONE="J_020" WTX_TIPO="AR" WTX_PARAMETRO="ART" WTX_CODICE="A01"%> (http://test.smea.it/servlet/ServletTag?WTX_WBP=WTX_LNKFUN&WTX_TIPOFUNZIONE=J-AR&WTX_CODICEFUNZIONE=J_020&WTX_TIPO=AR&WTX_PARAMETRO=ART&WTX_CODICE=A01)

!! WTX_LNKMNU\\
! Descrizione\\
Tag per la visualizzazione del link ad una pagina di Menù.
Il formato della pagina linkata è descritto nel file MNU-formato-gruppo-utente.inc presente nella directory destinata alle pagine di menù (impostabile nel file di configurazione).

La ricerca del file prevede un meccanismo di risalita così definito:
1- MNU-formato-gruppo-utente.inc
2- MNU-formato-gruppo.inc
3- MNU-formato.inc
! Sintassi\\
<%WTX_LNKMNU WTX_PAGFMT="..." WTX_GRUPPO="..." WTX_UTENTE="..."%>
- PAGFMT: valore obbligatorio che identifica il tipo di menù richiesto
- GRUPPO : valore opzionale indicante il gruppo associato all'utente,
reperibile dinamicamente tramite l'utilizzo del Tag <%#WTX_GRUPPO#%>
- UTENTE : valore opzionale indicante l'identificativo dell'utente,
reperibile dinamicamente tramite l'utilizzo del Tag <%#WTX_UTENTE#%>

! Output\\
Ritorna il link alla pagina di menù specificato da FORMATO,GRUPPO,UTENTE.

! Struttura\\
Struttura modello standard (http://test.smea.it/pagineTest/wtx_lnkmnu.inc?&wtx_rsltag=&wtx_strtag=)

! Esempi\\
Visualizzazione pagine menù
WTX_PAGFMT=001 (http://test.smea.it/servlet/ServletTag?WTX_WBP=WTX_LNKMNU&WTX_PAGFMT=001)

!! WTX_LNKOBJSLC\\
! Descrizione\\
Tag per la visualizzazione del link a una pagina di lista di selezione per un oggetto Sme.up.

! Sintassi\\
La funzione eredita tutte le proprietà del tag WTX_LNKOBJLST, con l'aggiunta di due nuovi parametri, legati al meccanismo di selezione:
* RESPONSEVAR: Indica la variabile che riceverà il valore del codice selezionato\\
* RETCODE : marcatore della pagina a cui ritornare il valore selezionato. Il corpo della lista di selezione deve definire il meccanismo di ritorno attraverso l'uso del tag WTX_LNKMRK.\\

! Struttura\\
Struttura modello standard (http://test.smea.it/pagineTest/wtx_lnkobjslc.inc?&wtx_rsltag=&wtx_strtag=)

! Esempi\\
Link alla PAG 001 di selezione di oggetti di categoria AR-ART, la risposta passata con marcatore PAG 001 nella variabile RISPOSTA
WTX_TIPO=AR, WTX_PARAMETRO=ART, WTX_PAGFMT=001, WTX_RESPONSEVAR=RISPOSTA, WTX_RETCODE=PAG001 (http://test.smea.it/servlet/ServletTag?WTX_WBP=WTX_LNKOBJSLC&WTX_TIPO=AR&WTX_PARAMETRO=ART&WTX_PAGFMT=001&WTX_RETCODE=PAG001&WTX_RESPONSEVAR=risposta)

!! WTX_LNKOAVLST\\
! Descrizione\\
Tag per la visualizzazione del link a una pagina di lista di un attributo Sme.up.
Il formato della pagina linkata è descritto nel file LST-formato.inc presente nella directory destinata alle pagine di lista (impostabile nel file di configurazione).

! Sintassi\\
<%WTX_LNKOAVLST WTX_TIPO="..." WTX_PARAMETRO="..." WTX_CODICE="..."
WTX_CODATTRIBUTO="..." WTX_PAGFMT="..." WTX_METODO="..." %>

* TIPO, PARAMETRO, CODICE, CODATTRIBUTO: valori obbligatori che definiscono l'attributo Sme.up cui è riferito il link\\
* PAGFMT: tipo di vista associata all'oggetto\\
* METODO: Metodo di visualizzazione attributi. I valori possibili per questo parametro sono:\\
** TUTTI: Mostra tutti i valori dell'attributo specificato\\
** USATI: Mostra solo i valori dell'attributo utilizzati da almeno un oggetto della categoria specificata\\
** POSSIBILI: Mostra solo i valori possibili per l'attributo, in funzione della categoria.\\

! Output\\
Ritorna il link alla pagina di lista per l'attributo specificato da TIPO, PARAMETRO,CODICE.CODATTRIBUTO nel PAGFMT richiesto.

! Struttura\\
Struttura modello standard (http://test.smea.it/pagineTest/wtx_lnkoavlst.inc?&wtx_rsltag=&wtx_strtag=)

! Esempi\\
Lista Articoli generici - 1 elemento per riga - pulsanti di paginazione
WTX_TIPO=CN, WTX_PARAMETRO=CLI, WTX_CODICE=000001, WTX_CODATTRIBUTO=P/CL/A80, WTX_PAGFMT=007 (http://test.smea.it/servlet/ServletTag?WTX_WBP=WTX_DSPOAVLST&WTX_TIPO=CN&WTX_PARAMETRO=CLI&WTX_CELLFMT=corpo001.txt&WTX_CODICE=000001&WTX_CODATTRIBUTO=P/CL/A80)

!! WTX_LNKOAVSLC\\
! Descrizione\\
Tag per la visualizzazione del link ad una pagina di selezione del valore di un attributo Sme.up.

! Sintassi\\
La funzione eredita tutte le caratteristiche del tag WTX_LNKOAVLST con l'aggiunta di due nuovi parametri per la gestione della selezione:
* RESPONSEVAR: Indica la variabile che riceverà il valore del codice selezionato\\
* RETCODE: riceve il marcatore della pagina a cui deve essere ritornato il valore selezionato (usando la variabile specificata nel parametro RESPONSEVAR)\\

! Struttura\\
Struttura modello standard (http://test.smea.it/pagineTest/wtx_lnkoavslc.inc?&wtx_rsltag=&wtx_strtag=)

! Esempi\\
Selezione da lista di articoli generici
WTX_TIPO=CN, WTX_PARAMETRO=CLI, WTX_CODICE=000001, WTX_CODATTRIBUTO=P/CL/A80, WTX_PAGFMT=007, WTX_RETCODE=001, WTX_RESPONSEVAR=RISPOSTA (http://test.smea.it/servlet/ServletTag?WTX_WBP=WTX_LNKOAVSLC&WTX_TIPO=CN&WTX_PARAMETRO=CLI&WTX_CODICE=000001&WTX_CODATTRIBUTO=P/CL/A80&WTX_PAGFMT=007&WTX_RETCODE=001&WTX_RESPONSEVAR=risposta)

!! WTX_LNKFLT\\
! Descrizione\\
Tag per la visualizzazione del link ad una pagina di Filtro.
Il formato della pagina linkata è descritto nel file FLT-formato.inc presente nella directory destinata alle pagine di filtro (impostabile nel file di configurazione).

! Sintassi\\
<%WTX_LNKFLT WTX_PAGFMT="..." WTX_TIPO="..." WTX_PARAMETRO="..." WTX_ FORMFILTRO[n] WTX_CODEMARK="..." WTX_CODFILTRO="..."%>

* TIPO,PARAMETRO: valori obbligatori che identificano l'oggetto Sme.up\\
* PAGFMT: valore obbligatorio che identifica il tipo di filtro richiesto\\
* FORMFILTRO[1-5]: Forma di rappresentazione per i valori di filtro. I valori possibili sono:\\
** TXT: Campo di input\\
** TXTRIC: Campo di input + ricerca\\
** COMBOBOX: ComboBox\\
** RADIO: RadioButton\\
** CODEMARK: Marcatore di pagina da filtrare\\

__N.B.__: Se nei campi FORMFILTRO non viene specificato un preciso formato di campo, valgono le seguenti regole:
1 Per oggetti non tipizzati viene assunto per default il formato TXTRIC.
2 Per oggetti tipizzati viene assunto per default il formato TXTRIC tranne per i due casi seguenti.
3 Per oggetti di tipo TA viene assunto per default il formato COMBOBOX.
4 Per oggetti di tipo V2 viene assunto per default il formato RADIO

! Output\\
Ritorna il link a una pagina di filtro.

! Struttura\\
Struttura modello standard (http://test.smea.it/pagineTest/wtx_lnkflt.inc?&wtx_rsltag=&wtx_strtag=)

! Esempi\\
Visualizzazione pag. 001 di filtro per categoria oggetti
WTX_TIPO=AR, WTX_PARAMETRO=ART, WTX_PAGFMT=001, WTX_CODFILTRO=ARACC.F01, WTX_RETCODE=001 (http://test.smea.it/servlet/ServletTag?WTX_WBP=WTX_LNKFLT&WTX_TIPO=AR&WTX_PARAMETRO=ART&WTX_PAGFMT=001&WTX_CODFILTRO=ARACC.F01&WTX_RETCODE=001)

!!! Dettaglio Tag per la costruzione del contenuto delle pagine dinamiche\\

!! WTX_DSPOBJLST\\
! Descrizione\\
Tag per la visualizzazione del corpo di una lista di oggetti Sme.up sotto forma di tabella HTML.
Il formato HTML della singola cella è descritto nel file specificato dal parametro FILEFMT e reperibile nella directory dedicata ai formati (impostabile nel file di configurazione).

! Sintassi\\
<%WTX_DSPOBJLST WTX_TIPO="..." WTX_PARAMETRO="..." WTX_CELLFMT="..." WTX_ELROW="..." WTX_ NROGG="..." WTX_PAGYN="..." WTX_POSPAG="..." WTX_METODO="..." WTX_CODFILTRO="..."%>

* TIPO,PARAMETRO: valori obbligatori che identificano l'oggetto Sme.up da listare\\
* CELLFMT : valore obbligatorio indicante il file da cui caricare il formato HTML della singola cella.\\
* ELROW : valore opzionale indicante il numero di celle per riga, per default = 1\\
* NROGG : valore opzionale indicante il numero di celle per pagina. default = 20, *ALL per listare tutti gli oggetti.\\
* PAGYN : valore opzionale per visualizzare i pulsanti di paginazione. default = N (N = No, Y = Yes)\\
* POSPAG : valore opzionale per il posizionamentodei pulsanti di paginazione. default = E (A = Alto, B = Basso, E = Entrambi)\\
* METODO: Metodo di accesso al file. I valori possibili sono:\\
** CCA - Codice/Compreso/Avanti\\
** CCI - Codice/Compreso/Indietro\\
** CEA - Codice/Escluso/Avanti\\
** CEI - Codice/Escluso/Indietro\\
** DCA - Descrizione/Compreso/Avanti\\
** DCI - Descrizione/Compreso/Indietro\\
** DEA - Descrizione/Escluso/Avanti\\
** DEI - Descrizione/Escluso/Indietro\\
* FILTRO[1-5]: Campi per la specificazione dei valore da assegnare al filtro associato alla categoria di oggetti listati. La definizione dei campi filtro è specificata nella tabella JAA.\\

! Output\\
Mostra la lista di oggetti di tipo TIPO-PARAMETRO, con ELROW elementi per ognuna delle NROGG/ELROW righe. Se richiesto, mostra automaticamente i pulsanti per la paginazione nella posizione specificata.

! Struttura\\
Struttura modello standard (http://test.smea.it/pagineTest/wtx_dspobjlst.inc?&wtx_rsltag=&wtx_strtag=)

! Esempi\\
Lista clienti paginata - singolo elemento con formato "corpo001.txt"- 10 elementi per pagina - pulsanti di paginazione sia in testa che in fondo alla lista.
WTX_TIPO=CN, WTX_PARAMETRO=CLI, WTX_CELLFMT=corpo001.txt, WTX_ELROW=1, WTX_NROGG=10, WTX_PAGYN=Y, WTX_POSPAG=E (http://test.smea.it/servlet/ServletTag?WTX_WBP=WTX_DSPOBJLST&WTX_TIPO=CN&WTX_PARAMETRO=CLI&WTX_CELLFMT=corpo001.txt&WTX_ELROW=1&WTX_NROGG=10&WTX_PAGYN=Y&WTX_POSPAG=E)

!! WTX_DSPOBJSLC\\
! Descrizione\\
Tag per la visualizzazione di una lista di selezione di oggetti Sme.up sotto forma di lista HTML. Il formato HTML della singola cella è descritto nel file specificato dal parametro CELLFMT e reperibile nella directory dedicata ai formati (impostabile nel file di configurazione). L'oggetto selezionato viene passato alla pagina marcata con il marcatore specificato nel parametro WTX_RETCODE associandolo alla variabile il cui nome è specificato nel parametro WTX_RESPONSEVAR.

! Sintassi\\
<%WTX_DSPOBJSLC WTX_TIPO="..." WTX_PARAMETRO="..." WTX_CELLFMT="..." WTX_ELROW="..." WTX_ NROGG="..." WTX_PAGYN="..." WTX_POSPAG="..." WTX_METODO="..." WTX_CODFILTRO="..." WTX_FILTROX="..." WTX_RETCODE="..." WTX_RESPONSEVAR="..."%>

Legenda (si omette per semplicità il prefisso WTX_):
* TIPO,PARAMETRO: valori obbligatori che identificano l'oggetto Sme.up da listare\\
* CELLFMT : valore obbligatorio indicante il file da cui caricare il formato HTML della singola cella.\\
* ELROW : valore opzionale indicante il numero di celle per riga, per default = 1\\
* NROGG : valore opzionale indicante il numero di celle per pagina. default = 20, *ALL per listare tutti gli oggetti.\\
* PAGYN : valore opzionale per visualizzare i pulsanti di paginazione. default = N (N = No, Y = Yes)\\
* POSPAG : valore opzionale per il posizionamentodei pulsanti di paginazione. default = E (A = Alto, B = Basso, E = Entrambi)\\
* METODO: Metodo di accesso al file. I valori possibili sono:\\
** CCA: Codice/Compreso/Avanti\\
** CCI: Codice/Compreso/Indietro\\
** CEA: Codice/Escluso/Avanti\\
** CEI: Codice/Escluso/Indietro\\
** DCA: Descrizione/Compreso/Avanti\\
** DCI: Descrizione/Compreso/Indietro\\
** DEA: Descrizione/Escluso/Avanti\\
** DEI: Descrizione/Escluso/Indietro\\
* CODFILTRO: codice del filtro da applicare alla lista di selezione, come da tabella JAA.\\
* FILTRO[1-50]: Campi per la specificazione dei valore da assegnare al filtro associato alla categoria di oggetti listati. La definizione dei campi filtro è specificata nella tabella JAA. Il numero massimo dei campi di filtro è 50.\\
* RETCODE: codice della pagina a cui ritornare la selezione. Il codice è quello usato per marcare la pagina.\\
* RESPONSEVAR: nome variabile in cui salvare la selezione\\

! Output\\
Mostra la lista di selezione di oggetti di tipo TIPO-PARAMETRO, con ELROW elementi per ognuna delle NROGG/ELROW righe. Se richiesto mostra automaticamente i pulsanti per la paginazione, inseriti nella posizione specificata.

! Struttura\\
Struttura modello standard (http://test.smea.it/pagineTest/wtx_dspobjslc.inc?wtx_rsltag=&wtx_strtag=)

! Esempi\\
Selezione di un articolo di tipo AR-ART, con paginazione da 10 elementi per pagina e ritorno della selezione alla pagina marcata con RETURN all'interno della variabile RISPOSTA.
Pulsanti di paginazione sia in testa che in fondo alla lista.
<%WTX_DSPOBJSLC WTX_TIPO="AR" WTX_PARAMETRO="ART" WTX_CELLFMT="DSPOBJSLC_F01.txt" WTX_NROGG="10" WTX_PAGYN="Y" WTX_POSPAG="E" WTX_RETCODE="RETURN" WTX_RESPONSEVAR="RISPOSTA"%> (http://test.smea.it/servlet/ServletTag?WTX_WBP=WTX_DSPOBJSLC&WTX_TIPO&WTX_PARAMETRO=ART&WTX_CELLFMT=DSPOBJSLC_F01.txt&WTX_NROGG=10&WTX_PAGYN=Y&WTX_POSPAG=E&WTX_RETCODE=RETURN&WTX_RESPONSEVAR=RISPOSTA)

!! WTX_DSPOBJCMB\\
! Descrizione\\
Tag per la visualizzazione di un Combobox i cui elementi sono una lista di oggetti Sme.Up di tipo predefinito.

! Sintassi\\
<%WTX_DSPOBJCMB WTX_TIPO="..." WTX_PARAMETRO="..." WTX_NOME="..." WTX_ONCHANGE="..." WTX_FORMATO="..."  WTX_RETCODE="..." WTX_CELLFMT="..." WTX_CODFILTRO="..." WTX_FILTRO1="..." WTX_FILTRO2="..."%>
* TIPO, PARAMETRO: valori obbligatori che definiscono il tipo degli oggetti Sme.up che si desidera visualizzare nel Combobox.\\
* NOME : Nome da assegnare all'oggetto Combobox all'interno del form HTML.\\
* ONCHANGE (facoltativo): nome della funzione Javascript da chiamare quando si seleziona un elemento del combo (vedi standard HTML per maggiori dettagli).\\
* RETCODE (facoltativo): marcatore alla pagina a cui passare la selezione del Combox.\\
* FORMATO (facoltativo) : Contenuto corpo Radio per FILEFMT = *blanks\\
** C = Codice\\
** D = Descrizione\\
** CD = Codice + Descrizione\\
** DC = Descrizione + Codice\\
* FILTRO1 - FILTRO50 (facoltativi): campi di immissione delle condizioni di filtro.\\
* CELLFMT (facoltativo): File da cui caricare eventualmente il formato HTML della singola cella.\\

! Output\\
Ritorna un Combobox contenente la lista degli oggetti Sme.up di tipologia definita da Tipo/Parametro.

! Struttura\\
Struttura modello standard (http://test.smea.it/pagineTest/wtx_dspobjcmb.inc?&wtx_rsltag=&wtx_strtag=)

! Descrizione\\
Tag che consente la variazione on the fly della macchina AS/400 di riferimento. Alla partenza Web.up instaura un collegamento con la macchina AS/400 specificata nel file di configurazione e con questo Tag è possibile ridirigere il collegamento verso una nuova macchina o cambiare il profilo di collegamento sulla macchina precedentemente usata.

! Sintassi\\
<%WTX_CHGSRV WTX_SYSTEM="..." WTX_USER="..." WTX_PASSWORD="..." WTX_LIB="..." WTX_PGM="..." %>

* SYSTEM: indirizzo TCP/IP della macchina AS/400 a cui collegarsi. Accetta sia il formato numerico che quello mnemorico.\\
* USER: utente da usare per il collegamento con l'AS/400.\\
* PASSWORD: password dell'utente per il collegamento con l'AS/400.\\
* LIB: (facoltativo): libreria che contiene il programma server su AS/400. Per default vale *LIBL.\\
* PGM (facoltativo): nome del programma server su AS/400. Per default JAJAC0.\\

! Output\\
Il Tag non prevede un output grafico, ma torna solo un breve mesaggio che conferma o meno la corretta esecuzione del comando richiesto.

! Struttura\\
Struttura modello standard (http://test.smea.it/pagineTest/wtx_dspobjcmb.inc?&wtx_rsltag=&wtx_strtag=)

! Esempi\\
Visualizza radio per selezione oggetto di tipo tabella/pagamenti con vista per codice+descrizione: WTX_TIPO=TA, WTX_PARAMETRO=PAG, WTX_NOME=RADIONAME, WTX_FORMATO=CD, WTX_ELROW=2

!! WTX_DSPOAVRAD\\
! Descrizione\\
Tag per la visualizzazione di un Radio i cui elementi sono i valori di un attributo.

! Sintassi\\
<%WTX_DSPOAVRAD WTX_TIPO="..." WTX_PARAMETRO="..." WTX_CODICE=".."WTX_CODATTRIBUTO="..." WTX_NOME="..." WTX_METODO="..." WTX_FORMATO="..."
WTX_CELLFMT="..." WTX_ELROW="..."%>

* TIPO, PARAMETRO,CODICE,CODATTRIBUTO: valori obbligatori che definiscono l'attributoSme.up che si desidera visualizzare nel Radio.\\
* NOME : Valore facoltativo da attribuire al Radio, e quindi al campo di input all'interno del form.\\
* METODO:\\
** TUTTI = Tutti i valori dell'attributo\\
** POSSIBILI = Tutti i valori possibili dell'attributo\\
** UTILIZZATI= Tutti i valori utilizzati per l'attributo\\
* FORMATO (facoltativo) : Contenuto corpo Radio\\
** C = Codice\\
** D = Descrizione\\
** CD = Codice + Descrizione\\
** DC = Descrizione + Codice\\
* CELLFMT (facoltativo): File da cui caricare eventualmente il formato HTML della singola cella.\\
*ELROW (facoltativo): numero di elementi per riga. Per default è pari a 1.\\

! Output\\
Ritorna un Radio contenente i valori dell'attributo Sme.up.

! Struttura\\
Struttura modello standard (http://test.smea.it/pagineTest/wtx_dspoavrad.inc?wtx_rsltag=&wtx_strtag=)

! Esempi\\
Visualizza i valori dell'attributo P/CL/A80 del cliente in formato radio
WTX_TIPO=CN, WTX_PARAMETRO=CLI, WTX_CODICE=000001, WTX_CODATTRIBUTO=P/CL/A80, WTX_NOME=COMBONAME, WTX_FORMATO=CD, WTX_METODO=TUTTI (http://test.smea.it/servlet/ServletTag?WTX_WBP=WTX_DSPOAVRAD&WTX_TIPO=CN&WTX_PARAMETRO=CLI&WTX_NOME=RADIONAME&WTX_CODICE=000001&WTX_METODO=TUTTTI&WTX_FORMATO=CD&WTX_CODATTRIBUTO=P/CL/A80)

!! WTX_DSPOBJCHK\\
! Descrizione\\
Tag per la visualizzazione di un Checkbox i cui elementi sono i valori di un oggetto Sme.up

! Sintassi\\
<%WTX_DSPOBJCHK WTX_TIPO="..." WTX_PARAMETRO="..." WTX_CODICE=".." WTX_NOME="..." WTX_FORMATO="..." WTX_CELLFMT="..." WTX_CODFILTRO="..." WTX_ELROW="..."%>

* TIPO, PARAMETRO,CODICE: valori obbligatori che definiscono l'oggetto Sme.up che si desidera visualizzare nel Radio\\
* NOME : Valore facoltativo da attribuire al Checkbox, e quindi al campo di input all'interno del form.\\
* FORMATO (facoltativo) : Contenuto corpo Checkbox per FILEFMT = *blanks\\
** C = Codice\\
** D = Descrizione\\
** CD = Codice + Descrizione\\
** DC = Descrizione + Codice\\
* CELLFMT (facoltativo): File da cui caricare eventualmente il formato HTML della singola cella.\\
* ELROW (facoltativo): numero di elementi per riga. Per default è pari a 1.\\

! Output\\
Ritorna un Radio contenente gli oggetti Sme.up da listare definiti da Tipo/Parametro.

! Struttura\\
Struttura modello standard (http://test.smea.it/pagineTest/wtx_dspobjchk.inc?&wtx_rsltag=&wtx_strtag=)

! Esempi\\
Visualizza radio per selezione oggetto di tipo tabella/pagamenti con vista per codice+descrizione
WTX_TIPO=TA, WTX_PARAMETRO=PAG, WTX_NOME=RADIONAME, WTX_FORMATO=CD, WTX_ELROW=2

!! WTX_DSPOAVCHK\\
! Descrizione\\
Tag per la visualizzazione di un Checkbox i cui elementi sono i valori multipli associati a un attributo di un oggetto Sme.up.

! Sintassi\\
<%WTX_DSPOAVCHK WTX_TIPO="..." WTX_PARAMETRO="..." WTX_CODICE=".." WTX_CODATTRIBUTO="..." WTX_NOME="..." WTX_METODO="..." WTX_FORMATO="..." WTX_CELLFMT="..." WTX_ELROW="..."%>

* TIPO, PARAMETRO,CODICE,CODATTRIBUTO: valori obbligatori che definiscono l'attributo Sme.up che si desidera visualizzare nel Checkbox\\
* NOME : Valore facoltativo da attribuire al Checkbox, e quindi al campo di input all'interno del form.\\
* METODO:\\
** TUTTI = Tutti i valori dell'attributo\\
** POSSIBILI = Tutti i valori possibili dell'attributo\\
** UTILIZZATI= Tutti i valori utilizzati per l'attributo\\
* FORMATO (facoltativo) : Contenuto corpo Radio\\
** C = Codice\\
** D = Descrizione\\
** CD = Codice + Descrizione\\
** DC = Descrizione + Codice\\
* CELLFMT (facoltativo): File da cui caricare eventualmente il formato HTML della singola cella.\\
* ELROW (facoltativo): numero di elementi per riga. Per default è pari a 1.\\

! Output\\
Ritorna un Checkbox contenente i valori multipli associati ad un attributo di un oggetto Sme.up

! Struttura\\
Struttura modello standard (http://test.smea.it/pagineTest/wtx_dspoavchk.inc?&wtx_rsltag=&wtx_strtag=)

! Esempi\\
Visualizza i valori dell'attributo P/CL/A80 del cliente in formato radio
WTX_TIPO=CN, WTX_PARAMETRO=CLI, WTX_CODICE=000001, WTX_CODATTRIBUTO=P/CL/A80, WTX_NOME=COMBONAME, WTX_FORMATO=CD, WTX_METODO=TUTTI

!! WTX_DSPOAVLST\\
! Descrizione\\
Tag per la visualizzazione della lista di valori assunti da un attributo specificato per una dato oggetto. Consente la visualizzazione in tabella di valori multipli con un formato HTML per la singola cella, definito nel file esterno specificato dal parametro FILEFMT. Il file di formato deve sempre risiedere nella directory dedicata ai formati (impostabile come parametro nel file di configurazione di Web.up)

! Sintassi\\
<%WTX_DSPOAVLST WTX_TIPO="..." WTX_PARAMETRO="..." WTX_CODICE="..." WTX_CODATTRIBUTO="..." WTX_CELLFMT="..." WTX_ELROW="..."  WTX_NROGG="..." WTX_METODO="..."%>

* TIPO,PARAMETRO: valori obbligatori che identificano la classe di oggetti Sme.up da listare\\
* CODICE: codice dell'oggetto. Serve solo nel caso si leggano i valori assunti da un attributo per un oggetto specifico.\\
* CODATTRIBUTO: codice dell'attributo di cui si vogliono visualizzare i valori.\\
* CELLFMT : valore obbligatorio indicante il file da cui caricare il formato HTML della singola cella della tabella risultante. Il file specificato deve risiedere nella directory specificata nel file di configurazione.\\
* ELROW : valore opzionale indicante il numero di celle per riga (default = 1).\\
* METODO: metodo di lettura dei valori dell'attributo specificato.\\
** TUTTI = Tutti i valori dell'attributo dato l'oggetto specifico (deve essere indicato il codice dell'oggetto di riferimento)\\
** POSSIBILI = Tutti i valori possibili dell'attributo data la categoria oggetto.\\
** UTILIZZATI = Tutti i valori utilizzati per questo attributo da almeno un oggetto della categoria specificata\\

! Output\\
Una tabella HTML che mostra i valori associati all'attributo specificato nei parametri del Tag.

! Struttura\\
Struttura modello standard (http://test.smea.it/pagineTest/wtx_dspoavlst.inc?&wtx_rsltag=&wtx_strtag=)

! Esempi\\
Lista valori attributo P/CL/A80 dell'oggetto cliente 000001
WTX_TIPO=CN, WTX_PARAMETRO=CLI, WTX_CODICE=000001, WTX_CODATTRIBUTO=P/CL/A80, WTX_CELLFMT=corpo001.txt (http://test.smea.it/servlet/ServletTag?WTX_WBP=WTX_DSPOAVLST&WTX_TIPO=CN&WTX_PARAMETRO=CLI&WTX_CELLFMT=corpo001.txt&WTX_CODICE=000001&WTX_CODATTRIBUTO=P/CL/A80)

!! WTX_DSPOAVSLC\\
! Descrizione\\
Tag per la visualizzazione di una lista di selezione di valori di un attributo di un oggetto che prevede valori multipli.Il formato HTML della singola cella è descritto nel file specificato dal parametro CELLFMT e reperibile nella directory dedicata ai formati (impostabile nel file di configurazione). L'oggetto selezionato viene passato alla pagina marcata con il marcatore specificato nel parametro WTX_RETCODE associandolo alla variabile il cui nome è specificato nel parametro WTX_RESPONSEVAR

! Sintassi\\
<%WTX_DSPOAVSLC WTX_TIPO="..." WTX_PARAMETRO="..." WTX_CODICE="..."  WTX_CODATTRIBUTO= "..." WTX_CELLFMT="..." WTX_ELROW="..." WTX_ NROGG="..." WTX_PAGYN="..." WTX_POSPAG="..." WTX_METODO="..." WTX_CODFILTRO="..." WTX_FILTROX="..." WTX_RETCODE="..." WTX_RESPONSEVAR="..."%>

Legenda (si omette per semplicità il prefisso WTX_):
* TIPO,PARAMETRO,CODICE: valori obbligatori che identificano l'oggetto Sme.up di cui leggere i valori attributo.\\
* CODATTRIBUTO: codice dell'attributo a valori multipli a cui si riferisce la selezione.\\
* CELLFMT: valore obbligatorio indicante il file da cui caricare il formato HTML della singola cella.\\
* ELROW: valore opzionale indicante il numero di celle per riga, per default = 1\\
* NROGG: valore opzionale indicante il numero di celle per pagina. default = 20, *ALL per listare tutti gli oggetti.\\
* PAGYN: valore opzionale per visualizzare i pulsanti di paginazione. default = N (N = No, Y = Yes)\\
* POSPAG: valore opzionale per il posizionamentodei pulsanti di paginazione. default = E (A = Alto, B = Basso, E = Entrambi)\\
* METODO: Metodo di accesso al file. I valori possibili sono:\\
** CCA: Codice/Compreso/Avanti\\
** CCI: Codice/Compreso/Indietro\\
** CEA: Codice/Escluso/Avanti\\
** CEI: Codice/Escluso/Indietro\\
** DCA: Descrizione/Compreso/Avanti\\
** DCI: Descrizione/Compreso/Indietro\\
** DEA: Descrizione/Escluso/Avanti\\
** DEI: Descrizione/Escluso/Indietro\\
* CODFILTRO: codice del filtro da applicare alla lista di selezione, come da tabella JAA.\\
* FILTRO[1-50]: Campi per la specificazione dei valore da assegnare al filtro associato alla categoria di oggetti listati. La definizione dei campi filtro è specificata nella tabella JAA. Il numero massimo dei campi di filtro è 50.\\
* RETCODE: codice della pagina a cui ritornare la selezione. Il codice è quello usato per marcare la pagina.\\
* RESPONSEVAR: nome variabile in cui salvare la selezione\\

! Output\\
Mostra la lista dei valori dell'attributo CODATTRIBUTO dell'oggetto specificato e consente la selezione di uno dei valori proposti. Se richiesto mostra automaticamente i pulsanti per la paginazione, inseriti nella posizione specificata.

! Struttura\\
Struttura modello standard (http://test.smea.it/pagineTest/wtx_dspoavslc.inc?wtx_rsltag=&wtx_strtag=)

! Esempi\\
Selezione di uno dei valori dell'attributo P/AR/A07 dell'oggetto AR-ART-A02; ritorna la selezione alla pagina marcata con RETURN all'interno della variabile RISPOSTA.
<%WTX_DSPOAVSLC WTX_TIPO="AR" WTX_PARAMETRO="ART" WTX_CODICE="A02" WTX_CODATTRIBUTO=P/AR/A07 WTX_CELLFMT="DSPOBJSLC_F01.txt"  WTX_RETCODE="RETURN" WTX_RESPONSEVAR="RISPOSTA"%> (http://test.smea.it/servlet/ServletTag?WTX_WBP=WTX_DSPOAVSLC&WTX_TIPO=AR&WTX_PARAMETRO=ART&WTX_CODICE=A02&WTX_CODATTRIBUTO=P/AR/A07&WTX_RETCODE=RETURN&WTX_RESPONSEVAR=RISPOSTA&WTX_CELLFMT=DSPOBJSLC_F01.txt)

!! WTX_DSPOAVCMB\\
! Descrizione\\
Tag per la visualizzazione di una comboBox i cui elementi sono una lista di attributi di un oggetto Sme.up

! Sintassi\\
<%WTX_DSPOAVCMB WTX_TIPO="..." WTX_PARAMETRO="..." WTX_CODICE="..." WTX_CODATTRIBUTO="..." WTX_NOME="..." WTX_ONCHANGE="..." WTX_METODO="..."
WTX_FORMATO="..." %>
* TIPO, PARAMETRO, CODICE, CODATTRIBUTO: valori obbligatori che definiscono l'attributo\\
* NOME: Valore facoltativo da attribuire all comboBox, e quindi al campo di input all'interno del form.\\
* ONCHANGE: Valore indicante il JavaScript ascoltatore dell'evento.\\
* METODO:\\
** TUTTI = Tutti i valori dell'attributo\\
** POSSIBILI = Tutti i valori possibili dell'attributo\\
** UTILIZZATI= Tutti i valori utilizzati per l'attributo\\
* FORMATO (facoltativo) : Contenuto corpo ComboBox\\
** C = Codice\\
** D = Descrizione\\
** CD = Codice + Descrizione\\
** DC = Descrizione + Codice\\

! Output\\
Ritorna una comboBox contenente i valori dell'attributo Sme.up.

! Struttura\\
Struttura modello standard (http://test.smea.it/pagineTest/wtx_dspoavcmb.inc?wtx_rsltag=&wtx_strtag=)

! Esempi\\
Visualizza i valori dell'attributo P/CL/A80 del cliente in formato combobox
WTX_TIPO=CN, WTX_PARAMETRO=CLI, WTX_CODICE=000001, WTX_CODATTRIBUTO=P/CL/A80, WTX_NOME=COMBONAME, WTX_FORMATO=CD, WTX_METODO=TUTTI (http://test.smea.it/servlet/ServletTag?WTX_WBP=WTX_DSPOAVCMB&WTX_TIPO=CN&WTX_PARAMETRO=CLI&WTX_NOME=RADIONAME&WTX_CODICE=000001&WTX_METODO=TUTTTI&WTX_FORMATO=CD&WTX_CODATTRIBUTO=P/CL/A80)

!! WTX_DSPOBJRAD\\
! Descrizione\\
Tag per la visualizzazione di un Radio i cui elementi sono i valori di un oggetto Sme.up.

! Sintassi\\
<%WTX_DSPOBJRAD WTX_TIPO="..." WTX_PARAMETRO="..." WTX_CODICE=".." WTX_NOME="..." WTX_FORMATO="..." WTX_CELLFMT="..." WTX_CODFILTRO="..." WTX_ELROW="..."%>

* TIPO, PARAMETRO, CODICE: valori obbligatori che definiscono l'oggetto Sme.up che si desidera visualizzare nel Radio\\
* NOME: Valore facoltativo da attribuire al Radio, e quindi al campo di input all'interno del form\\
* FORMATO (facoltativo): Contenuto corpo Radio per FILEFMT = *blanks\\
** C = Codice\\
** D = Descrizione\\
** CD = Codice + Descrizione\\
** DC = Descrizione + Codice\\
* CELLFMT (facoltativo): File da cui caricare eventualmente il formato HTML della singola cella.\\
* ELROW (facoltativo): numero di elementi per riga. Per default è pari a 1.\\

! Output\\
Ritorna un Radio contenente gli oggetti Sme.up da listare definiti da Tipo/Parametro.

! Struttura\\
Struttura modello standard (http://test.smea.it/pagineTest/wtx_dspobjrad.inc?wtx_rsltag=&wtx_strtag=)

! Esempi\\
Visualizza radio per selezione oggetto di tipo tabella/pagamenti con vista per codice+descrizione WTX_TIPO=TA, WTX_PARAMETRO=PAG, WTX_NOME=RADIONAME, WTX_FORMATO=CD, WTX_ELROW=2 (http://test.smea.it/servlet/ServletTag?WTX_WBP=WTX_DSPOBJRAD&WTX_TIPO=TA&WTX_PARAMETRO=PAG&WTX_NOME=RADIONAME&WTX_FORMATO=CD&WTX_ELROW=2)

!! WTX_DSPOAV\\
! Descrizione\\
Tag per la visualizzazione di informazioni associate ad un attributo di uno specifico oggetto Sme.up.

! Sintassi\\
<%WTX_DSPOAV WTX_TIPO="..." WTX_PARAMETRO="..." WTX_CODICE="..." WTX_CODICEATTRIBUTO="..." WTX_PAGFMT %>

* TIPO, PARAMETRO, CODICE: valori obbligatori che definiscono l'oggetto Sme.up a cui è riferito l'attributo.\\
* CODICEATTRIBUTO: il valore obbligatorio identifica l'attributo da visualizzare.\\
* FORMATO: tipo di informazione da visualizzare. Valori possibili:\\
** TIP: (valore di default) Torna il valore tipizzato e crea il link alla relativa pagina di dettaglio\\
** VALORE: Valore alfanumerico\\
** TIPDEC: Come TIP con in più un campo di decodifica del valore.\\
** VALDEC: Come VALORE con in più un campo di decodifica del valore.\\
** TIPPAR: Tipo e Parametro\\
** NUMERO: Valore Numerico\\
** DATAINI: Data Inizio validità\\
** DATAFINE: Data Fine Validità\\
** TIPO: Tipo\\
** PARAMETRO: Parametro\\
** CATEGORIA: Categoria\\
** LIVELLO: Livello\\
** DEVIAZIONE: Deviazione\\
** INTESTAZIONE: Intestazione\\
** DECODIFICA: Decodifica\\
* PAGFMT: Formato pagina di dettaglio. Serve solo per i formati TIP e TIPDEC\\

! Output\\
Valore attributo di un oggetto Sme.up,  secondo il formato richiesto.

! Struttura\\
Struttura modello standard (http://test.smea.it/pagineTest/wtx_dspoav.inc?&wtx_rsltag=&wtx_strtag=)

! Esempi\\
Lettura attributo P/CL/A80 del cliente 000001 WTX_TIPO=AR, WTX_PARAMETRO=ART, WTX_CODICE=A01, WTX_CODATTRIBUTO=I/02 (http://test.smea.it/servlet/ServletTag?WTX_WBP=WTX_DSPOAV&WTX_TIPO=AR&WTX_PARAMETRO=ART&WTX_CODICE=A01&WTX_CODATTRIBUTO=I/02&WTX_FORMATO=VALORE)

!! WTX_DSPNUM\\
! Descrizione\\
Tag per la visualizzazione di un numero associato ad uno specifico oggetto Sme.up.

! Sintassi\\
<%WTX_DSPNUM WTX_TIPO="..." WTX_PARAMETRO="..." WTX_CODICE="..." WTX_CODICENUMERO="..." WTX_FORMATO %>

* TIPO, PARAMETRO, CODICE: valori obbligatori che definiscono l'oggettoSme.up a cui è riferito il tag.\\
* CODICENUMERO : codice del numero da leggere.\\
* FORMATO: formato di visualizzazione del risultato. Puo assumere uno dei seguenti valori:\\
** VALORE: Valore alfanumerico del numero\\
** DECODIFICA: Decodifica del numero.\\

! Output\\
Valore o decodifica del numero associato all'oggetto specificato.

! Struttura\\
Struttura modello standard (http://test.smea.it/pagineTest/wtx_dspnum.inc?&wtx_rsltag=&wtx_strtag=)

!! WTX_DSPOBJLNK\\
! Descrizione\\
Visualizza un link alla pagina di dettaglio di un oggetto, unitamente a tre pulsanti per l'interrogazione delle funzioni, parametri e numeri associati all'oggetto stesso.

! Sintassi\\
<%WTX_DSPOBJLNK WTX_TIPO="..." WTX_PARAMETRO="..." WTX_CODICE="..." WTX_LINK="..."%>

* TIPO, PARAMETRO, CODICE: valori obbligatori che definiscono l'oggettoSme.up a cui è riferito il tag.\\
* LINK : Valore booleano (SI/NO). Se SI, viene mostrato il link alla pagina di dettaglio dell'oggetto.\\

! Output\\
Decodifica dell'oggetto con pulsanti per visualizzazione di funzioni-parametri-numeri. Se richiesto inserisce un link alla pagina di dettaglio.

! Struttura\\
Struttura modello standard (http://test.smea.it/pagineTest/wtx_dspobjlnk.inc?&wtx_rsltag=&wtx_strtag=)

!! WTX_DSPOBJDEC\\
! Descrizione\\
Tag per la visualizzazione della decodifica di un oggetto Sme.up.

! Sintassi\\
<%WTX_DSPOBJDEC WTX_ TIPO="..." WTX_PARAMETRO="..." WTX_CODICE="..."%>

* TIPO, PARAMETRO, CODICE: valori obbligatori che definiscono l'oggettoSme.up che si desidera decodificare.\\

! Output\\
Ritorna la descrizione di un oggetto Sme.up.

! Struttura\\
Struttura modello standard (http://test.smea.it/pagineTest/wtx_dspobjdec.inc?&wtx_rsltag=&wtx_strtag=)

! Esempi\\
Decodifica oggetto A01
WTX_TIPO=AR, WTX_PARAMETRO=ART, WTX_CODICE=A01 (http://test.smea.it/servlet/ServletTag?WTX_WBP=WTX_DSPOBJDEC&WTX_TIPO=AR&WTX_PARAMETRO=ART&WTX_CODICE=A01)

!! WTX_DSPFLT\\
! Descrizione\\
Tag per la visualizzazione di una pagina di Filtro.

! Sintassi\\
<%WTX_DSPFLT WTX_TIPO="..." WTX_PARAMETRO="..." WTX_CODFILTRO="..." WTX_ FORMFILTRO[n] WTX_CODEMARK="..." %>

* TIPO,PARAMETRO: valori obbligatori che identificano l'oggetto Sme.up\\
* FORMFILTRO[1-5]: Forma di rappresentazione per i valori di filtro\\
** TXT: Campo di input\\
** TXTRIC: Campo di input + ricerca\\
** COMBOBOX: ComboBox\\
** RADIO: RadioButton\\
** CODEMARK: Marcatore di pagina da filtrare\\

Per oggetti TA, se non specificato, viene assunto COMBOBOX
Per oggetti V2, se non specificato, viene assunto RADIO
Per altri oggetti, se non specificato, viene assunto TXTRIC purchè tipizzati, altrimenti TXT

! Output\\
Ritorna una pagina di filtro

! Struttura\\
Struttura modello standard (http://test.smea.it/pagineTest/wtx_dspflt.inc?&wtx_rsltag=&wtx_strtag=)

! Esempi\\
Descrizione visualizzazione dell'oggetto filtro per la categoria AR-ART
WTX_TIPO=AR, WTX_PARAMETRO=ART, WTX_FORMFILTRO1=TXT, WTX_FORMFILTRO2=TXTRIC, WTX_FORMFILTRO3=COMBOBOX, WTX_CODEMARK=PAGRITORNO WTX_CODFILTRO=ARACC.F01 WTX_RETCODE=001 (http://test.smea.it/servlet/ServletTag?WTX_WBP=WTX_DSPFLT&WTX_TIPO=AR&WTX_PARAMETRO=ART&WTX_CODFILTRO=ARACC.F01&WTX_RETCODE=001&WTX_FORMFILTRO1=TXT&WTX_FORMFILTRO2=TXTRIC&WTX_FORMFILTRO3=COMBOBOX&WTX_CODEMARK=PAGRITORNO)

!! WTX_DSPOBJICN\\
! Descrizione\\
Tag per la visualizzazione di una icona di un oggetto Sme.up.
Le icone devono risiedere nella directory loro destinata (impostabile nel file di configurazione).

La ricerca dell'icona avviene tramite una risalita così definita:
1- tipo+parametro+codice+.formato
2- tipo+parametro+.formato
3- tipo+.formato
4- Default da file di configurazione
Formato di defaut = gif

! Sintassi\\
<%WTX_DSPOBJICN WTX_TIPO="..." WTX_PARAMETRO="..." WTX_CODICE="..." WTX_ FILEEXT="..."%>

* TIPO, PARAMETRO, CODICE: valori che definiscono l'oggetto Sme.up di cui visualizzare l'icona.\\
* FILEEXT : estensione del file associato all'icona\\

! Output\\
Ritorna il path dell' icona associata all'oggetto, nella forma directory/directory/nomeicona.formato

! Struttura\\
Struttura modello standard (http://test.smea.it/pagineTest/wtx_dspobjicn.inc?&wtx_rsltag=&wtx_strtag=)

! Esempi\\
Link di un icona associato all'oggetto AR/ART/A01, nel formato predefinito .GIF
WTX_TIPO=AR, WTX_PARAMETRO=ART, WTX_CODICE=A01 (http://test.smea.it/servlet/ServletTag?WTX_WBP=WTX_DSPOBJICN&WTX_TIPO=AR&WTX_PARAMETRO=ART&WTX_CODICE=A01)

!! WTX_DSPOBJIMG\\
! Descrizione\\
Tag per la visualizzazione di una immagine di un oggetto Sme.up.
Le immagini devono risiedere nella directory destinata alle immagini degli oggetti (impostabile nel file di configurazione).

La ricerca dell'immagine avviene tramite una risalita così definita:
1- tipo+parametro+codice+_size.formato
2- tipo+parametro+_size.formato
3- tipo+_size.formato
4- Default+size.formato
5- Default2.formato
6- Default2.gif
con Default da file di configurazione

! Sintassi\\
<%WTX_DSPOBJIMG WTX_TIPO="..." WTX_PARAMETRO="..." WTX_CODICE="..." WTX_ INDEX="..."WTX_ FILEEXT="..."%>

* TIPO, PARAMETRO, CODICE: valori che definiscono l'oggettoSme.up di cui visualizzare l'immagine.\\
* SIZE: il valore, opzionale, identifica la grandezza dell'immagine default = 2 (1 = Piccola 2 = Media 3 = Grande)\\
* FORMATO: il valore, opzionale, identifica l'estensione del file di immagine (default = gif)\\

! Output\\
Ritorna il path della immagine associata all'oggetto, nella forma directory/directory/nomeimage.formato

! Struttura\\
Struttura modello standard (http://test.smea.it/pagineTest/wtx_dspobjimg.inc?&wtx_rsltag=&wtx_strtag=)

! Esempi\\
Link di un immagine associato all'oggetto AR/ART/A01, nel formato predefinito .GIF
WTX_TIPO=AR, WTX_PARAMETRO=ART, WTX_CODICE=A01

!! WTX_DSPNST\\
! Descrizione\\
Tag per la visualizzazione delle note strutturate.

! Sintassi\\
<%WTX_DSPNST WTX_TIPOCONTENUTO="..." WTX_DATIPOINFORMAZIONE="..." WTX_ATIPOINFORMAZIONE="..." WTX_CHIAVE1="..." WTX_CHIAVE2="..." WTX_CHIAVE3="..." WTX_SEPARATORE="...%>

* TIPOCONTENUTO= Contenitore note (tabella NSC)\\
* DATIPOINFORMAZIONE= Capitolo note iniziale (tabella NSI)\\
* ATIPOINFORMAZIONE= Capitolo note finale (tabella NSI)\\
* CHIAVE1= Chiave 1\\
* CHIAVE2= Chiave 2\\
* CHIAVE3= Chiave 3\\
* SEPARATORE= Stringa libera di separazione fra le righe\\

! Output\\
Ritorna il contenuto delle note in funzione dei capitoli selezionati

! Struttura\\
Struttura modello standard

! Esempi\\
Visualizza radio per selezione oggetto di tipo tabella/pagamenti con vista per codice+descrizione
WTX_TIPO=TA, WTX_PARAMETRO=PAG, WTX_NOME=RADIONAME, WTX_FORMATO=CD, WTX_ELROW=2

!!! Dettaglio Tag per la gestione delle variabili\\
!! WTX_SETVAR\\
! Descrizione\\
Tag per l'assegnazione di un valore ad una variabile. Le varibili in WebUp non sono tipizzate quindi non viene eseguito alcun controllo sulla tipologia dell'assegnamento

! Sintassi\\
<%WTX_SETVAR WTX_VAR="..." WTX_VALUE="..."%>
dove:
* WTX_VAR: nome da assegnare alla variabile\\
* WTX_VALUE: valore da assegnare alla variabile.\\

! Output\\
Il tag non ha nessun output grafico.

!! WTX_GETVAR\\
! Descrizione\\
Tag per la lettura del valore di una variabile.

! Sintassi\\
<%WTX_GETVAR WTX_VAR="..." WTX_VALUE="..."%>
dove:
* WTX_VAR: nome della variabile da leggere.\\
Questo Tag può essere anche utilizzato nella forma <%#nomevar#%>

! Output\\
Il valore della variabile, in formato testo.

!! WTX_RMVVAR\\
! Descrizione\\
Tag per la cancellazione di una variabile.

! Sintassi\\
<%WTX_RMVVAR WTX_VAR="..." %>
dove:
* WTX_VAR: nome della variabile da cancellare\\

! Output\\
Il tag non ha nessun output grafico.

!!! Dettaglio Tag per il controllo di flusso\\
!! WTX_IF\\
! Descrizione\\
Tag per la gestione del costrutto logico IF. Se la condizione impostata è verificata viene eseguito il codice definito nel bolcco THEN altrimenti viene eseguito il codice del blocco ELSE.

! Sintassi\\
<%WTX_IF WTX_FATTORE1="..." WTX_FATTORE2="..." WTX_OPERATORE="..."  WTX_TIPO="..." WTX_PARAMETRO="..." WTX_CODFILTRO="..."  WTX_THEN="..." WTX_ELSE="..."%>
Dove:
* FATTORE1: primo elemento di confronto\\
* FATTORE2: secondo elemento di confronto\\
* OPERATORE: operatore logico da applicare\\
Valori disponibili:
** EQ: Uguaglianza\\
** NE: Diverso da\\
** GT: Maggiore di\\
** GE: Maggiore o uguale di\\
** LT: Minore di\\
** LE: Minore o uguale di\\
* THEN: codice da eseguire se la condizione è vera. Può essere a sua volta un Tag.\\
* ELSE: codice da eseguire se la condizione è falsa. Può essere a sua volta un Tag.\\

N.B.: I campi THEN ed ELSE possono contenere dei richiami ad altri Tag di Web.Up. E' un modo per eseguire un Tag piuttosto che un altro in funzione del risultato di un confronto logico. Ciò comporta la presenza di  tag annidati uno nell'altro e il conseguente rischio che il motore dinamico confonda i costrutti del tag contenuto con quelli del tag contenitore. Per questo motivo  i tag annidati nei campi THEN e ELSE devono essere scritti in modo particolare, secondo le due regole seguenti:
1 Il tag contenuto nel campo THEN o nel campo ELSE non deve essere racchiuso tra i caratteri di delimitazione <% e %>
2 All'interno del tag, tutti i caratteri " (doppio apice) devono essere sostituiti con caratteri ' (apice singolo).

! Output\\
A seconda del risultato del confronto logico, ritorna il contenuto del blocco THEN o del blocco ELSE. Se questi contengono un Tag, ritorna il risultato della sua esecuzione.

! Struttura\\
Struttura modello standard (http://test.smea.it/pagineTest/wtx_if.inc?wtx_rsltag=&wtx_strtag=)

! Esempi\\
Scrivi "Condizione vera" se la condizione è verificata, in caso contrario scrivi "Condizione falsa"
<%WTX_IF WTX_FATTORE1="3" WTX_FATTORE2="3" WTX_OPERATORE="EQ" WTX_THEN="Condizione_vera" WTX_ELSE="Condizione_falsa"%> (http://test.smea.it/servlet/ServletTag?WTX_WBP=WTX_IF&WTX_FATTORE1=3&WTX_FATTORE2=3&WTX_OPERATORE=EQ&WTX_THEN=Condizione_vera&WTX_ELSE=Condizione_falsa)

!!! Tag per l'esecuzione di azioni e funzioni\\
!! WTX_EXEFUN\\
! Descrizione\\
Tag per l'applicazione di una funzione con input da utente. Vengono mostrate all'utente una serie di domande (definite dal gestionale) a cui deve rispondere. Le risposte date vengono raccolte, controllate e inviate al motore che esegue la funzione associata. Se l'azione va a buon fine, viene mostrata una pagina di conferma (definibile dall'utente). In caso contrario viene mostrata una pagina di errore (anch'essa definibile a piacere).

! Sintassi\\
<%WTX_EXEFUN WTX_TIPOFUNZIONE="..." WTX_CODICEFUNZIONE="..." WTX_PAGINACONFERMA="..." WTX_PAGINAERRORE="..." WTX_NOMEFORM="..."%>

* TIPOFUNZIONE: il valore obbligatrio identifica il tipo di funzione associata all'oggetto\\
* CODICEFUNZIONE: codice della funzione per l'oggetto\\
* PAGINACONFERMA: pagina html da visualizzare per confermare l'esecuzione dell'azione. Se non definita viene usata una pagina di default.\\
* PAGINAERRORE:pagina html da visualizzare per segnalare un errore nei dati immessi. Se non definita viene usata una pagina di default.\\

! Output\\
Si tratta di un form con l'elenco delle domande a cui rispondere e il bottone di invio con associato il motore di esecuzione dell'azione. Se le domande prevedono un valore tipizzato vengono mostrati i rispettivi bottoni di ricerca per ognuno dei campi interessati.

! Struttura\\
Struttura modello standard (http://test.smea.it/pagineTest/wtx_exefun.inc?&wtx_rsltag=&wtx_strtag=)

!! WTX_DSPFUN\\
! Descrizione\\
Tag per l'applicazione di una funzione ad un oggetto Sme.up.
Il codice Html ritornato viene costruito su AS400.

! Sintassi\\
<%WTX_DSPFUN WTX_TIPO="..." WTX_PARAMETRO="..." WTX_CODICE="..." WTX_TIPOFUNZIONE="..." WTX_CODICEFUNZIONE="..."%>

* TIPO, PARAMETRO,CODICE: valori obbligatori che definiscono l'oggettoSme.up a cui è applicata la funzione\\
* TIPOFUNZIONE: il valore obbligatrio identifica il tipo di funzione associata all'oggetto\\
* CODICEFUNZIONE. codice della funzione per l'oggetto\\

! Output\\
Ritorna il codice HTML generato su AS400 corrispondente alla funzione richiesta

! Struttura\\
Struttura modello standard (http://test.smea.it/pagineTest/wtx_dspfun.inc?wtx_rsltag=&wtx_strtag=)

! Esempi\\
Visualizza la funzione J_020 (distinta base) di tipo J-AR per l'oggetto AR-ART-A01:
<%WTX_DSPFUN WTX_TIPO="AR" WTX_PARAMETRO="ART" WTX_CODICE="A02" WTX_TIPOFUNZIONE="J-AR" WTX_CODICEFUNZIONE="J_020"%> (http://test.smea.it/servlet/ServletTag?WTX_WBP=WTX_DSPFUN&WTX_TIPO=AR&WTX_PARAMETRO=ART&WTX_TIPOFUNZIONE=J-AR&WTX_CODICE=A02&WTX_CODICEFUNZIONE=J_020)

Visualizza la funzione J_060 (listino vendita per cliente) di tipo J-AR per l'oggetto AR-ART-A01:
<%WTX_DSPFUN WTX_TIPO="AR" WTX_PARAMETRO="ART" WTX_CODICE="A02" WTX_TIPOFUNZIONE="J-AR" WTX_CODICEFUNZIONE="J_060"%> (http://test.smea.it/servlet/ServletTag?WTX_WBP=WTX_DSPFUN&WTX_TIPO=AR&WTX_PARAMETRO=ART&WTX_TIPOFUNZIONE=J-AR&WTX_CODICE=A02&WTX_CODICEFUNZIONE=J_060)

Visualizza la funzione J_050 (listino vendita per articolo) di tipo J-AR per l'oggetto CN-CLI-000001:
<%WTX_DSPFUN WTX_TIPO="CN" WTX_PARAMETRO="CLI" WTX_CODICE="000001" WTX_TIPOFUNZIONE="J-AR" WTX_CODICEFUNZIONE="J_050"%> (http://test.smea.it/servlet/ServletTag?WTX_WBP=WTX_DSPFUN&WTX_TIPO=CN&WTX_PARAMETRO=CLI&WTX_TIPOFUNZIONE=J-AR&WTX_CODICE=000001&WTX_CODICEFUNZIONE=J_050)

Visualizza la funzione J_070 (ordini vendita del cliente) di tipo J-AR per l'oggetto CN-CLI-000001:
<%WTX_DSPFUN WTX_TIPO="CN" WTX_PARAMETRO="CLI" WTX_CODICE="000001" WTX_TIPOFUNZIONE="J-AR" WTX_CODICEFUNZIONE="J_070"%> (http://test.smea.it/servlet/ServletTag?WTX_WBP=WTX_DSPFUN&WTX_TIPO=CN&WTX_PARAMETRO=CLI&WTX_TIPOFUNZIONE=J-AR&WTX_CODICE=000001&WTX_CODICEFUNZIONE=J_070)

Visualizza la funzione J_080 (bolle) di tipo J-AR per l'oggetto CN-CLI-000001:
<%WTX_DSPFUN WTX_TIPO="CN" WTX_PARAMETRO="CLI" WTX_CODICE="000001" WTX_TIPOFUNZIONE="J-AR" WTX_CODICEFUNZIONE="J_080"%> (http://test.smea.it/servlet/ServletTag?WTX_WBP=WTX_DSPFUN&WTX_TIPO=CN&WTX_PARAMETRO=CLI&WTX_TIPOFUNZIONE=J-AR&WTX_CODICE=000001&WTX_CODICEFUNZIONE=J_080)

Visualizza la funzione J_090 (fatture) di tipo J-AR per l'oggetto CN-CLI-000001:
<%WTX_DSPFUN WTX_TIPO="CN" WTX_PARAMETRO="CLI" WTX_CODICE="000001" WTX_TIPOFUNZIONE="J-AR" WTX_CODICEFUNZIONE="J_090"%> (http://test.smea.it/servlet/ServletTag?WTX_WBP=WTX_DSPFUN&WTX_TIPO=CN&WTX_PARAMETRO=CLI&WTX_TIPOFUNZIONE=J-AR&WTX_CODICE=000001&WTX_CODICEFUNZIONE=J_090)


!!! Dettaglio Tag per la gestione del sistema\\
!! WTX_CHGSRV\\
! Descrizione\\
Tag che consente la variazione on the fly della macchina AS/400 di riferimento. Alla partenza, Web.up instaura un collegamento con la macchina AS/400 specificata nel file di configurazione. Con questo Tag è possibile ridirigere il collegamento verso una nuova macchina o cambiare il profilo di collegamento sulla macchina precedentemente usata.

! Sintassi\\
<%WTX_CHGSRV WTX_SYSTEM="..." WTX_USER="..." WTX_PASSWORD="..." WTX_LIB="..." WTX_PGM="..." %>

* SYSTEM: indirizzo TCP/IP della macchina AS/400 a cui collegarsi. Accetta sia il formato numerico che quello mnemorico.\\
* USER : utente da usare per il collegamento con l'AS/400.\\
* PASSWORD: password dell'utente per il collegamento con l'AS/400.\\
* LIB: (facoltativo): libreria che contiene il programma server su AS/400. Per default vale *LIBL\\
* PGM (facoltativo): nome del programma server su AS/400. Per default JAJAC0.\\

! Output\\
Il Tag non prevede un output grafico. Torna solo un breve mesaggio che conferma o meno la corretta esecuzione del comando richiesto.

! Struttura\\
Struttura modello standard (http://test.smea.it/pagineTest/wtx_chgsrv.inc?&wtx_rsltag=&wtx_strtag=)

! Descrizione\\
Tag per l'impostazione della lingua. Setta la lingua di default per il sito: dopo l'esecuzione di questo Tag, viene impostata una nuova lingua per tutti i Tag dinamici e tutti i link HTML vengono diretti verso il sottoinsieme del sito dedicato alla lingua attiva in quel momento.

! Sintassi\\
<%WTX_SETLIN WTX_LIN="..." WTX_VERBOSE="..."%>

* LIN: codice lingua da settare come lingua del sito. Il codice lingua è reperito dalla tabella LIN di Sme.up.\\
* VERBOSE (facoltativo): se YES ritorna un messaggio di conferma o di errore, in caso contrario esegue la funzione senza tornare alcun messaggio. Per default vale NO.\\

! Output\\
Il Tag non prevede un output grafico. Se VERSOSE=YES torna un breve messaggio di conferma o di errore.

! Struttura\\
Struttura modello standard (http://test.smea.it/pagineTest/wtx_setlin.inc?&wtx_rsltag=&wtx_strtag=)

!!! Requisiti hardware e software\\
I moduli operativi di Web.up sono stati scritti nel moderno linguaggio Java della Sun Microsystem. Grazie alla portabilità garantita da questo linguaggio, Web.up può funzionare su diverse piattaforme alternative senza richiedere particolari adattamenti del codice. Questo fa si che le modalità di installazione del prodotto possono differire in maniera significativa in funzione di molti fattori: tipologia delle informazioni da visualizzare, carico di lavoro previsto, tecnologia già disponibile dal cliente ecc. ecc.
In questo paragrafo si descriveranno i requisiti hardware e software normalmente richiesti per l'installazione tipica del prodotto considerando le due piattaforme pi- diffuse in ambito dei servizi di rete (Windows NT e Linux).

!! Requisiti per server Web.up su piattaforma Windows\\
Memoria: minimo 256 Mb, consigliati 512 Mb (obbligatori se si usa WebSphere).
Sistema operativo: Windows NT 4.0 o Windows 2000. Sconsigliati Windows 95/98/Me.
Server HTTP: Microsoft Internet Information Server,  Apache 1.3 o IBM HTTP Server
Servlet engine: IBM WebSphere (versione standard o superiore, richiede 512 Mb), Allaire Jrun, Apache Tomcat.
Java Virtual Machine:  Sun Java Runtime Engine, versione 1.2 o 1.3.  IBM Java Virtual Machine versione 1.1 o superiore.

!! Requisiti per piattaforma Linux\\
Memoria: minimo 128 Mb, consigliati 512 Mb.
Sistema operativo: Consigliata la distribuziona Red Hat versione 6.0 e superiori. Funziona però anche con qualsiasi altra distribuzione recente (Mandrake, Suse).
Server HTTP: Apache 1.3 oppure IBM HTTP Server.
Servlet engine: IBM WebSphere (versione standard o superiore), Allaire Jrun oppure Apache Tomcat.
Java Virtual Machine: consigliato il JDK 1.3 della Sun Microsystem. Ci potrebbero invece essere alcuni problemi con il pacchetto Kaffe, non pienamente Java compatibile.

!! Requisiti piattaforma AS/400\\
La piattaforma AS/400 è normalmente utilizzata come server dei dati gestionali: su di essa gira il gestionale che fornisce tutte le informazioni dinamiche richieste dai moduli di Web.Up. In questo contesto per il corretto funzionamento del sistema è richiesta solo la presenza del gestionale Sme.up e un accesso di rete da parte del server HTTP esterno.
In via teorica è possibile installare interamente Web.Up solo su AS/400 sfruttando la presenza di tutte le funzioni di base già preinstallate nel sistema operativo. Questo tipo di installazione non è però completamente compatibile con la versione attuale di Web.up e ciò comporta che alcune funzionalità potrebbero al momento non funzionare. È comunque previsto lo sviluppo di una versione di Web.up specificatamente pensata per una installazione solo AS/400. In questo caso le richieste di sistema sono:
Sistema operativo: OS/400 versione V4R2 o superiore.
Server HTTP: già presente nel sistema operativo.
Servlet engine: per versioni V4R2 e V4R3 del sistema OS/400 è richiesto IBM WebSphere for AS/400, per versioni superiori è compreso nel sistema operativo.
Java Virtual Machine: già presente nel sistema operativo.