Newsgroup: it.comp.lang.delphi
Titolo: personalizzazioni di una applicazione per "utente" tramite ifdef

Buonasera
 
Sto valutando un meccanismo per impostare un insieme di regole a livello generale per consentire la personalizzare della mia applicazione.
 
parto da un presupposto : vorrei  compilare la stessa applicazione per diversi utenti (che avranno piccole esigenze diverse) senza  voler "localizzare" alcune personalizzazioni dei form, dei menu , nè nel DB installato presso l'utente ne in un file locale sempre installato sul pc dell'utente per evitare che debba essere necessario fare backup di tali "personalizzazioni" (da parte dell'utente e/o da parte mia) e voler centralizzare nel mio codice sorgente le presonalizzazioni
 
stavo pensando di creare una unit generare dove avere una serie di variabili boolean con cui poter andare a dichiarare  tutti i "parametri personalizzabili" ed un file definizionepersonalizzazioneutenti.inc in cui per ogni utente avere un blocco di 
 
IFDEF UTENTE1
define personalizzazione1
define personalizzazione2e
ENDIF utente1
 
IFDEF UTENTE2
define personalizzazione1
define personalizzazione2e
ENDIF utente2
 
tale file sarebbe incluso nella unit generale
nella unit generale dovrei andare ad inserire tutte le variabili parametrizzabili
 
ifdef personalizzazion1
menusecondario_formxy.campo23.attivo:=false;
endif}
 
 
Il problema è questo. Come faccio a personalizzare tramite unit generale eventuali variabili/campi presenti in form che sono dichiarati in unit successive e che riguardando (ad esempio) solo i FORMX ?
nella unitgenerale ho solo la varibile "ATTIVO" ma in tale unit dei campi del FORMX non vi è traccia
 
in teoria nella unit relativa al FORMX potrei usare una USES unitgenerale ed avere tutti i riferimenti quantomeno dei parametri boolean "ATTIVO" true or false
 
pensate sia fattibile?
o ci potrebbe essere un metodo alternativo ?  (diverso dai 2 succitati , scrivo tutto nel db e/o in un file locale)
 
grazie
 
 
 

> endif}
 
pensi davvero che basti menusecondario_formxy.campo23.attivo:=false;in 
una unit generica con una variabile per ottenere quello che cerchi ?
 
la variabile puoi definirla, ma poi quando vai ad interpretarla come ti 
comporti ? , quella menusecondario_formxy.campo23.attivo:=false; devi
dichiararla come string, altrimenti non la accetta.
 
devi scomporre 'menusecondario_formxy.campo23.attivo:=false' almeno in 3 
parti
menusecondario_formxy
campo23.attivo:=false;
in tante parti riconoscibili e quante if ti servono ?
 
pensa ad un qualcosa di strutturato in modo rigido, tipo XML.
 

 o ci potrebbe essere un metodo alternativo ? 
 
Dipende da cosa, nella tua app, intendi per personalizzazione.
 
Se si tratta di voci di menu che devono essere visibili o nascoste, magari con 
le direttive  te la cavi pure, salvo che tu non  abbia 10.000 menu...
 
Se si tratta di gestire comportamenti diversi per una o piu' funzionalita', cosi su 2 piedi punterei a generalizzare il comportamento, defindendo delle classi polimorfiche che incaspulano le logiche divrse ed identificando ognuna di esse con, ad esempio, il valore di un tipo enumerato. 
 
A quel punto, avresti una finestra di editing delle opzioni generali della tua applicazione e con una combox del kakkio puoi selezionare un valore.
Questo valore lo salvi insieme alle altre opzioni.
Poi, quando la tua app deve fare quella cosa specifica, si legge il parametro, istanzia la classe che corrisponde al valore e la usa.
 
Ovviamente (ma non per tutti) parametri di questo tipo sono da leggere una tantum all'avvio della applicazione solo se **strettamente** necessario.
 
 
A.


quello che penso è relativo poichè non ho grosse esperienze in merito con delphi
infatti ho chiesto dei consigli
 
quella della ifdef era solo una idea per spiegare cosa intendo
potrei usare una variabile dichiarata a livello generale fatta da 1 solo livello
poi nella unit/form menusecondario la testo con una if
 
se ho un qualcosa di strutturato tipo XML non devo testarlo comunque nella "posizione dovuta" ?


si lo so, gestire con le ifdef sarebbe "pesante" in termini di manutenzione
per questo pensavo a delle variabili dichiarate a livello globale, ma non so , una "unit_generale" che ha delle variabili non private , riesce a "farle vedere" ad altre unit successive tramite una "uses"? 
 
sostanzialmente la cosa mi servirebbe per "accendere-spegnere" dei campi su alcuni form, ma non arrivo a 10000 penso neanche a 100  , magari 10/20
un debug fatto su un form con campi "semplici" la cui differenza sia acceso/spento penso possa creare poche difficoltà
 
interessante è invece gestire eventuali comportamenti diversi.
se usassi queste classi polimorfiche , riuscirei a gestirne le "diversità" tramite parametro enumerato dichiarato a livello generale tramite una variabile ?
 
esempio, una unit_generale  dove c'è
var
 
parametro_funzione_polimorfaXY_enumeratore:=20;  //valore di default
comportamento standard  del form FATTURE
 
{$ifdef utenepippo}
parametro_funzione_polimorfaXY_enumeratore:=30;  //valore comportamento del form fatture per utente pippo
{$endif}
 
 
 
le ifdef in questo caso le userei solo nella unit generale che dovrebbe essre utilizzata (uses) da tutte le unit che usano form personalizzabili quindi nessuna ifdef nelle altre unit ma solo nella unit generale
 
poi, nella unit form_fatture ho la funzionepolimorfayx a cui passerei il "parametro_funzione_polimorfaXY_enumeratore"

 variabile ?
 
Come dicevo prima, DIMENTICA LE VARIABILI GLOBALI E LE UNIT.
La soluzione, è avere una classe che descrive ci' che ti serve.
Poi, questa classe è passata tramite una apposta property ai tuoi form. 
Se hai usato la WFI ti basta mettere la property nell' ancestor cosi la vedono tutti.
Quindi:
 
1) I form espongono poi un metodo di setup che in funzione della classe di cui sopra attiva o disattiva le funzionalità.
 
2) se al click di un pulsnate devi fare una cosa il cui comportamento dipende da uno dei parametri del descrittore fai:
 
a) leggi il valore
b) in funzione del valore istanzi la classe che ti serve
c) usi l'istanza
d) la distruggi
 
Qua poi ci sarebbe tanto da dire sui concetti di class factory e molto altro.
 
A.
 
 
 

 
 
grazie cmq.. è già una buona strada credo!! devo solo approfondirla , dimenticando le variabili globali!!:)

 cosa è WFI ?
 
Ho scritto male: VFI.
 
A.

 Onestamente, me ne frego, e MALEDICO ogni giorno la possibilità offerta da delphi di lavorare in strutturato, cosa non prevista ad esempio in c# e java.
 
...non prevista in C# e in Java, dove mi è capitato di vedere gente che implementava la logica scrivendo esclusivamente metodi statici in classi statiche.
 
Non è un problema del linguaggio: OOP è uno "stato mentale". :)
 
-- 
MARCO BREVEGLIERI (Software and Web Developer)
#Home: 
http://bit.ly/marcobreveglieri
 
#Blog: 
http://bit.ly/compilaquindiva