Italian community of Lazarus and Free Pascal

Una form dai comportamenti predefiniti

Quando si sviluppa una applicazione destinata ad avere un certo numero di form, è bene prevedere che tutte abbiamo lo stesso comportamento. Se poi a lavorare sullo stesso progetto c'è più di uno sviluppatore allora un metodo comune di lavoro diventa obbligatorio.
Solitamente si dice che si devono definire degli standard di sviluppo.

Per ottenere questo possiamo sfruttare l'ereditarietà dell'oggetto TForm. L'esempio che segue è basato sulla mia esperienza e ovviamente non è l'unico modo possibile.

Il comportamento cercato
Nello sviluppo di un ipotetico gestionale bisogna tener conto anche dell'utente finale. Oggi si stanno diffondendo GUI in cui solitamente, tramite tasto destro del mouse e quindi click su "Properties", si accede alla maschera che permette di modificare i campi di un certo record. Nel gestionale secondo me è meglio un approccio che tenga conto dello stato della maschera. Se pensiamo ad una fattura ad esempio è chiaro che per modificarla abbiamo bisogno di una richiesta esplicita, non è ipotizzabile che con "Properties" ci si trovi già in modifica.
Per questo ho diceso di impostare un comportamento predefinito basato sullo stato della maschera (segue esempio):


Riepilogando, attualmente una maschera può assumere i seguenti stati (valori di TBaseForm_GuiMode):

valore	significato
bfgmDisabled	valore usato per disabilitare tutti i controlli (non dovrebbe mai essere usato in casi normali)
bfgmBrowse	modalità browse: non sono ammesse modifiche
bfgmInsert	modalità inserimento
bfgmEdit	modalità modifica di un record esistente
bfgmDelete	eliminazione di un record esistente
bfgmWorkInProgress	esecuzione di una procedura in corso
bfgmReportInProgress	stampa in corso
bfgmConfirmInsertInProgress	conferma di un nuovo record in corso
bfgmConfirmEditInProgress	conferma delle modifiche di un record esistente in corso
bfgmCancelInsertInProgress	annullamento dell'inserimento in corso
bfgmCancelEditInProgress	annullamento delle modifiche in corso

Le azioni di un utente
Riguardo all'uso dei menù o dei bottoni, è meglio non precludersi nessuna delle due strade. Per questo motivo verranno sfruttate le Azioni. Queste possono essere abbinate sia alle voci di menù che ai bottoni: impostando un comportamento automatico delle azioni, avrò, gratis, menù e bottoni abilitati o disabilitati di conseguenza.
Quindi per ogni azione che l'utente ha a disposizione, troviamo una TAction (facente parte di una action list).
Queste sono categorizzate a seconda dello stato della maschera attualmente visualizzata.

Category: Browse

azione	descrizione
acUser_Insert	azione che permette l'inserimento di un nuovo record
acUser_Edit	azione che permette la modifica di un record esistente
acUser_Delete	azione che permette l'eliminazione di un record esistente
acUser_Refresh	richiesta di refresh
acUser_Report	azione che permette la generazione di un report

Category: Edit

azione	descrizione
acUser_Confirm	richiesta di conferma (dell'inserimento o modifica)
acUser_Cancel	richiesta di abbandono (dell'inserimento o modifica)

Category: Navigation

azione	descrizione
acUser_First	azione che permette lo spostamento al primo record
acUser_Prior	azione che permette lo spostamento al record precedente
acUser_Next	azione che permette lo spostamento al record successivo
acUser_Last	azione che permette lo spostamento all'ultimo record

Category: Stateless

azione	descrizione
acUser_Help	azione che permette la visualizzazione dell'help

Ogni operazione dell'utente sarà suddivisa in 3 sotto operazioni:
- prima di eseguire (per fare test o precaricare dati)
- esecuzione
- dopo l'esecuzione (istruzioni da eseguire a conclusione dell'operazione, es: invio mail)
Per chiarimenti andate a vedere, ad esempio, il codice del metodo DoInsert.

Come si usa?
L'utilizzo è semplicissimo, non bisogna installare nulla: (1) includere la unit uBaseForm nel progetto, (2) creare una nuova form e (3) nell'editor dei sorgenti, modificare l'ereditarietà della nuova sottoclasse da TForm a TfmBaseForm.

Anche la scrittura del codice è stata lasciata intenzionalmente semplice: si tratta di normale programmazione ad oggetti.
Ogni azione, metodo ed evento sono stati nominati in modo da rispondere ad una precisa convenzione.
Se ad esempio creiamo una form che eredita da TfmBaseForm e vogliamo ad esempio gestire l'inserimento di un nuovo record sappiamo che:
- l'azione corrispondente si chiama: acUser_Insert
- nell'evento OnEcecute dell'azione si lancia un unico metodo: DoInsert
- nel metodo DoInsert, quando presenti, vengono lanciati gli eventi:
  . OnInsertTest    : test che permette di stabilire se l'azione "Insert" è eseguibile
  . OnInsertBefore  : operazioni da eseguire prima dell 'insert vero e proprio (la gui non è ancora in Insert mode)
  . OnInsertExecute : operazioni relative all'insert
  . OnInsertAfter   : operazioni da effettuare dopo che l'insert è stato consolidato sul database

Nessuno di questi eventi è obbligatorio ma OnInsertExecute è necessariamente l'unico evento dove ci si aspetta di trovare del codice.
Quindi bisogna operare nel seguente modo:
1) definire 1 procedura di tipo TBaseForm_NotifyEvent
2) (solitamente nell'OnCreate della form) assegnare il puntatore di questa procedura all'evento

 
Progetto di esempio
Un progetto di esempio è scaricabile da subversion


Oppure lo trovate in allegato sul seguente thread:
http://www.lazaruspascal.it/index.php?topic=1392.0

Il contenuto è il seguente:

TestBaseForm (.lpr e .lpi)	file di progetto
umainform (.pas e .lfm)	form principale
ubaseform (.pas e .lfm)	form con la superclasse da cui ereditare
ubaseformtester (.pas e .lfm)	sottoclasse che eredita da ubaseform

Spoero che la codifica sia sufficientemente autoesplicativa, per chiarimenti basta aprire un thread sul forum.