Newsgroup: it.comp.java
Titolo: Il problema dei codici comuni e province....

Vi giro una mail che ho spedito qualche giorno fa, circa l'inutilità di
codificare entità e la relativa difficoltà introdotta nel trattamento dei
dati così gestiti. Ho sostituito i nomi di persone e società con XXX. Mi
date un conforto morale?
Ciao,
Comunque, il problema di dover registrare i codici istat di Comuni e
Province anziché la loro descrizione è un problema ricorrente negli
applicativi in XXX. Nel web è molto più complesso da realizzare, non
essendoci logica client (e combo ripopolabili dinamicamente).
Ok comunque per risolvere il problema come concordato:
1) normalizzazione della descrizione inserita dall'utente (rimuovendo spazi
in testa, spazi doppi tra le parole, e spazi in fondo)
2) controllo dell'esistenza del comune sulla base dati attraverso
descrizione e codice provincia, e rilevamento del codice in caso di record
individuato.
3) Inserimento su db del codice istat se la validazione ha successo.
La registrazione del codice istat del comune e della provincia anziché
mantenere su db la loro descrizione così come inserita dall'utente, viene
sempre richiesta (purtroppo) e non ho mai capito quale utilità abbia
rispetto alla registrazione della descrizione libera.
Se ciò è voluto per evitare che l'utente sbagli l'inserimento di un dato,
ipotizzando quindi un migliorando nell'usabilità, in realtà l'effetto che si
ottiene è (secondo me) proprio l'opposto: l'utente tende a sbagliare non
solo gli spazi ma anche le lettere doppie, le vocali, le lettere accentate,
gli apostrofi, etc... E poi capita sempre l'utente che inserisce un comune
non presente in archivio (magari un comune nuovo) impedendogli quindi di
procedere nell'uso del programma. Oltre al fatto che ciò introduce anche il
problema di dover manutenere la base dati, dovendo aggiungere i comuni nuovi
e scartare quelli scomparsi (alias non più abitati da tempo).
In genere dopo pochi tentativi in cui si segnala di non aver trovato il
comune, l'utente comincia a spazientirsi, chiude il browser e addio!
Quando hai tempo, ci passi le tabelle dei comuni/province ?
Ciao & grazie :-)
~Luigi
Nota: qualcuno di voi sul newsgroup sa dirmi che diavolo di utilità può
avere avere una tabella del genere
codiceIstat descrizione
1                  TO
2                  MI
3                  NA
4                  RM
5                  PD
.... .... .... ....
Cioè la sigla provincia è già essa stessa un codice... che cavolo di senso
ha avere una tabella di trascodifica (che usa il codice istat) per
ricodificare le province????
Meno male che non ho una tabella di ricodifica dei codici istat, se no ero
apposto :-).
E che diavolo di utilità ha avere tabelle dei comuni??? L'utente queste
informazioni le deve inserire a mano liberamente. Ho già implementato
soluzioni diverse per risolvere il problema (campi testo che si trasformano
in combobox con la lista dei comuni trovati, tipo quelle usate su
www.trenitalia.com
) Ma certe soluzioni si possono implementare quando
davvero sono utili (appunto la ricerca di un luogo di partenza e un luogo di
destinazione), è completamente inutile voler codificare il comune di
un'indirizzo di un utente... se lo scrive sbagliato peggio per lui! non si
può pretendere di correggere ogni dato che l'utente inserisce: ciò vuol dire
anche appesantire enormemente l'applicazione. Inutilmente. IMHO...
Voi che ne pensate?
Luigi

 .... .... .... ....
Beh, avere delle Primary Key collegate al dominio e' una pessima 
pratica: le Primary Key dovrebbero essere le unita' piu' facilmente 
gestibili dal DB, tipicamente degli interi (long).
Se sono due tabelle diverse 1:1, io pero' ne farei una sola.
ciao
uL


Io in questo caso non avrei definito nemmeno la tabella (se non ce n'è una
reale necessità): lascerei l'utente libero di digitare la provincia,
semplicemente perché lo trovo più comodo di sceglierla da una combobox.
Cioè... se l'utente mi scrive
Comune : Cosenza
Provincia : MI
Non mi metto a controllare se
1) sul DB ho Cosenza o qualcosa di simile
2) Se cosenza è in provincia di MI
per poi registrare su DB
Utente {
  Nome : pippo
  Comune: 10238 // codice di cosenza
  Provincia: 298 // codice di Milano (o di cosenza)
}
(quei codici non significano niente, sono solo una rottura da dover
decodificare ogni volta in visualizzazione x poi ricodificarli numericamente
su DB)
Registrerei invece
Utente {
  Nome : pippo
  Comune: Cosenza
  Provincia: MI
}
E chi se ne frega se cosenza non è in provincia di Milano: visto che si
tratta di un applicativo per richiedere finanziamenti allo stato, che
facciano un po' di attenzione questi utenti, se vogliono il grano...
Immaginate un comune come "Castel Sant' Angelo Marittima"
L'utente lo scrive "S.Angelo Marittima" o "Castel Sant Angelo" non lo
troverà mai più sul DB... Al terzo submit che il sistema gli risponde
"comune non trovato"... addio.... l'utente compila il modulo in formato
cartaceo e saluti a internet.
Lo so che si usano i match code per evitare i miss spelling (accenti,
lettere doppie, vocali, etc...), ma avendo 15 giorni a disposizione per
consegnare...
Già così com'è l'utente al primo accesso deve cambiare la password
inviatagli via mail dal sistema, e tale password dev'essere:
- essere di almeno sei caratteri
- essere diversa dal nome utente e dalla denominazione
- essere diversa dalla precedente
- contenere numeri e lettere
Secondo me anche quì, al terzo submit ci becchiamo un bel vaff.... Secondo
me st'applicativo è pensato per non essere utilizzabile.
Ho già fatto presente la cosa... non mi stupirò quando vedrò che solo 3
utenti che hanno utilizzato l'applicativo e gli altri hanno inviato il
modulo via fax (è piuttosto frustrante).
La soluzione è utilizzare dei textfield che selezionano con LIKE su DB e
quindi ripropongono una lista di match probabili in una combobox dalla quale
l'utente sceglie quella più appropriata... ora però, visto che il sistema
così come desiderato dall'utente (un layout engine proprietario e MOOOLTO
limitato) impedisce la scrittura di componenti riutilizzabili (TAGs & Co.)
vuol dire che devo fare un po' di copia e in colla, visto che in metà delle
pagine ho comune e provincia da inserire... E poi c'è il discorso che ad
ogni submit devo fare un po' di query con "like" (non indicizzabili) per
controllare comuni e province, tirando fuori dal db dati inutili...
Vabbé.... qualcuno di voi si sta godendo le ferie almeno ? :-)
Ciao!
Luigi
P.S. Cerco soci per aprire una pizzeria :-)

 semplicemente perché lo trovo più comodo di sceglierla da una combobox.
La richiesta iniziale era:
L'utente seleziona la provincia e il sistema ripropone in una combo tutti i
comuni della provincia selezionata. L'ho già fatto tempo fa utilizzando
un'applet con tecnologia LiveConnect, in cui Bruno mi ha aiutato. Ma.... non
si vogliono applet (e meno male)... Ma che esigenza ci sarà mai di impedire
all'utente di premere i tasti sulla tastiera? Le prossime interfacce utente
ce le chiederanno "telepatiche". Che imparino ad usare la tastiera questi
utenti...


Ciao,
    Bruno.
---
| Bruno Bossola 
| A Java Software Engineer :-)
| 
http://digilander.iol.it/bbossola
|
| Membro del JUG Torino - 
http://www.jugtorino.it
|