Superclasse form base per programmi gestionali (e non)

[nomorelogic]

ho scritto un articolo sull'ereditarietà delle form ed ho fatto un esempio con un ipotetico gestionale
in allegato il progetto di esempio (per chi non volesse scaricarlo da svn).

L'articolo di riferimento è:
http://www.lazaruspascal.it/index.php?page=152

[xinyiman]

Gran bell'articolo nomore. Bravo

[nomorelogic]

Grazie xinyiman

Segue la seconda puntata: http://www.lazaruspascal.it/index.php?page=153

Argomenti:
- log automatico delle azioni dell'utente
- salvataggio call stack in caso di eccezione (nel log automaticamente)
- toolbox: nuova classe di ausilio per l'inizializzazione delle form

[Legolas]

Ottimo! Quando ho aperto il thread sulle best practices avevo in mente proprio qualcosa del genere! 

Complimenti 

[nomorelogic]

grazie Legolas

immaginavo che servisse qualcosa del genere, in più sto mettendo il tutto sullo stesso progetto... vedi mai che alla fine ne esce qualcosa di buono?!

Spero solo che gli articoli siano chiari, purtroppo scrivo (codice e articoli) sempre con la clessidra che scorre
Vabbè, se ci sono dubbi c'è sempre il forum

[Stilgar]

Poi non dovresti essere solo tu a scrivere il codice
alla fine l'articolo funge anche da specifiche

Sto guardando con curiosità il tuo codice Al prossimo push su svn scarico.
Stavo già pensando a qualche modifica

Stilgar

[nomorelogic]

Beh, se stimola la curiosità è positivo

ho allineato il repository svn, a che modifica pensavi?

[Stilgar]

Ragionare a plug in e non monolitico.
Ma quello quando hai implementato tutte le cose che ti frullano per la testa
Spostare tutto in un datamodel in modo che possa essere applicato anche a form che non estendono "la superdotata" ma possa essere applicata anche a form esistenti
Magari facendo implementare una interfaccia.

Stilgar

[Stilgar]

PS: Il riempimento dello failback stack  dovrebbe essere fatto a livello di applicazione, non di form ...

[nomorelogic]

Ragionare a plug in e non monolitico.
Ma quello quando hai implementato tutte le cose che ti frullano per la testa

in effetti ho in previsione di usare le shared object (.DLL per i windowsiani) per rendere modulare il tutto
ma è ancora presto

Spostare tutto in un datamodel in modo che possa essere applicato anche a form che non estendono "la superdotata" ma possa essere applicata anche a form esistenti
Magari facendo implementare una interfaccia.

in effetti l'uso delle interfacce potrebbe essere un'alternativa
ma in questo modo la cosa si fa comunque e senza cambiare una riga di codice nelle form esistenti
basta cambiare la classe da cui ereditare, da

Codice: [Seleziona]

TForm1 = class(Tform)

a

Codice: [Seleziona]

TForm1 = class(TBaseForm)

e si può premere F9



Edit:
vabbè, il "si può premere F9" è realistico ma va preso con beneficio d'inventario

[nomorelogic]

PS: Il riempimento dello failback stack  dovrebbe essere fatto a livello di applicazione, non di form ...

hai ragione, ma nella zucca mi frulla sempre qualcosa di "strano" che non ha preso una forma definita

I motivi sono 2.

1) Ho deciso di fare così (non l'ho scritto nell'articolo, dannata clessidra!) perchè voglio decidere nella form se far filtrare l'eccezione all'esterno (in modo che sia catturata dall'applicazione) o se... lavare i panni sporchi in casa.
Non è infatti detto che le eccezioni debbano per forza concludersi con un Dialog da sbattere in faccia all'utente: se un giorno uno volesse implementare delle macro (wow) utilizzando le classi esistenti dovrebbe riscrivere tutta da capo la gestione delle eccezioni. Non si può mica fare una macro che ad un certo punto ti chiede una conferma di un errore: o va a buon fine o fallisce (e in un log trovo il motivo).
In questo modo posso istanziare una Form, cambiare il modo di gestire le eccezioni (da GUI a silent) e ho la classe pronta all'uso.

2) Voglio che ogni istanza (non classe ma istanza) gestisca le eccezioni come è meglio in quel caso ed in un file indipendente da tutte le altre istanze.

Visto che comunque la gestione delle eccezioni, come dici anche tu, dovrebbe essere centralizzata, mi sono inventato la classe "toolbox" che fa l'alter-ego dell'applicazione

Edit:
ogni form gestisce a modo suo ma è in "toolbox" che ho messo il dump del call stack

[schumi]

in FoxPro ho sempre usato librerie come base dei gestionali.
non sarebbe male aggiungere anche i bottoni (insert, delete ecc) direttamente in form o una toolbar, che dite?

[nomorelogic]

stavo già studiando come fare

[schumi]

l'ideale è una toolbar che si attiva all'occorrenza con la possibilità di decidere quali funzioni sono attive.
Potrei avere solo bisogno solo di alcune funzioni, oppure bloccare l'insert agli utenti non abilitati. quindi pensavo ad una variabile Public per ogni tasto che attiva disattiva, poi non so se convenga una TToolbar o un frame o dei semplici button...

sono alle prime armi con Lazarus ma se posso dare un mano volentieri...

[nomorelogic]

attualmente, nel progetto che sto sviluppando, quello che un utente può fare è definito dalle azioni
queste saranno abilitate/disabilitate (per utente) a seconda di un sistema di permessi che dovrà arrivare

pensavo di realizzarlo sia come toolbar che come menù