Written by nomorelogic Agosto 28, 2014, 07:27:00 pm21729 ViewsRating: 0 (0 Rates)Print
Ora che lo scheletro di una superclasse form da ereditare è pronto andiamo a vedere cosa succede se vogliamo implementare le seguenti caratteristiche:
gestione dei log automatica
potenziamento della gestione delle eccezioni tramite il salvataggio - nel log - dello stack dell'eccezione
prevedere un oggetto tipo "toolbox" da passare alle istanze delle form
toolbox Iniziamo dalla fine. Pensando all'implementazione di nuove caratteristiche direttamente all'interno della superclasse non si può fare a meno di pensare di prevedere una classe esterna, che sopravviva a tutte le istanze delle varie form dell'ipotetico gestionale. Questa classe che chiameremo TBaseForm_ToolBox avrà diversi compiti:
sarà un repository di codice che dovrà essere comune a tutte le form (ad esempio, la generazione di una stringa che rappresenta lo stack quando c'è un'eccezione)
sarà il manager delle impostazioni delle form (ad esempio, la path del salvataggio del log)
varie ed eventuali...
Questa sarà la prima classe che verrà istanziata dall'applicazione e la prima che verrà valorizzata. Solo successivamente verranno create le form (sottoclassi di TBaseForm) le quali si autoconfigureranno secondo le impostazioni che troveranno nell'istanza della "toolbox".
Segue un esempio di codice dove la toolbox viene istanziata e vengono inizializzate alcune proprietà, tra cui, la path del log che dovranno rispettare tutte le form.
Caption := bftoolbox.LogPath; if not ForceDirectoriesUTF8(bftoolbox.LogPath) then ShowMessage('Directory' + LineEnding + Caption + LineEnding + 'non creata!');
end;
gestione automatica dei log Se andiamo a rivedere l'articolo precedente notiamo che ogni azione che l'utente può richiedere è suddivisa in sotto-azioni (che in realtà sono eventi). Ad esempio la conferma di una operazione di insert viene effettuata con il seguente schema:
test (es: verifica che i dati inseriti siano congrui)
before (es: operazioni preliminari come la determinazione di un protocollo)
execute (es: salvataggio vero e proprio)
after (es: operazioni successive)
Sicuramente vi sarà capitato di dover indagare per un bug o per un collo di bottiglia ed altrettanto sicuramente avrete pensato che un log con tanto di tempi vi avrebbe aiutato molto nel lavoro. Cosa c'è di meglio quindi che implementare un log trasparente? Il log viene così gestito:
procedure TfmBaseForm.DoConfirm; var SaveGuiMode: TBaseForm_GuiMode; BFCR: TBaseForm_BFCR; begin SaveGuiMode := GuiMode; try // create record for intermethod communications with BFCR do begin Test.result:=TRUE; Test.CanForce:= FALSE; Test.MsgTestFailed:=''; Test.MsgToForce:=''; end;
// test if Assigned(OnConfirmTest) then try if Assigned(FEventLog) then FEventLog.Log('DoConfirm / OnConfirmTest'); OnConfirmTest(Self, BFCR); if not BFCR.Test.result then if Assigned(FEventLog) then FEventLog.Log('DoConfirm / OnConfirmTest / Test Failed'); if BFCR.Test.CanForce then begin if MessageDlg('ATTENTION', BFCR.Test.MsgTestFailed + #10#10 + BFCR.Test.MsgToForce, mtConfirmation, [mbYES, mbNo], 0) mrYes then exit; if Assigned(FEventLog) then FEventLog.Log('DoConfirm / OnConfirmTest / Execution Forced'); end else begin if BFCR.Test.MsgTestFailed '' then ShowMessage(BFCR.Test.MsgTestFailed); exit; end; except on e: exception do begin raise TBaseForm_Exception_ConfirmTest.Create('Where: TEST FOR CONFIRM' + #10 + e.Message); end; end;
// set gui case SaveGuiMode of bfgmInsert: GuiMode := bfgmConfirmInsertInProgress; bfgmEdit : GuiMode := bfgmConfirmEditInProgress; end;
// before Confirm if Assigned(OnConfirmBefore) then try if Assigned(FEventLog) then FEventLog.Log('DoConfirm / OnConfirmBefore'); OnConfirmBefore(Self, BFCR); except on e: exception do begin raise TBaseForm_Exception_ConfirmBefore.Create('Where: BEFORE CONFIRM' + #10 + e.Message); end; end;
// Confirm if Assigned(OnConfirmExecute) then try if Assigned(FEventLog) then FEventLog.Log('DoConfirm / OnConfirmExecute'); OnConfirmExecute(Self, BFCR); except on e: exception do begin raise TBaseForm_Exception_ConfirmExecute.Create('Where: EXECUTE CONFIRM' + #10 + e.Message); end; end;
// after Confirm if Assigned(OnConfirmAfter) then try if Assigned(FEventLog) then FEventLog.Log('DoConfirm / OnConfirmAfter'); OnConfirmAfter(Self, BFCR); except on e: exception do begin raise TBaseForm_Exception_ConfirmAfter.Create('Where: AFTER CONFIRM' + #10 + e.Message); end; end;
GuiMode := bfgmBrowse;
except on e: exception do begin ManageException(e); GuiMode := SaveGuiMode; end; end; end;
Per l'attivazione invece si è ricorso al "toolbox" e ad una proprietà particolare di nome Behavior (di tipo set). Possiamo quindi assegnare 2 valori a Behavior:
bfb_InstanceLog: fa il log delle singole istanze, ogni volta che istanziamo una form avremo un nuovo file con il suo log
bfb_ClassLog: fa il log della classe, il file è sempre lo stesso e viene sovrascritto
nomorelogic registered at Italian community of Lazarus and Free Pascal on Marzo 10, 2012, 12:27:59 pm and has posted 2908 posts in the boards since then. Last visit was Oggi alle 09:27:39 am.
Questo blog non rappresenta una testata giornalistica poiché viene
aggiornato senza alcuna periodicità. Non può pertanto considerarsi un
prodotto editoriale ai sensi della legge n. 62/2001.
Questo sito utilizza cookie, anche di terze parti, per offriti servizi in linea con le tue preferenze. Chiudendo questo banner, scorrendo questa pagina, cliccando su un link o proseguendo la navigazione in altra maniera, acconsenti all’uso dei cookie.