Superclasse form base per programmi gestionali (e non)

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):
Codice: [Seleziona]

Stato iniziale = browse (sola letura) <-+ <-+
 |                                      |   |
 +---> Insert --+                       |   |
 |              |                       |   |
 |              +-> Conferma Insert ----+   |
 |              |                       |   |
 |              +-> Annulla Insert    --+   |
 |                                          |
 +---> Edit   --+                           |
                |                           |
                +-> Conferma Edit ----------+
                |                           |
                +-> Annulla modifiche ------+              


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

valoresignificato
bfgmDisabledvalore usato per disabilitare tutti i controlli (non dovrebbe mai essere usato in casi normali)
bfgmBrowsemodalità browse: non sono ammesse modifiche
bfgmInsertmodalità inserimento
bfgmEditmodalità modifica di un record esistente
bfgmDeleteeliminazione di un record esistente
bfgmWorkInProgressesecuzione di una procedura in corso
bfgmReportInProgressstampa in corso
bfgmConfirmInsertInProgressconferma di un nuovo record in corso
bfgmConfirmEditInProgressconferma delle modifiche di un record esistente in corso
bfgmCancelInsertInProgressannullamento dell'inserimento in corso
bfgmCancelEditInProgressannullamento 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

azionedescrizione
acUser_Insertazione che permette l'inserimento di un nuovo record
acUser_Editazione che permette la modifica di un record esistente
acUser_Deleteazione che permette l'eliminazione di un record esistente
acUser_Refreshrichiesta di refresh
acUser_Reportazione che permette la generazione di un report



Category: Edit
azionedescrizione
acUser_Confirmrichiesta di conferma (dell'inserimento o modifica)
acUser_Cancelrichiesta di abbandono (dell'inserimento o modifica)


Category: Navigation
azionedescrizione
acUser_Firstazione che permette lo spostamento al primo record
acUser_Priorazione che permette lo spostamento al record precedente
acUser_Nextazione che permette lo spostamento al record successivo
acUser_Lastazione che permette lo spostamento all'ultimo record


Category: Stateless

azionedescrizione
acUser_Helpazione 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
Codice: [Seleziona]
svn checkout svn://svn.code.sf.net/p/lazarusiug/liug/trunk/baseform lazarusiug-liug


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.

SMF 2.0.8 | SMF © 2011, Simple Machines
Privacy Policy
SMFAds for Free Forums
TinyPortal © 2005-2012

Go back to article