Anatomia dei FRAMEWORK

GENERALITA' SUI FRAMEWORK

Un Framework è una scrivania di lavoro a se stante slegata completamente da altri Framework;

Ogni Framework è composto da:

-  1 file XML che ne descrive le caratteristiche, le applicazioni, i business objects e le loro caratteristiche.

  Questo è il file di base del Framework senza il quale esso non esiste;

-  1 Pagine JS per ogni lingua:

  Queste servono per l'esecuzione del Framework all'interno di un Browser.

Gli oggetti che possono essere gestiti all'interno del Framework sono:

Tutti i file XML dei Framework si trovano nella cartella <ROOT LANSA>\X_WIN95\X_LANSA\X_CAL\Execute" ed i loro 

nomi hanno questa struttura   DMWEB_<nome Framework>.xml

Come creare nuovi Framework

Qui tratteremo la creazione di un Framework che corrisponda alle scelte adottate da Emmedata 

Da DModaweb aprire il framework "Amministrazione DModa" -> "Applicazioni" -> "Frameworks" 

Cliccare su "Nuovo"

- ID File XML: è il nome del file da creare e bisogna utlizzare il nome del modulo applicativo che gestirà (Il prefisso DMWEB_ viene messo in automatico).

   Es: il FrameWork del Magazzino si può chiamare semplicemente "DMWEB_Magazzino"

- Nome Tipo Oggetto FrameWork: è il nome che viene utilizzato all'interno del framework come identificativo

- Descrizione Applicazione: è la descrizione che comparirà nella pagina WEB

Altri Attributi da asseganre sono:

- Area Gestionale (E' il gruppo che includerà il framework nella pagina di login)

- Modulo di vendita 

- Modulo Applicativo

Cliccando su "Salva" verrà creato il file XML.

A questo punto aprire il FrameWork in Designer per terminare la configurazione.

Come configurare un Framework

All'apertura, il FrameWork (sotto Windows) si presenta cosi:

La richiesta di Utente e Password deriva dal fatto che è attiva la gestione Utenti all'interno del FrameWork.

Per lavorare in "Designer" basta cliccare su "Work Offline".

La "Caption" del Framework deve sempre essere "DModa - ddddddddddd"  dove ddddddddd è la descrizione 

Ogni Framework deve avere la seguente struttura dei Menu (creata in automatico dalla Template):

- Azioni

- Stampe

- Utilità

Ogni FrameWork deve avere almeno questi Comandi (creati in automatico dalla Template) :

- Nuovo (con l'attributo "Show on Toolbar" impostato e associato al menu "Azioni")

- Elimina

Come salvare un Framework

Per salvare un Framework cliccare su "(Framework)" quindi su "(Save)"

Quando si salva il Framework verranno generate le pagine per il WEB, al termine verrà presentata la finestra di pubblicazione

di tali pagine.

Può accadere che venga prima presentato un messaggio di avvertimento che la versione del Framework non è allineata:

rispondete sempre "OK"

!!!!!!!!!!! E' IMPORTANTE LASCIARE SOLO LE SELEZIONI EVIDENZIATE !!!!!!!!!!!!!!!!

Gli attributi "Show when disabled" sia nella sezione "Toolbar" e "Show in menu when disabled" nella sezione "Main Menus"

non devono essere impostati.

L'attributo "Show on toolbar" (obbligatorio per il command "Nuovo") può essere impostato, con moderazione, solo nei casi in cui si ha necessità di rendere

facilmente accessibile un particolare BO Command.

Attenzione: troppi command attivi contemporaneamente nella toolbar provocano la mancata visualizzazione di quelli più a destra.

L'attributo "Toolbar Group" deve seguire la suddivisione dei menu e può assumere i seguenti valori: 1 = Azioni;  2 = Stampe;  3 = Utilità

Se un command ha doppia valenza all'interno di un BO deve per forza essere duplicato: un esempio è il command "Stampa" usato sia a livello di BO che a livello di Instance;

in questo caso creare il command CMD_STAMPA_BO e CMD_STAMPA_IL.

Stesso discorso per i command che gestiranno la multiselezione dell'instance-list in quanto devono avere la dicitura "(+)" in aggiunta alla label normale,

allo scopo di far capire la differenza di azione all'utente finale: esempio per "Elimina" (CMD_ELIMINA) e "Elimina (+)" (CMD_ELIMINA_PIU).

5) Per i BUSINESS_OBJECT le linee guida sono queste:

Nella Tab "Command Display", impostare "Object Command Presentation" a "Separate stay on top window"

In questo modo solo i Command a Livello di Oggetto verranno aperti in una finestra separata.

I filtri sono importanti per permettere un accesso veloce alle instance dell'oggetto. Devono essere strudiati in modo tale da non generare una lista troppo grande

per evitare problemi di performance e tempi lunghi ti attesa da parte dell'utente.

Non c'è nessun limite fisico (c'è quello di visualizzazione) nel numero di filtri da poter creare, quindi sarebbe meglio differenziarli più possibile sempre tenendo contro 

delle necessità e soprattutto del contesto.

Dato che per generare l'instance list occorre passare sempre da un filtro, nel caso in cui il filtro non debba richiedere nessun parametro, è possibile definire il filtro

come hidden.

In alternativa ai filtri tradizionali, è possibile definire un unico minifiltro per ogni BO, che comparirà in alto.

Per un approfondimento al riguardo si consiglia la consultazione dell'help di lansa lansa048.chm

L'instance-list propone il risultato delle selezioni effettuate dal filtro e rappresenta un insieme di oggetti su cui lavorare.

Nell'apposito tab di configurazione è possibile definirne la struttura. Fondamentalmente è cosi composta:

- ha 2 visual Id che vengono sempre visualizzati (obbligatori)

- è possibile visualizzare fino a 10 colonne alfanumeriche aggiuntive

- è possibile visualizzare fino a 10 colonne numeriche aggiuntive.

- ha a disposizione 10 chiavi identificative (5 numeriche e 5 alfanumeriche) che devono essere gestite da programma.

Normalmente ogni BO ha la propria instance-list ma è anche possibile gestire BO differenti all'interno della stessa, 

in quest'ultimo caso si parla di relazioni tra oggetti.

Le relazioni possono essere :

- PEER : tutti gli oggetti vengono visualizzati sullo stesso livello

- PARENT/CHILD: gli oggetti vengono raggruppati in una Tree-View dove l'elemento principale (livello 1) è considerato

il Padre mentre quelli sottostanti vengono definiti Figli.

L'aggancio tra Padre/Figlio avviene tramite le chiavi dell'instance-List quindi i Figli devono avere le stesse chiavi del padre, più le loro.

Per far convivere BO differenti è importante impostare correttamente il parametro "BusinessObjectType" nel metodo AddToList 

(nel programma che si occupa di caricare i dati nell'Instance List).

In caso di relazione PARENT/CHILD è possibile caricare l'instance-list in modo sincrono o asincrono:

- sincrono: le instance vengono caricate direttamente dal filtro con select o cicli indentati

- asincrono: si definisce nel BO la funzione che dovrà caricare i sotto livelli;

      il filtro quindi carica solo il primo livello.

      sarà il framework a richiamare la funzione ogni volta che sarà necessario.

Il caricamento dati in Instance List di tipo asincrono ottimizza i tempi di esecuzione del caricamento dati;

Se un oggetto può essere gestito solo in relazione con altri, definire la relazione tra i due e nascondere l'oggetto "figlio" dalla navigazione.

Di norma, le opzioni disponibili nella videata di configurazione NON vanno selezionate.

Esempio di BO con Instance List con un unico livello:

Esempio di BO con Instance List che ha relazione di tipo PEER ad altri BO:

Esempio di BO con Instance List che ha relazione di tipo PARENT/CHILD ad altri BO, con caricamento sincrono:

Esempio di BO con Instance List che ha relazione di tipo PARENT/CHILD ad altri BO, con caricamento asincrono:

Nei casi in cui i filtri possono generare una lista contenente molti record (> 200) sarebbe bene utilizzare la tecnica della pseudo-paginazione (ovvero

carico tutti i dati ma ne visualizzo una parte alla volta)

In questi casi se l'instance-list contiene oggetti relazionati come Parent-Child, la paginazione va fatta solo sui record del primo livello (padre).

La paginazione va sempre e solo gestita nel filtro (non nella funzione che carica i figli)

E' IMPORTANTE capire come sono strutturate le chiavi identificative dell'instance-list per non incorrerre in problemi di caricamento ed associazione, soprattutto

in presenza di relazioni.

Questo schema è una rappresentazione di come le chiavi sono memorizzate dall'instance-list, per capire anche come poi avverrà l'ordinamento dei record.

ATTENZIONE Nel caso in cui il figlio necessitasse di una chiave numerica, NON può essere sfruttata la NKEY1.

In pratica le chiavi del filglio possono iniziare dopo la fine delle chiavi del padre, considerando la sequenza indicata in tabella. Nell'esempio, la prima chiave numerica disponibile 

è NKEY2, mentre quella alfanumerica è AKEY3. 

Sono le azioni che possono essere eseguite su un BO e si dividono in due tipi:

- Command a livello di Oggetto (BO Command)

- Command a livello di Instance (IL Command)

La differenza tra questi 2 tipi di Command sta nel fatto che i primi sono già attivi nel momento in cui si seleziona un BO, gli altri invece si attivano nel momento in cui 

viene selezionato almeno un elemento dall'instance-list.

Da questo si evidenzia il fatto che devono far parte dei BO Command tutte le funzionalità generali dell'oggetto in questione, mentre devono far parte degli 

Instance-List Command le operazioni specifiche per l' instanza selezionata dall'elenco generato dal filtro.

Per il fatto che nell'instance-list è possibile effettuare selezioni multiple, alcuni command possono prevederne la gestione (deve essere fatta da programma: non è

una funzionalità automatica fornita dal Framework)

Esempio:

- "Interrogazione Ordini" vale per l'oggetto "Ordine" (BO Command)

- "Dettaglio" vale per l'ordine 3451 che è una istanza dell'oggetto "Ordine" selezionato dall'Instance-List (IL Command)

- "Elimina (+)" consente di eliminare contemporaneamente tutte le istanze selezionate. (IL Command con gestione della multiselezione)

Tutte le azioni possibili per un oggetto devono essere definite come command separati per questi motivi:

- è più vicino alla programmazione ad oggetti

- consente di agganciarle ai menu contestuali 

- consente una gestione flessibile delle autorizzazioni 

E' quindi opportuno creare tanti command quante sono le azioni da fare piuttosto che includerle con dei bottoni all'interno del command principale.

Esempio:

Devono diventare dei Command:

- Elimina

- Annulla

- Ripristina

- Stampa

ecc.

Le azioni di "modifica" vanno implementate in command come "Gestione" o "Dettagli"

I tasti funzione rimangono validi per le azioni che hanno senso solamante all'interno di un determinato command.

- Decodifica

- Ricalcola

ecc.

In alcuni casi è necessario attivare o meno dei command in base al tipo di istanza selezionata: ciò è possibile grazie alla gestione dei "Sub-Type".

Questi sono delle semplici descrizioni di 5 caratteri che vanno associate ad ogni elemento dell'Instance-List al momento del caricamente dal Filtro.

Nel FrameWork vanno associati i command a queste descrizioni.

Al momento della selezione dell'istanza, è il FrameWork che si preoccupa di visualizzare solo i command associati al Sub-Type selezionato.

IMPORTANTE: se vengono gestiti i Sub-Type TUTTI gli elementi dell'Instance-List devono averne associato uno altrimenti il meccanismo si blocca.

Regole di associazione dei commad ai Business-Object

Riepilogo dei "Command Options"

Stay Active: Valido solo in ambiente Windows no WEB

Default Command: YES => Imposta il command come avvio automatico quando si seleziona un elemento dell'Instance-List

NO => E' un Command normale che rimane attivo quando scorro gli elementi dell'Instance-List

NEVER => Fa in modo che quando mi sposto su un altro elemento dell'Instance-List mentre il command è attivo, 

    viene richiamato in automatico il command di default

Allow on Web: Va sempre spuntato, in quanto abilita il command ad essere visualizzato in ambiente WEB

Allow on Windows: Non va spuntato.

On Popup Menus: Permette la visualizzazione del Command all'interno del menu contestuale

Hide All Other Command Tabs: Fa si che quando il command è attivo tutti gli altri command non vengono visualizzati

Restricted Access: Disabilita automaticamente l'autorizazzione del command agli utenti

Execute as Hidden Command:  Il command viene eseguito senza un' interfaccia grafica (in background sul server). 

      E' utile per fare delle attività che non hanno bisogno di interazione con l'utente.

      In questo caso il programma non sarà una WAM ma una funzione RDML o RDML/X

      (fare riferimento al manuale "Visual LANSA FrameWork" lansa048.chm per la codifica e l'uso)

"Optional Arguments"

E' possibile utilizzare questi campi per passare delle informazioni al programma legato al command.

E' utile nei casi in cui più command richiamano lo stesso programma che si deve comportare in modo diverso in base al command.

Es: La WAM di "Modifica" e "Inserimento" può essere chiamata dal Command "Nuovo" con Alpha Argument 1 impostato a "A" mentre dal Command

     "Dettagli" con Alpha Argument 1 impostato a "M" 

Business object command

INSTANCE LIST COMMAND

ATTENZIONE: il flag "Default Command" DEVE essere impostato SOLO SU DI 1 COMMAND