MosaicoX: appunti per la gestione dell'interfaccia
®
Mosaicox: Appunti per la gestione dell'interfaccia
Versione 3.6 – 15.11.2006 - © Whag srl Autore: Carlo Cassinari Applicabile a MoasServer Ver. 1.3.5
Pag. 1 di 24
15/11/06
MosaicoX: appunti per la gestione dell'interfaccia
I marchi MosaicoX e i tre quadrati rossi con la X sono marchi registrati di Whag Srl
Pag. 2 di 24
15/11/06
MosaicoX: appunti per la gestione dell'interfaccia
Indice dei contenuti
1. Struttura dell'interfaccia 1. Componenti di base della videata 2. ApView 3. Collegamenti tra ApView e Database 4. Struttura base di una tabella dati 5. Specifiche dei descrittori degli oggetti delle ApView 2. Elenco tabelle applicative 3. API
Pag. 3 di 24
15/11/06
MosaicoX: appunti per la gestione dell'interfaccia
1. Struttura dell'intefaccia
L'interfaccia del MOAS può essere costruita dinamicamente dal client in base alle informazioni che gli invia il server. Per questo sono stati implementati nel server xmlrpc i metodi GetViewGui, GetViewData, GetTreeMenu e GetSpeedBar. Questi quattro metodi, estrapolando le informazioni contenute in alcune tabelle del database, inviano al client l'elenco dei componenti che definiscono i contenuti, l'aspetto e le funzioni disponibili per l'interfaccia. Questo sistema offre il vantaggio di poter costruire o modificare l'interfaccia in funzione delle esigenze specifiche del singolo cliente. Attualmente è disponibile l'interfaccia WEB e alcune librerie di metodi che possono essere utilizzati per l'accesso ai dati diretto bypassando l'interfaccia, in questo manuale ci occuperemo dell'interfaccia WEB. 1.1 Componenti di base della videata L'aspetto dell'interfaccia è definito quindi dai seguenti fattori: Layout HTML delle pagine, foglio di stile CSS, impostazioni contenute nel database del MOAS. Lasciando da parte per un momento i primi due ci soffermeremo invece sul terzo fattore che è quello più interessante per chi debba costruire interfaccie o personalizzare quelle esistenti. Dopo la classica immissione di login e password, il form viene inviato al webserver che elabora i dati con PHP. Php si mette in connessione con MOAS e instaura un dialogo che gli permette di ottenere dal server le informazioni necessarie per comporre la videata come quella in figura 1. Lo strumento utilizzato per accedere a MOAS è naturalmente un browser HTML. Non ci sono particolari limitazioni sul tipo di browser, possiamo utilizzare Internet Explorer, Opera, Safari, Mozzilla e tutti quelli che sono compatibili con HTML 4 e Javascript 1.1.
Pag. 4 di 24
15/11/06
MosaicoX: appunti per la gestione dell'interfaccia
Figura 1: intefaccia web tipo Informazioni utente e data Informazioni utente e data
SpeedBar, accesso veloce SpeedBar, accesso veloce a funzioni generali e a funzioni generali e LOGOUT LOGOUT
Menu a livelli Menu a livelli infiniti scritto infiniti scritto in Javascript in Javascript
Area NEWS, informazioni Area NEWS, informazioni e notizie provenienti dal e notizie provenienti dal server, indirizzate a classi server, indirizzate a classi di utenza. di utenza.
Area di lavoro principale, Area di lavoro principale, in questa zona vengono in questa zona vengono visualizzate le APVIEW visualizzate le APVIEW
Non vengono utilizzati plug-in di sorta e le uniche immagini utilizzate sono quelle che definiscono le icone del menu e le “linguette” delle pagine. Questo rende agevole l'accesso all'applicazione anche via modem analogico, provare per credere. Quando effettuiamo il login, PHP chiede al Moas gli oggetti che compongono l'interfaccia, in sequenza chiede: la speedbar, il menu, la vista da inserire nell'area di lavoro e infine le notizie. Il menu e la speedbar vengono recuperati in base al profilo utente in base alla relazione: Utente --> Profilo --> Menu e Speedbar Nel database sono presenti N profili, ad ogni profilo sono associati un menu e una speedbar, ogni utente è associato a un profilo. Questo principio regola quindi cosa un utente possa vedere dell'applicazione, a quali dati possa o meno avere accesso e se in modifica o in lettura. 1.2 ApView La parte di videata che viene costruita nell'area di lavoro principale è detta APView. Abbiamo coniato questo termine volendo sintetizzare il concetto di VISTA APPLICATIVA. Il database presenta tabelle, campi, indici e talvolta viste logiche di questi oggetti, MOAS
Pag. 5 di 24 15/11/06
MosaicoX: appunti per la gestione dell'interfaccia
presenta le “viste applicative”. Ogni vista applicativa o APView è un insieme di informazioni distribuite su diversi livelli: 1. APView 2. Pagina 3. Action & Campi Ogni oggetto dell'apview ha quattro caratteristiche principali: • Nome: identificativo univoco nel suo livello • Indice: ordine di apparizione nell'interfaccia • Caption: etichetta • Descrittore: informazioni che descrivono le proprietà dell'oggetto. Linguette di Linguette di accesso alle accesso alle pagine pagine Tasti (Action) funzione per Tasti (Action) funzione per navigazione, modifica e stampa navigazione, modifica e stampa dati dati
Tabella con Tabella con elenco dei elenco dei record record Figura 2: particolare dell'area di lavoro della ApView
Nome, Indice e descrittore sono unici per ogni oggetto mentre la caption è multipla, ne può esistere una per ogni lingua configurata. Questo rende l'applicazione già pronta per utenti di lingue differenti. L'utente vedrà l'interfaccia tradotta nella lingua che è stata impostata nella sua scheda anagrafica. Vediamo le relazioni tra i tre livelli di oggetti: per ogni apview possono esistere più pagine, per ogni pagina esistono azioni e campi, le azioni e i campi sono relativi ad una tabella del database. Possiamo pensare alla apview come ad un classico modulo, il modulo può essere composto da una o più sezioni, dette pagine, accessibili cliccando sulla classica “linguetta” identificativa. Ogni pagina può presentare action e campi di varia natura e in diversi formati di layout (tabelle, record singoli, griglie editabili e così via). Il classico esempio di APView che mi piace fare è quello dell'anagrafico articoli. La apview si riferisce principalmente alla tabella articoli, con relazioni uno a molti verso i listini e i gruppi di articoli. La prima pagina (sezione) della ApView presenta l'elenco degli articoli con le colonne prescelte organizzate in una tabella, la seconda pagina presenta il dettaglio dell'articolo selezionato con il click del mouse, la terza pagina presenta l'elenco dei gruppi ai quali l'articolo è associato. Lo strumento che si utilizza per modellare le APView è MOASSERVERMANAGER, un programmino scritto in Delphi, compilabile anche con Kylix per la piattaforma Linux. Questo
Pag. 6 di 24
15/11/06
MosaicoX: appunti per la gestione dell'interfaccia
strumento offre una serie di funzioni per operare sul database e un'interfaccia che serve per compilare agevolmente i dati sulle ApView. Per maggiori informazioni su MoasServerManager e il suo utilizzo vedere il capitolo seguente. Adesso è importante capire bene come funzionano le APView. Ogni ApView ha un nome, questo nome servirà per collegare l'ApView al menu principale e alla speedbar, dando quindi modo all'utente di utilizzarla. Se un apview non viene collegata al menù o alla speedbar non sarà accessibile da questa interfaccia. La caption della ApView non viene per il momento visualizzata ma potrebbe sempre essere utile in futuro quindi vi consiglio di inserirla correttamente sin da subito. Il descrittore contiene tutta una serie di informazioni che definiscono: a quale tabella del database faccia riferimento la Apview, in che ordine presentare le informazioni, di che tipo di ApView (normale, di lookup, di pickup) si tratta. La pagina oltre ad avere un nome, ha un indice che stabilisce in che posizione viene presentata la linguetta di selezione pagina. Anche la pagina ha la caption multilingua, la caption è il testo che viene visualizzato nella linguetta di selezione. Il descrittore della pagina dice all'interfaccia di che tipo di pagina si tratti (tabella, record, griglia di editing), a che tabella fa riferimento, quale è la pagina di dettaglio nel caso in cui l'utente clicchi su un record della tabella. Le action definiscono cosa l'utente possa fare o no nella pagina, quindi ogni pagina ha le sue action. Le action hanno come per le pagine: un nome, un indice, la caption multilingua, il descrittore. Nel descrittore troviamo: il tipo di action (Database, Navigation), se abilitata, se visibile, e che cosa fa. Nella pagina, definito il layout dobbiamo definire quali campi si debbano vedere/editare. Quindi per ogni campo abbiamo il nome (corrispondente al campo nella tabella associata del database), l'ordine di apparizione, la caption multilingua e il descrittore. All'interno del descrittore troviamo informazioni come TYPE (edit, text, menufield, lookup, ...), il formato di visualizzazione, eventuali valori di default ecc. Ogni informazione nei descrittori viene definita dalla sintassi NOME=VALORE, ad esempio se un campo deve essere editabile, nel descrittore dovrà essere presente la voce TYPE=EDIT Non importa in che posizione (prima o dopo altre informazioni) ma è importante che non ci siano spazi prima del nome, tra il nome e il segno di =, tra il segno di = e il valore. I nomi delle proprietà e i valori (tranne quelli tra apici) sono indipendenti da maiuscole e minuscole, vegono comunque tutti tradotti in MAIUSCOLO. 1.3 Collegamenti tra apview e database Le apview sono viste applicative, ovvero oggetti che fanno vedere il database dell'applicazione. Come abbiamo visto, è possibile specificare sia la tabella di visualizzazione che la tabella di editing nel caso non dovessero essere le stesse (se avessimo ad esempio un database che gestisce le viste logiche ma non editabili). Osservazione importante da fare è che le apview basano il collegamento con i record sottostante sul contenuto del campo RecID. Per questo motivo, negli oggetti campo di tutte le pagine, il primo della lista deve sempre essere RecID, preferibilmente di tipo Hidden. L'interfaccia, quando riceve l'ordine dall'utente di aprire una ApView compie due operazioni: prima si fa mandare la lista degli oggetti per l'ApView in questione, poi si fa mandare il primo record disponibile della tabella legata alla apview. Successivamente, ogni volta che l'utente cliccherà su una action di navigazione (primo, ultimo, prossimo e precedente), l'interfaccia chiederà a MOAS solo i dati della tabella e non più
Pag. 7 di 24 15/11/06
MosaicoX: appunti per la gestione dell'interfaccia
l'elenco degli oggetti. Come si è potuto capire, esiste la possibilità di compilare menù a discesa con dati provenienti da tabelle di lookup. Una precisazione importante da fare è che nel momento in cui l'interfaccia richiede le componenti di una pagina al MOAS, nella specifica di ogni oggetto campo viene inserito anche l'elenco delle opzioni che vanno a comporre il relativo menu a tendina. Queste informazioni vengono trasmesse da MOAS a interfaccia una sola volta allo scopo di minimizzare il traffico sul canale di comunicazione. E' ovvio quindi che se dopo aver aperto una APView con menu a tendina che fanno riferimento a una tabella anagrafica, l'utente modifica i record dell'anagrafica in questione, le modifiche non verranno riflesse nel menu a tendina fino a quando MOAS e interfaccia non si scambino nuovamente i dati dei descrittori dei campi. Questo però avviene solo in due casi: quando apro la prima volta una apview e quando l'utente clicca sulla action di refresh. In sostanza, se si costruisce una ApView con menu a tendina che debbano essere aggiornati dopo modifiche in anagrafica, è bene prevedere sempre una action di refresh. In alternativa è possibile anche inserire nel descrittore del campo con menu a tendina l'opzione “REFRESH=TRUE” che farà si che ad ogni scambio dati tra APVIEW e server, verranno anche rinfrescati i menu a discesa. 1.4 Struttura base di una tabella Come detto, le ApView si mantengono “sincronizzate” con il database sulla base del campo RecID delle tabelle. Questo presuppone che tutte le tabelle che andremo a costruire siano provviste del campo RecID, il quale viene riempito da MOAS in automatico al momento della action di inserimento NEWRECORD. Il campo RecId deve essere definito come un VARCHAR di 30 posizioni e deve essere il primo campo della tabella, in chiave primaria univoca, non nullo. Altri campi che devono essere obbligatoriamente presenti nelle tabelle sono: • CREATOR Varchar(30) • CREATED TimeStamp • MODIFIED DateTime Creator serve a MOAS per sapere chi ha creato il record, evitando quindi di farlo vedere ai non proprietari, CREATED memorizza in automatico data e ora di creazione del record, mentre MODIFIED memorizza la data e l'ora dell'ultima modifica apportata al record. In pratica la frase SQL di creazione delle nostre tabelle deve essere come la seguente:
CREATE TABLE `abbanche` ( `RecId` varchar(30) NOT NULL default '', `Banca` varchar(100) default NULL, `Filiale` varchar(100) default NULL, `Piazza` varchar(40) default NULL, `Abi` varchar(10) default NULL, `Cab` varchar(10) default NULL, `Creator` varchar(30) default NULL, `Created` timestamp(14) NOT NULL, `Modified` datetime default NULL, PRIMARY KEY (`RecId`), UNIQUE KEY `RecId` (`RecId`) ) ;
Nell'esempio precedente abbiamo creato una tabella per memorizzare l'anarafico delle banche secondo la classificazione ABI, in grassetto sono evidenziate le parti sempre e comunque obbligatorie per la costruzione di una tabella compatibile con MOAS.
Pag. 8 di 24
15/11/06
MosaicoX: appunti per la gestione dell'interfaccia
Questo sistema presenta sostanzialmente tre vantaggi: 1. Il RecId, univoco a livello di database ci permette di identificare con certezza ogni singolo record, potendolo quindi relazionare in diversi contesti, anche di tracciatura delle operazioni e soprattutto di utilizzarlo come bookmark per la gestione dei cursori a livello di server per il posizionamento delle viste. Risulta inoltre molto semplice instaurare relazioni tra tabelle perchè il criterio di relazione sarà sempre costituito da un legame tra singoli campi. Facciamo un esempio: se voglio associare ad un cliente la sua banca, nella tabella del cliente mi sarà sufficiente creare un campo denominato RifBanca Varchar(30). Con questo sistema, guardando la tabella dei clienti, vedendo il campo RifBanca saprò già che si tratta di un campo di relazione sulla tabella banche. A livello di integrità dati, potrò sempre comunque definire una chiave univoca sui campi ABI e CAB della tabella banche evitando così duplicazioni di chiave. 2. Il campo Creator mi dice sempre a chi appartiene il record, questo mi è utile per limitare la vista dei record in funzione dell'utente loggato nel sistema. (Per maggiori informazioni su questo argomento si rimanda all'analisi di base che tratta la questione dell'ereditarietà dei record) 3. I campi Created e Modified mi danno informazioni sulla data di creazione e di modifica del record che potranno essere utili in futuro quando dovrò sincronizzare più database tra loro.
Pag. 9 di 24
15/11/06
MosaicoX: appunti per la gestione dell'interfaccia
1.5 Specifiche dei descrittori degli oggetti delle ApView Vediamo nel dettaglio tutte le caratteristiche associate alle singole tipologie di oggetto inseribili nel descrittore. Teniamo presente che alcune caratteristiche sono attive solo in alcuni contesti, ad esempio, nelle pagine di tipo TAB, non è possibile avere campi se non di tipo TEXT (ovvero non editabili). Tutte le voci non specificate vengono sostituite da impostazioni di default provenienti dal server o instaurate nell'interfaccia. Ad esempio, se EditTablename non viene specificato, è automaticamente recuperato dal Tablename; se Autoinsert non viene specificato viene considerato come FALSE. I valori con * sono obbligatori. Quelli con ^ sono considerati di default se non esplicitati con specifica.
ApView
Nome Tablename * (obbligatorio) EditTablename SELECTCLAUSE FROMCLAUSE JOINCLAUSE WHERECLAUSE ORDERBYCLAUSE GROUPBYCLAUSE Valore [nometabella] Significato
Indica il nome della tabella dalla quale vengono prelevati i record da inserire negli oggetti griglia, campo Nel caso in cui non sia possibile editare i dati su Tablename è possibile specificare una tabella diversa
Componenti di uno Serve per costruire una vista di dati complessa quando non bastano i campi riferiti direttamente con statement sql. l'opzione RIFTAbleName. Quando la SELECTCLAUSE è compilata, TableName perde significato. Esempio: TableName=documentiscadenze DefaultOrderBy=DataRata SELECTCLAUSE=documentiscadenze.recid, documentiscadenze.DataRata, documentitestata.numeroprotocollo, documentitestata.dataprotocollo, soggetti.RagioneSociale, abmodpag.Descrizione, documentiscadenze.Stato, documentiscadenze.RifBancaIncasso, abbanche.Banca as RifBancaPresentazione, documentiscadenze.Pagata, documentiscadenze.Importo FROMCLAUSE=documentiscadenze, documentitestata, soggetti, abmodpag, sograpporto JOINCLAUSE=left outer join abbanche on (documentiscadenze.rifbancapresentazione = abbanche.recid) WHERECLAUSE=documentiscadenze.rifdocumento = documentitestata.recid and documentiscadenze.rifrapporto = sograpporto.recid and sograpporto.rifsoggetto = soggetti.recid and documentiscadenze.RifPagamento = abmodpag.recid //ORDERBYCLAUSE=documentiscadenze.datarata GROUPBYCLAUSE=documentiscadenze.Stato, documentitestata.RifTipoPagamento
MaskType (valido anche per MASK * ApPageView) MASK:UP MASK:DOWN
Questa opzione definisce come devono essere presentati i dati della tabella specificata. Il valore MASK indica che devono essere presentati solo i record generati o ereditati dall'utente corrente. MASK:UP indica che i record presentati devono
Pag. 10 di 24
15/11/06
MosaicoX: appunti per la gestione dell'interfaccia
ApView
MASK:
essere quelli gerati o ereditati dall'utente di livello superiore. Se specifico invece MASK:UP-2 indico che i record presentati saranno quelli degli utenti due livelli superiori MASK:DOWN indica che i record presentati devono essere quelli gerati o ereditati dall'utente di livello inferiore. MASK: dove taglivello è appunto un taglivello valido nella schiera di utenti, definisce da quale livello preciso di utenza recuperare i dati. Es.: MASK:1 recupera tutti i record inseriti a livello di ADMIN. Questa opzione ha validità anche in caso di cancellazione dei record, per il momento in beta e solo per MASK:DOWN e solo se il record non è ereditato.
Filter
nomcampo=valore
Espressione regolare condizionale che permette di restringere la visualizzazione dei record solo a quelli rispondenti alla condizione specificata. Sono ammessi tutti gli operatori logici sql. Espressione regolare che definisce l'ordinamento dei record di default all'apertura della apview Quando viene richiamata la apview, e successivamente richiesto il set di record al Moas, se non esiste nessun record, ne viene creato uno automaticamente e passato all'interfaccia. Può essere utile in apview dove necessariamente deve essere sempre disponibile un record da editare evitando all'utente di dover necessariamente cliccare sulla action di inserimento. Rende la funzione non attiva Specifica che la apview è una apview di lookup, serve all'interfaccia per gestire l'apertura modale della finestra di visualizzazione Specifica che la apview è normale Per il momento, se specificato, è possibile solo definire apview normali, di lookup e di Pickup, che sono quelle predisposte per l'ereditarietà dei record. Versioni future potranno utilizzare questa specifica con altri valori.
Defaultorderby Autoinsert
nomecampo True
False ^ IsLookUp True False ^ ViewType PickUpView
ApPageView
Nome Tablename * EditTablename Type Valore
Significato
Indica il nome della tabella dalla quale vengono prelevati i record da inserire negli oggetti griglia, campo Nel caso in cui non sia possibile editare i dati su Tablename è possibile specificare una tabella diversa Compila la pagina con la visualizzazione di un record alla volta, utile per editare schede anagrafiche. Compila la pagina con una tabella non editabile di soli campi di testo, vengono visualizzati nrecord alla volta in funzione del parametro MAXROWSPERPAGE inserito nel profilo utente
[nometabella] Record Tab
Pag. 11 di 24
15/11/06
MosaicoX: appunti per la gestione dell'interfaccia
ApPageView
Grid Compila la pagina con una griglia editabile, è possibile inserire campi di ogni tipo (testo, data, lookup, menu,...) è possibile editare i valori nei campi su tutti i record e solo alla fine inviare il salvataggio al server. Ogni Record presenta una casella di selezione all'inizio utilizzabile per le operazioni di cancellazione Compila la pagina con una tabella non editabile come con TAB ma aggiunge una casella di selezione all'inizio di ogni record. Questo formato è da utilizzare nella apview di lookup per consentire all'utente la selezione di un record e nelle apview di pickup per selezionare uno o più record. Non rende visibile il tasto per l'aggiunta di record nella griglia Rende visibile il tasto per l'aggiunta di record solo sopra Rende visibile il tasto per l'aggiunta di record solo sotto Rende visibile il tasto sopra e sotto Indica quale pagina è da utilizzarsi al momento del click su un record della TAB, per rappresentare il dettaglio del record cliccato. Esempio: ho un apview con due pagine, una denominata ELENCO, l'altra DETTAGLIO. La pagina Elenco è di tipo TAB mentre la pagina DETTAGLIO è di tipo RECORD. Indicando nel descrittore della pagina Elenco la voce DETAILPAGE=DETTAGLIO ottengo la possibilità di cliccare su un record della pagina ELENCO e vedere subito il dettaglio del record selezionato nella pagina DETTAGLIO. Elenco dei campi che verranno utilizzati nella relazione con altre tabelle presenti nella pagina di Dettaglio specificata in DetailPage, questi campi fanno riferimento alla tabella specificata in Tablename della pagina. Elenco dei campi della tabella specificata nel TABLENAME della pagina indicata in DetailPage. Questi sono i campi che verranno accoppiati ai KeyFields per creare la relazione tra pagina corrente pagina di dettaglio. Es. Nel caso dell'anagrafica articoli ho la pagina elenco che porta questa configurazione: DetailPage=Dettaglio KeyFields=RecId DetailKeyFields=RecId (riferito alla tabella articoli) (riferito alla tabella articoli)
CheckTab
AddButton (Solo se TYPE=GRID) NONE
TOP BOTTOM BOTH ^
DetailPage
Keyfields
DetailKeyFields
Se però ho una relazione tra articoli e listini, avrò una cosa del genere DetailPage=Dettaglio KeyFields=RecId (riferito alla tabella articoli) DetailKeyFields=RifArticolo(riferito alla tabella listini)
Autosave
True
Quando l'utente passerà ad un altra pagina, tutte le modifiche apportate al record corrente verranno salvate in automatico Nessun salvataggio se non espressamente richiesto dall'utente con il click sulla action appropriata.
False ^
TableHeight
Altezza in pixel, 300 di Altezza della tabella per le barre di scorrimento default
Pag. 12 di 24
15/11/06
MosaicoX: appunti per la gestione dell'interfaccia
ApActionView
Nome Position
Top ^
Valore
Significato
Indica se la action deve essere posizionata in una action bar che stia al di sopra di ogni altro oggetto campo/tabella Indica se la action deve essere posizionata in una action bar che stia al di sotto di ogni altro oggetto campo/tabella Indica se la action è visibile o meno nella actionbar specificata Indica se la action è attiva o meno nella actionbar specificata Designa una action che consente la navigazione nei record legati alla apview.
Bottom
Visible Enabled ActionType=Navigation
True False ^ True False ^
First
Porta al primo record se la pagina è di tipo RECORD o al primo set di record se la pagina è di tipo TAB, CHEKTAB e GRID. Porta al record precedente se la pagina è di tipo RECORD o al set di record precedente se la pagina è di tipo TAB, CHEKTAB e GRID. Porta al record successivo se la pagina è di tipo RECORD o al set di record successivo se la pagina è di tipo TAB, CHEKTAB e GRID. Porta all'ultimo record se la pagina è di tipo RECORD o all'ultimo set di record se la pagina è di tipo TAB, CHEKTAB e GRID.
Prev
Command
Next
Last
ActionType=Window
Close Chiude la apview corrente se aperta in una nuova finestra
Command
ActionType=Database
NewRecord
Designa una action che apporta modifiche al database Causa l'inserimento di un nuovo record nella tabella, il nuovo record viene fisicamente inserito nella tabella dal server, vengono compilati eventuali valori di default specificati in DefaultValue nel descrittore dei campi. Salva le modifiche al record corrente. Se non vengono apportate modifiche al record la action non viene inviata al server Autoappend Se = TRUE aggiunge un nuovo record automaticamente al momento del salvataggio di quello corrente. Delete Elimina il record corrente, viene chiesta conferma Invia una richiesta di esecuzione del metodo DoAction al server MOAS (utile per implementare pulsanti che richiamino procedure residenti sul server che al termine dell'elaborazione diano un risultato booleano.
Command
Save
ActionType=DoAction
Command Specifica il nome del comando da eseguire Autosave Salva i dati della apview prima di inviare il comando
Pag. 13 di 24
15/11/06
MosaicoX: appunti per la gestione dell'interfaccia
ApActionView
Confirm Se uguale a True chiede conferma Esempio applicativo ActionType=DoAction
Command=!ProcessaScadenziario NAME=Applica Visible=True Enabled=True La action qui descritta permette di lanciare una query presente nella tabella apqueryproc che aggiorna la situazione di prima nota e scadenziario in funzione dei dati presenti nel db. Il parametro COMMAND indica il nome della query preceduto da ! Che specifica il tipo di comando da eseguire. Attualmente sono implementate solo le esecuzioni di query.
ActionType=Print ReportName
Avvia la stampa di un report in formato PDF Nome del template da utilizzare per la stampa del report. Il server prepara un file pdf contenente il risultato di stampa e invia all'interfaccia l'URL del file, il file viene quindi aperto in una nuova finestra del browser. NOTA: installare o aggiornare acrobat reader alla versione 7 Sono possibili due sintassi: ReportName=ddt, dove ddt è il nome del template da utilizzare per creare il report. Per poter eseguire uno script sql, di quelli contenuti in apqueryproc, è sufficiente aggiungere un ? Davanti al nome del report. Lo script si dovrà chiamare come il report, ma con l'esclamativo davanti; es: Devo stampare un report chiama:eventisettimana.rep, inserirò: che si
ReportName=?eventisettimana.rep. Prima di elaborare il report, verrà lanciato lo script !eventisettimana.rep. Per stampare con un nome di template proveniente da un campo di una tabella specifica: inserire un punto esclamativo davanti al nome del campo, al posto del nome del report, seguire con nometabella, nome campo e nomeparametro per l'update del record con l'azione di stampa. Esempio: ReportName=! Layoutdocumento;documentitestata;Stampato;ParRifDoc Nel caso invece si desideri inviare via e-mail il pdf risultante dalla stampa del documento, occorre specificare quanto nell'esempio seguente: Params=ParRifDoc;RecId ReportName=@ddtimmagine;documentitestata;Stampat o;ParRifDoc Aggiungere anche in tabella apmailquery, nel campo SqlText, una Select come la seguente: select t.Recipient, t.CC, t.BCC, t.Body, td.TipoDocumento as DocType,concat(td.Tipodocumento,' n° ', t.numeroprotocollo, ' del ', DATE_FORMAT(t.dataprotocollo,'%d/%m/%Y')) as Subject from documentitestata t, abtipidocumento td
Pag. 14 di 24
15/11/06
MosaicoX: appunti per la gestione dell'interfaccia
ApActionView where td.RecId = t.RifTipoDocumento and t.RecId = "", e nel campo mailtype “documentitestata”. Ovviamente la tabella “documentitestata” dovrà avere nella sua struttura i campi Recipient, CC, BCC, Subject e Body. Il PDF verrà allegato alla mail con oggetto, destinatari e corpo come quello risultante dalla select. Il Moas si farà carico di inviare il tutto e di memorizzare nella tabella apmailsent le informazioni e lo stato di invio.
Se si desidera non inviare un pdf al client ma un file RPMF gestibile dal client di reportmanager indicare nel parametro reportname la clausola ASMETAFILE come da esempio: ReportName=articoli;ASMETAFILE
Params [param1=value1;para Parametri che vegono passati al report per la selezione m2=value2;...] dei dati da stampare. Es. se voglio stampare un elenco articoli senza nessuna limitazione non invio alcun parametro, ma se voglio poter selezionare ad esempio il fornitore, nel template avrò specificato l'sql di estrazione dati con un parametro nominato con FORNITORE e nel descrittore della action potrò specificare qualcosa come: FORNITORE=RIFFORNITORE, l'interfaccia invierà al MOAS qualcosa tipo: FORNITORE=MOAS20045509580, ovvero il valore contenuto nel campo della pagina designato come FIELDNAME=RIFFORNITORE. Dato che le apview possono avere dei filtri attivi, se l'utente desiderasse una stampa che rispetti i filtri attivi sulla apview, è possibile inserire nel tempate dei report i parametri di filtro. Se un campo per il quale è possibile attivare un filtro si chiama ARTICOLO, nel parametro che passiamo al report si chiamerà PAR_ARTICOLO.
Archive True
False ^
Attiva l'archiviazione del database (Da implementare) Disattiva l'archiviazione del database (Da implementare)
documento documento
nell'apposito nell'apposito
Keywords [elenco
di parole Parole chiave per l'indicizzazione del docuemento. Se chiave separate da ;] precedute da ! vengono archiviate così come sono altrimenti vengono utilizzati i corrispondenti oggetti campo con il loro valore. Es: ! FATTURE;RagioneSociale,DataProdotocollo;NumeroProto collo (Da implementare)
ActionType=Refresh
Esegue il regresh della apview, acquisendo nuovamente tutte le informazioni inerenti gli oggetti della pagina visualizzata. Utile quando sono presenti campi di tipo MENUFIELD che devono essere rinfrescati con nuove opzioni provenienti da tabelle anagrafiche appena aggiornate. Unica opzione obbligatoria Inseribile in apView con specifica isLookUp=True Ok Viene confermata la selezione fatta dall'utente e chiamato il metodo DoneLookUp che compila i campi referenziati speficiati nel campo di tipo LookupField dal quale era partita la chiamata alla finestra di lookup.
Command Refresh ActionType=LookUp Command
Pag. 15 di 24
15/11/06
MosaicoX: appunti per la gestione dell'interfaccia
ApActionView
Cancel Chiude la ApView di lookup senza dare conferma di selezione, il campo di tipo lookupField dal quale era partita la chiamata alla finestra di lookup rimane invariato Inseribile in apView con specifica ViewType=PickUpView Ok Cancel Open Conferma la selezione fatta nella finestra di pickup è dà inizio alla procedura di acquisizione dei record ereditabili Non conferma la selezione fatta e chiude la finestra di Pickup. Questa action, a differenza delle due opzioni precedenti può essere inserita in qualunque apView dove sia necessario ereditare record dal livello superiore. Il parametro:PickUpView= indica quale apview utilizzare nella finestra che verrà aperta per la selezione dei record da ereditare. Le due opzioni command OK e Cancel devono essere inserite quindi nelle action della apview specificata in PickupView. Per le action di tipo Lookup, Pickup e DoAction chiede conferma prima di eseguire le action command=OK Esegue senza chiedere conferma
ActionType=PickUp
Command
Confirm
True False ^
ApFieldView
Nome FieldName * Active Valore True ^ False
Significato
Indica quale campo della tabella verrà utilizzato in questo oggetto Indica al server se comunicare all'interfaccia i dati di questo oggetto. In caso di ACTIVE=FALSE, l'interfaccia non saprà mai che questo oggetto esiste. Può essere utile per disabilitarlo completamente senza però eliminarlo dall lista dei campi della pagina per possibili riusi futuri. Indica se il campo è di sola lettura. Il server non accetterà nessuna modica a questo campo Permette di attivare un filtro di ricerca dinamico per l'utente che debba restringere la visualizzazione dei record solo a quelli rispondenti a determinate condizioni. Quando viene attivata a True questa specifica, il campo in questione viene elencato in una lista di campi editabili prima di ogni altro oggetto della pagina. Vengono anche aggiunti i pulsanti filtra e reset che permettono di attivare o meno il filtro impostato. Per ogni pagina possono esistere più campi con questa proprietò a True, i valori immessi nel criterio di ricerca sono combinati con l'operatore logico AND. Allinea a sinistra il valore nel campo Allinea al centro il valore nel campo Allinea a destra il valore nel campo Specifica un formato di decimali e di separatore migliaia. In caso di pagine di tipo TAB, CheckTab, Grid, viene creata in fondo alla griglia una riga aggiuntiva che mostra il totale dei valori elencati.
ReadOnly Searchable
True False ^ True False ^
Align
L^ C R
EditFormat Aggregate
#,##0.00 SUM
Pag. 16 di 24
15/11/06
MosaicoX: appunti per la gestione dell'interfaccia
ApFieldView
AVG In caso di pagine di tipo TAB, CheckTab, Grid, viene creata in fondo alla griglia una riga aggiuntiva che mostra la media dei valori elencati. Il valore specificato viene inserito nel nuovo record generato dalla action NEWRECORD. Inserendo un ! Davanti al valore viene attivata una procedura che elabora il valore di default secondo questi parametri:!NOW e !Today, Now inserisce data e ora corrente, Today inserisce solo la data corrente. E' possibile anche inserire un valore di default partendo da un campo di una tabella e ricavando il recid del record corrispondente: !RECIDOF(Tabella,Campo,Valore) ritorna il recid del record della tabella "Tabella", che risponde alla condizione CAMPO = VALORE.
DefaultValue
Required
True False ^
Indica se il campo deve essere compilato obbligatoriamente. In questo caso, se il campo sarà vuoto la action di dipo SAVE non viene eseguita e viene dato l'elenco dei campi obbligatori.
Server.Expression 