Newsgroup: it.comp.lang.delphi
Titolo: L'interfaccia utente (lunghetto)

Ciao a tutti,
non so quanto questo POST possa interessare/essere di aiuto a qualcuno ma mi
piacerebbe riuscire a cogliere qualche consiglio (o parere) da voi.
Fino a ieri ho sempre sviluppato applicativi per piccole e medie aziende con
infrastrutture classiche: rete aziendale100 mbit e computer abbastanza
potenti sviluppando, nella maggior parte dei casi, applicazioni che si
appoggiavano a sistemi esistenti (ACG su AS/400, G1 zucchetti,...).
Lo sviluppo funzionava bene nell'ormai collaudato sistema client/server
sviluppando con Delphi 5 ed utilizzando ADO/BDE su tabella Sql Server,
Paradox, Interbase a seconda dei casi.
Lei mie maschere erano abbastanza semplici e *a detta degli utenti*
gradevoli. Per un'anagrafica clienti fornivo una griglia contenente la lista
dei clienti con, in basso alla finestra, un TPageControl che visualizzava i
dettagli del cliente (magazzini, zone di vendita, ...). Il numero di record
visualizzati variava a seconda del tipo di problematica da affrontare ma non
superava mai i 1000-2000 record per griglia quindi le performances erano
assicurate e all'utente venivano messe a disposizione tutte le funzionalità
che normalmente sono richieste (ricerce, stampe, bottoni di editing,...).
Qualora un'utente voleva modificare/aggiungere un record veniva visualizzata
una finestra modale con tutti i campi necessari.
Ho passato molto tempo a cercare di mettere a punto delle *interfacce
utente* gradevoli ma altamente produttive: oramai i tempi di sviluppo delle
maschere con le funzionalità standard (add, edit, delete, find,...)
richiedeva al massimo 2 ore per quelle più complesse (comprese le form
modali per l'editing).
Tecnicamente sviluppavo al minimo 3 oggetti chiave: 2 TForm (una per la
griglia e una per l'editing) e 1 TDataModule con una TQuery (visualizzata in
griglia) e una TTable (sincronizzata al momento dell'editing).
Ora è arrivato Delphi 6 (con dbExpress) e, fortuna vuole, ho la possibilità
di sviluppare per aziende di grandi dimensioni.
Con Delphi 6 le cose cambiano se voglio abbandonare il BDE: devo risparmiare
risorse! Non posso permettermi di aprire query megalitiche anche perchè le
aziende per cui sviluppo hanno diverse sedi collegate tra loro (in alcuni
casi via ISDN = 5 kbit/s) e il numero di utenti collegati è notevole! (oltre
centinaia di migliaia di record) e, come se non bastasse, dovrò anche
cercare di integrare i miei software con SAP!
Premesso che sicuramente lo sviluppo client/server non basta ma dovrò
utilizzare un sistema multi-tier la mia maggior preoccupazione è come
sviluppare un'interfaccia funzionale che però mi richieda sempre un tempo
*limitato* di sviluppo.
Fino a ieri utilizzavo tutti i controlli standard (TDBEdit, TDBMemo,...)
perchè tanto sapevo benissimo cosa visualizzare/editare (passavo sempre
prima dalla griglia).
Ora sono costretto a mostrare all'utente la classica form mono-record dove
sarà lui a decidere se vuole aggiungere/modificare/cercare/eliminare!
Premesso che non voglio visualizzare l'ultimo record inserito e vorrei anche
permettere all'utente di cercare un record in base alle informazioni
inserite in alcuni campi della form (dopo aver cliccato il classico bottone
FIND) secondo voi che direzione devo prendere per sviluppare in modo
abbastanza rapido ?
saluti
Solid Snake IT
"Nemo mortalium omnibus horis sapit" (Plinio il VECCHIO)


Non so se ho capito ma.. hai pensato ad una gerarchia di form del tipo:
Form1: form bianca senza nessun controllo solo un modalresult
Form2: Deriva da form1 ma con la gestione del menu e dei vari pannelli di
contorno
Form3: deriva da form2 con preprietà dataset e datasource e perchè no anche
datamodule  un navigatore che ti permette edit post ect ect
form4: deriva da form 3 ma solo ricerca restituisce un dataset
form5: deriva da form 3 ma solo ricerca restituisce una stringa (pick su db)
e così via in questo modo ad ogni nuovo progetto hai tutta la pappa pronta
ogni volta e alla bisogna derivi da una o dall'altra form in base a quello
che ti serve.
Per quanto riguarda l'interfaccia utente penso che quello sia a tua
discrezione una volta che la tua form ti fa tutti i coontrolli sopra ci
butti quello che vuoi
Sperando di non aver scritto cavolate ti saluto
SALUTI

 wrote in message
9qfdh3$cjn$1...@pegasus.tiscalinet.it...


Crea un form con una dbgrid.
Per vedere dei dati l'utente deve impostare dei criteri in base ai
quali verra' costruita una query che mostra il risultato nella griglia.
Ad esempio, sui clienti potresti mettere come filtri:
ragione sociale (qui puoi usare una like!)
partita iva
citta
nazione
Se l'utente non specifica almeno un criterio, la ricerca non parte.
Un bel pulsante cerca et-voila': i dati sono serviti.
Se si clicca 2 volte su una riga, si apre una seconda form che mostra
i dettagli.
In questa form puoi mettere un pagecontrol; la attivazione delle query
che mostrano i dati in dettaglio puoi legarla alla show di ogni singolo
tabsheet del form di scheda.
Su entrambe le form un bel pulsante per aggiungere o eliminare un record.
Per ogni form un datamodule con query ovviamente diverse.
Se poi hai l'esigenza di avere ad esempio + form di scheda cliente aperti
nello stesso tempo, la cosa si complica un pochino...
Saluti
AS
-- 
Posted from  [212.177.19.163] 
via Mailgate.ORG Server - 
http://www.Mailgate.ORG

La tua non è una cattiva idea, mi farebbe cambiare di poco la logica delle
mie applicazioni. Certo, se un utente mi chiede TUTTO allora deve aspettare
un bel po ma quelli sono c... suoi.
Inoltre, per rispondere anche all'e-mail di Juba, io già utilizzo delle
classi (non macro-classi stile TForm modificata per la particolare esigenza)
ma un set di componenti sviluppati su misura per le mie necessità (lookup,
Tdbedit,...).
Per ora vi ringrazio e, se le cose vanno come credo, mi rifarò vivo con
qualche novità...
grazie e ciao


abbastanza rapido ?
Una soluzione che si puo' adattare al tuo caso sono i layer di
astrazione dalla base dati. Sono dei frameowork che "mascherano"
l'accesso al DB attraverso delle classi, su cui poi tu realizzi le tue
classi. Sono, in genere, framework pensati per grosse app, quindi si
interfacciano in maniera abbastanza efficiente al DB, tutto avviene
tramite SQL puro, ed e' abbastanza facile sotituire l'engine
sottostante (BDE, ADO, IBX, DBISAM, ASTA, ...)
Io te ne posso consigliare alcuni:
- Bold, molto complesso, e' il + completo che conosco
- Object Sight, non ti so dire molto, sembra + limpido di Bold ma e'
ancora acerbo
- Il framework della TechInsite, open source e ben fatto, ovviamente
limitato
Purtroppo mi devo fermare qui, eventualmente possiamo parlarne +
approfonditamente.
Ciao
--
Piero Bonanno
bop...@libero.it
pie...@tiscalinet.it
bpie...@hotmail.com
______________________________________________
"Madame, lei ha tra le gambe uno strumento
che puo' offrire piacere a migliaia di persone,
e tutto quello che sa fare e' grattarlo"
- Sir Thomas Beechan a una violoncellista

>>>>>>e, come se non bastasse, dovrò anche
cercare di integrare i miei software con SAP!<<<<<
scusami se il mio messaggio non è costruttivo, ma perchè cercano di
integrare programmi con il sap anziche svilupparli sul sistema??? la mia
domanda ti è posta da programmatore abap/4 che (anche sostenendo che il
sistema sia pessimo) sa che le possibilità per lavorare sulle tabelle è
pressoche illimitata.
ciao
--
Roberto Gibertini
TOGLIMIrober...@email.it
Home page personale (che fa schifo ma non mi va di metterci le mani)
http://digilander.iol.it/scionn/
Home page del NG free.it.vegetarianesimo
http://digilander.iol.it/fiveg

 integrare programmi con il sap anziche svilupparli sul sistema???
Beh! Qui usciamo un attimo dal discorso Delphi ma ne vale la pensa spendere
qualche parola.
SAP è stato costruito ad-hoc per le aziende cui lavoro (è un grande gruppo).
Oltre alle loro implementazioni so già che ci saranno altri programmi
"satellite" da creare (e sono due o tre per cominciare) che non sono stati
fatti per motivi di tempo e anche economica (se eri programmatore "abap" sai
benissimo anche quanto usta sviluppare delle verticalizzazioni SAP.
Quindi la mia scelta è quella di agganciarmi a BW (OLAP) per reperire le
informazioni statistiche che mi servono...il resto delle tabelle che andrò a
creare non centreranno niente con SAP.
Premesso che devo ancora "tentare" di agganciarmi a BW (e credo non sia
difficile con il driver ADO per OLAP) dopo arriverà il bello: avere le
specifiche dei cubi OLAP!!!
Tu che eri nel giro "SAP" cosa ne pensi ?
ciaooo
Solid Snake IT

>>>>Premesso che devo ancora "tentare" di agganciarmi a BW (e credo non sia
difficile con il driver ADO per OLAP) dopo arriverà il bello: avere le
specifiche dei cubi OLAP!!!
Tu che eri nel giro "SAP" cosa ne pensi ?<<<<<<
io sono tuttora nel giro di sap, sono programmatore abap come consulente e
lavoro con il delphi(stò iniziando ma spero di diventare bravo) so che i
programmatori abap costano parecchio, sò anche però che si riesce a fare
quasi qualsiasi cosa con le verticalizzazioni, soprattutto per dati
statistici ci sono dei moduli appositi, alcuni datawarehouse ad esempio,
esistono anche possibilità di connettersi al sap con programmi esterni,
esistono infatti le bapi (come le api) solo che la maggior parte degli
amministratori di sistema sap non ti darà mai i permessi per tirare fuori
dati interessanti o per utilizzare programmi interni.
sinceramente io non conosco molto di ado e olap, l'abap è un linguaggio
semplicissimo e molto logico, le istruzioni sono poche e le funzioni sono
tutte interne al sistema è molto ben documentate, si può fare praticamente
tutto sul sap, con le funzioni interne senza ricorrere a conoscenze su
database o tecniche particolari di programmazione, anche la programmazione
ad oggetti è stata per me una bellissima scoperta.
comunque sia se ti può essere utile saperlo, non hai problemi di risorse
utilizzando i programmi delphi sulle tabelle sap, il sap è un linguaggio (e
un sistema) interpretato, e tutte le applicazioni girano su un unico
application server, ogni computer può ancora sopportare quaindi qualsiasi
carico di lavoro, e soprattutto se avessi bisogno di un'applicazione client
server, il server dove starebbe il server sql non dovrebbe avere problemi a
sopportare un pò di lavoro in più, nelle aziende che ho visto io su cui
avevano sap i problemi di hardware non si vedono di frequente, anche perchè
il sap fa un uso intensivo di risorse fisiche (esagerato direi) qu8indi se
proprio ti servisse un altro server  e li fai risparmiare con il tuo
programma non credo faranno troppi problemi a fornirtene uno.
ciao non so se è indicato restare qui a discutere, se credi sia troppo OT e
vuoi continuare la discussione puoi scrivermi in pirvato, sotto il mio
indirizzo.
