Newsgroup: it.comp.java
Titolo: properties

Ciao a tutti,
ho sempre usato i file di properties come coppie chiave valore, come
ad esempio
nome=Mark
cognome=Owen
e cosi via
mi servirebbe realizzare un file di properties che invece associ ad
una chiave due o più valori, ad esempio
symbol=address, port,protocol
per avere una struttura del tipo
0001=host:localhost
0001=port:8080
0001=protocol:TCP
è possibile, utilizzando  java.util.Properties?
oppure in che modo si potrebbe fare? escludendo chiaramente la
creazione di tre chiavi, una per ciascun elemento
0001host=localhost
0001port=8080
0001protocol=TCP
Grazie


Di solito chi usa properties scrive:
0001.host=localhost
0001.port=8080
0001.protocol=TCP
Tra l'altro a me le properties non piacciono molto perché le trovo 
scomode per fare cose come liste e strutture gerarchiche.
Preferisco usare XML che è gerarchico e che si può leggere senza fatica 
usando xstream.
Hai valutato l'ipotesi codificare l'informazione come url?
0001=tcp://localhost:8080
-- 
Andrea Francia
FtpServerStub ease your FTP Client unit-testing:
http://andreafrancia.it/ftpserverstub/


wrote:

si, in realtà non so ancora come mi arriva questo file, perchè sarà
una risorsa esterna a cui io ho accesso in sola lettura


 una risorsa esterna a cui io ho accesso in sola lettura
Cosa c'entra con la mia domanda? Io intendevo scrivere le url nel file 
properties.



c'entra, perchè il file di properties non lo scrivo io, mi arriva in
sola lettura


 Grazie
Dov'e' il problema?
Per una coppia chiave=valore  il suo delimitatore e' "="
se io scrivo:
Dante=-->qui' tutta la Commedia
avro' una chiave = Dante
ed un valore=tutti i 100? canti della "comedia"
i.e.  symbol=host:localhost,port:8080,protocol:tcp
il valore della chiave=symbol e' 
valore=host:localhost,port:8080,protocol:tcp
come poi ti peschi i valori all'interno di "valore" e' un problema tuo
--
ac

 usando xstream.
Si puo' leggere senza fatica poiche' c'e' uo strumento, xstream, che lo 
fa per te, se ci fosse uno strumento che lo facesse per le properties 
avrebbe la stessa facilita' di uso dell'xml.
Per gestirlo, file di testo "gerarchico",  mi sono bastate poche 
istruzioni, e se lo scrivo correttamente "indentato" e' molto meno 
confuso di un qualsiasi xml.
E con questo *non* voglio sostenere che l'xml fa schifo.
--
ac

 sola lettura
Ma allora cosa vuoi sapere?
Devi definire tu o no il formato del file?


 confuso di un qualsiasi xml.
Puoi fare un esempio di come strutturi il file di testo gerarchico?
Mi interessa il formato, non il codice che lo legge.


 
i.e.
[Fanerogame]
	[.Cucubitacee]
		[.Ecballium]
			[.Ecballium Elaterium]
				NomeVolgare=Cocomero Asinino
				Image=FCE_EE
	[....Asteracee]
		[.Bellis]
			[.Bellis Perennis]
				NomeVolgare=Margheritina,Pratolina
				Tipo=Erbacea
				Image=FAB_BP
 
[Crittogame]
	[.Equisetacee]
		[.Equisetum]
			[.Equisetum selvaticum]
				NomeVolgare=Rasperella
				Rizoma=tuberifero
				Image=NoImage
			[..Equisetum Arvense]
				NomeVolgare=Coda di cavallo
				Rizoma=Tuberifero
				Image=CEE_ES
		[...Licopodiacee.Lycopodium]
			[.Lycopodium Alpinum]
				Fusti=Striscianti radicanti
				Image=CLL_LA
o questo:
[Connessione]
	[.Default]
		driver=com.mysql.jdbc.Driver
		database=jdbc:mysql://localhost:3306/test
	[..MySql]
		driver=com.mysql.jdbc.Driver
		database=jdbc:mysql://localhost:3306/motogp
	[.]
	[.MSSQL2000]
		driver=com.microsoft.jdbc.sqlserver.SQLServerDriver
		[.MotoGP]
database=jdbc:microsoft:sqlserver://localhost:1433;DatabaseName=MotoGP
			SQL=d:\pack\MotoGp\MotoGp.xml
			userid=<%=cryptoGp%>,MD5
			password=<%=cryptoGP%>,MD5
	[...MDB]
		driver=sun.jdbc.odbc.JdbcOdbcDriver
		[.MotoGP]
			database=jdbc:odbc:driver={Microsoft Access Driver 
(*.mdb)};DBQ=d:\pack\MotoGP\MotoGP.mdb
		[..Sounder]
			database=jdbc:odbc:driver={Microsoft Access Driver 
(*.mdb)};DBQ=d:\pack\sounder\SounderData.mdb
	[..Text]
		database=d:\pack\flora\Tassonomia.txt
[User]
......bla....bla
c'e' un mio post di un paio di settimane fa che chiedeva consigli per la 
sua gestione, va da se che nel frattempo mi sono ingegnato.
--
ac

                 Image=FAB_BP
Sapevi dell'esistenza di JSON e YAML? Sono due alternative ad XML più 
semplici da scrivere e da leggere per un umano. Naturalmente ci sono già 
le librerie java per leggerli.



[CUT]
Francamente non capisco perche' debba essere piu' leggibile di un XML,
per non parlare del fatto che i parser XML sono gia' belli che pronti
e gli editor per XML (con vista  ad albero) pure.

 le librerie java per leggerli.
Oddio, JSON  con tutte quelle graffe non mi sembra piu' facile da
leggere. E' invece sicuramente piu' facile da processare in ambiente
Javascript.

 interessa il formato, non il codice che lo legge.
attenzione che le properties sono adatte a contenere informazioni 
statiche, non configurazioni. i file di properties vengono cercati nel 
classpath e (ad esempio) in una applicazione j2ee non puoi modificarli a 
caldo.

 Sapevi dell'esistenza di JSON 
JSON? Non ho approfondito piu' di tanto ma e' stato uno dei piu' grossi 
"sorrisi" che ho avuto. L'ho incrociato leggendo di Ajax.
La storia e' che con un collaboratore ero sempre in lite a causa di come 
venivano pensate le applicazioni web  finche' un giorno il "cichen" e' 
venuto dicendo che Microsoft sosteneva che anche il client doveva fare 
la sua parte.
Non sono stato li a fare il maramaldo ma gli ho risposto che era una 
vita che glielo dicevo.
Tu dirai che c'entra, bene la questione era che, anche eccedendo, le mie 
applicazioni inviavano al cliente "stringoni" delimitati e gerarchici 
(la mia estrazione e' da "mainframes") con una specie di DTD i 
testa,quando serviva, evitando l'xml poiche' mi "puzzava" un po' inviare 
vagonate di caratteri che poi non usavo e perche' mi "ripuzzava" 
parecchio ricaricare l'intera pagina (questo non a causa dell'xml, 
naturalmente).
Ripeto ho guardato di sfuggita JSON e l'ho piantata quando, leggendo, ho 
avuto l'impressione che quel sistema era piu' complicato del mio e piu' 
o meno raggiungevamo lo stesso obiettivo.
L'altro, invece, non lo conosco  ma una cosa che si chiama "YAML" 
(-->cfr "jam") gia' mi fa venire qualche dubbio.  ;-{))
Comunque grazie per la segnalazione gli daro' una occhiata.
Se poi vogliamo parlare di DAO o POJO per non parlare delle ACTION sto 
ancora a rotolarmi sul pavimento e battendo i pugni.
E sto aspettando da un momento all'altro che qualcuno alzi il ditino e 
dica delle jsp quello che diceva Fantozzi della corazzata "potiemchin" o 
"potiomchin" che dir si voglia.
--
ac

cicap ha scritto:

E chi discute della prontezza. I file con i comandi SQL li ho esterni e 
sono rigorosamente XML.
Hai sicuramente ragione per gli editor ma talvolta uso il notepad.
--
ac

rootkit ha scritto:

E mica lo leggo con il resourcebundle. Uso un FileReader qualsiasi che 
va dove gli dico di andare e non dove pare a lui.
E comunque relativamente alle "properties" sono completamente d'accordo.
Riguardo il "tipo properties" (o tipo i vecchi e buoni .ini) la 
questione e' diversa, possono rappresentare tranquillamente un file 
"dati" (cfr es. botanico).
--
ac

comunque, per entrare nel merito, un file xml è circa 3 volte più
"pesante" di un file di properties.
nell'ordine dei kbyte inizia a importare qualcosa

 va dove gli dico di andare e non dove pare a lui. 
questo però è volersi parecchio male :-P
io almeno userei le commons configuration:
http://commons.apache.org/configuration/
e valuterei anche il formato, se avessi la necessità di informazioni 
memorizzate in modo gerarchico.



se usi sax per fare il parsing la cosa non ti tange minimamente.

 o meno raggiungevamo lo stesso obiettivo.
JSON non è altro che la rappresentazione JavaScript di un qualsiasi
oggetto.
Tutto qua.
Il giro è questo (quello piu' comune con AJAX): il server risponde con
una stringa in formato JSON:
out.print("{id: 1, nome: 'Alberto'}");
Il client (ad esempio un browser) deve solo valutare l'oggetto:
var response = eval(s);
e poi processarlo come farebbe con qualsiasi oggetto javascript:
alert(response.nome);
Nulla di meno complicato. E' un approccio non un sistema.

 
Grazie per il suggerimento.
Per quanto riguarda il formato gerarchico, dopo annate passate sul DBMS 
DL1 della IBM con vagonate di indici secondari e puntatori 
first,last,previous,next,parent, firstChild, lastChild, sibling and so 
on  e organizzazioni dati HDAM, HISAM (quelle che mi ricordo) qualche 
ideuzza me la sono fatta.
--
ac

 Nulla di meno complicato. E' un approccio non un sistema.
As you like. Ma cio' che prevede l'utilizzo di componenti attive per me 
e' un sistema. Se JSON e' in grado di utilizzare "json" e "xml" allora 
il sistema JSON avrebbe  due diversi approcci (ai dati).
--
ac

 il sistema JSON avrebbe  due diversi approcci (ai dati).
Non ti seguo molto, perchè JSON non centra nulla con XML. Stiamo solo 
comparando due modi diversi di trasportare dati dal server al client.
Comunque, fermo restando che stiamo parlando di AJAX, non ci sono 
componenti attive...AJAX presuppone che JavaScript sia abilitato, quindi 
chiamare "eval" su una stringa è una cosa normalissima che si è sempre 
fatta. Non richiede alcuna libreria supplementare.

 
http://commons.apache.org/configuration/
Certo che Apache Commons è pieno di cose utili.
-- 
Andrea Francia
http://andreafrancia.blogspot.com/2008/07/colinux-linux-dentro-windows.html

 nascosto governati da un po' di codice, anche quello "hidden".
Stai cercando di dire che AJAX è una tecnologia? Ci sono stati
parecchi dibattiti a riguardo in passato, i puristi dicono che non lo
è.
L'unica novità introdotta da AJAX (a parte l'acronimo stesso) è stato
l'oggetto XHR, del quale tra l'altro è possibile fare a meno persino
per scambiare dati in maniera asincrona (si possono usare iframe o
tecniche simili).

 Certo che Apache Commons è pieno di cose utili.
Non avevi notato che qualsiasi progetto open source di un certo
rilievo (specialmente della Apache) ha 4o 5 dipendenze con questi
stramaledetti commons? Stramaledetti perchè possono creare dei casini
mostruosi se non riesci ad azzeccare la versione giusta.

 tecniche simili).
Ne sto parlando proprio perche' lo ho fatto e lo ho fatto utilizzando 
strutture dati di "tipo" JSON e non XML per i motivi fin qui dibattuti.
E per poterlo fare ho dovuto "necessariamente" scrivere un po' di js per 
gestire il tutto.
Avevo appunto il "framino" ed il "timerino". Ora se questa cosa la 
sbatti dentro un "pacchettino"  lo infiocchetti ben bene e lo chiami 
*acaja* fa la stessa cosa dell'altro solo che il mio metodo invece di 
fare "responseText()" fa "build()" , "getTree(x)" , "updateDOM(x)" e 
"getFromDOM(x)" che cambia? Che uno lo ha fatto Microsoft e l'altro un 
pincopallo qualsiasi la qualcosa non e' esattamente ininfluente. 
Ahhh.... sta roba l'ho fatta prima che si sentisse parlare di AJAX e/o 
JSON e non ho avuto mai voglia o desiderio di sbattermi in giro a 
cantare le lodi dell'Elisir di lunga vita anche perche' fare il 
pacchetto e metterci i nastri colorati mi ha sempre annoiato.
Non so se questo era chiaro.
--
ac

 Non so se questo era chiaro.
Guarda che sono il primo a dire che AJAX è una trovata commerciale, e
non una vera innovazione tecnologica.
Dico anche che la tua soluzione non è scorretta.
Non la userei mai pero': quali vantaggi dovrebbe portarmi rispetto
all'uso di XML oppure JSON?
Con JSON non devo importare librerie, non devo chiamare alcuna build,
posso accedere con maggiore comodità agli elementi. Inoltre siccome è
Javascript, posso visualizzare (che so tramite Firebug) i dati
ottenuti con estrema facilità, posso anche manipolarli con estrema
facilita'.
In sostanza, se l'eleganza conta, la soluzione con JSON è sicuramente
piu' elegante.

 piu' elegante.
Quien sabe? Ripeto l'ho guardato molto superficialmente solo per capirne 
la logica. E tu non puoi sapere cosa facesse (e come) il mio 
"ferrovecchio".
--
ac

 "ferrovecchio".
Stiamo parlando di formati, non di tutto lo strato di librerie che ci
hai scritto sopra. Quello è un formato non standard, che richiede
codice ad hoc per essere trattato, e che non può integrarsi
altrettando bene con altre tecnologie. Questo per forza di cose.

 facilitata o meno da formato scelto?
La risposta e': ma tu sai come sono effettivamente messi i dati in un DB 
(che tra l'altro li mettono in modo diverso e sono l'apoteosi 
dell'entropia)? Probabilmente no, come il sottoscritto, e perche' non ci 
interessa la cosa? Perche' "sarvognuno" ci pensa il parser SQL del DB a 
trovarli per te e "parbleu" ti facilita la cosa. Che, non essendo 
abbastanza facilitata, qualcuno ha pensato che forse era meglio scrivere 
Hibernate cosi' anche mio padre, ormai completamente rincoglionito, 
possa fare i suoi sacrosanti accessi, a cui ha diritto, ad una basedati 
non sapendo manco che e'!
Ed e' esattissimamente la stessa cosa che fanno gli Activex.XML sul file 
di testo XML, indi se JSON mi dice soltanto come dovrei strutturare i 
dati e' la "mappa muta" che ho citato nel post precedente.
Ergo se tu mi dici che la struttura la devi fare cosi' perche le regole 
di "bazzica" dicono questo mi sta bene, Alberto non ha scritto una riga 
di codice, ci hanno pensato i vari Hubble e compagnia a verificare che 
il suddetto Alberto non aveva detto fesserie. Ma Alberto era Alberto(*)!
(*) Se ancora non si e' capito chi era Alberto, di cognome faceva Einstein.
--
ac

 dati e' la "mappa muta" che ho citato nel post precedente.
Ora lo dici in contrapposizione a quanto dico io oppure solo per
ribadire un concetto? Che JSON sia un formato e basta lo vado dicendo
da 10 post. Non prevede librerie supplementari (solo server side
volendo).

 volendo).
Bene allora non ne ho bisogno (anch'io lo vado dicendo da 10 post ;-{) ) 
se non mi da almeno una funzioncina piccola piccola che mi estragga dai 
dati quello che mi serve nel modo in cui mi serve. Sull' XML, per fare 
questo, c'e' una valanga di roba nonche' un "metalinguaggio" a corredo 
(che fine ha fatto l'XSL e' una vita che non ne sento piu' parlare). 
Oltretutto da una pagina JSON che ho visto mi sembra che usi anche 
"delimiters" bloccati e cio' talvolta e' molto limitante nonche' stressante.
Al momento l'unico valore aggiunto e' aver definito una "tavola delle 
leggi". Posso immaginare che in giro ci sia qualche "prodottazzo" che da 
quelle strutture riesca a tirar fuori qualcosa.
--
ac

 quelle strutture riesca a tirar fuori qualcosa.
Secondo me non hai ancora capito che JSON è JavaScript. Parli di
delimiters, ma non ti sei accorto che quella è pura e semplice
sintassi JS. Chiaro che per produrre da Java un JSON sia meglio usare
una delle tante piccole librerie disponibili, altrimenti devi stare
attento alle stringhe, apici e quant'altro.

 
e chi parlava di Java? Io mi sono riferito solo e sempre al lato client 
e quindi "assiomaticamente" a Js.
Come le produco sul server, java o non java, e' solo l'altro lato della 
medaglia. Ma non e' davvero questo il problema. Sul server le "stringo" 
e "unstringo" e non ci faccio particolari manipolazioni sopra, una 
passeggiata avendo a disposizione split e espressioni regolari (che ho 
anche lato js, come ben sai, sono le medesime a parte un paio di "/" in 
piu' e qualche "\" in meno).
 > attento alle stringhe, apici e quant'altro.
e' il quant'altro che mi deprime. Gli apici, invece, sono il mio forte.
--
ac

 e' il quant'altro che mi deprime. Gli apici, invece, sono il mio forte.
Forse non è chiaro che non ci sta attento lo sviluppatore, ma la libreria.

 Forse non è chiaro che non ci sta attento lo sviluppatore, ma la libreria.
mi  spiace ma stiamo parlando due  lingue diverse.
Il fatto che non sappia dove js sta di casa puo' essere vero e comunque
solo per divertirti passa questa roba a js. E' sufficiente che la sbatti 
in coda ad un qualsiasi html.
    <script>
   alert("necessita  scegliere un pollo")
   </script>
   <script>
  sonoac()
   function sonoac() {
{"category": "fiction",
           "author": "Evelyn Waugh",
           "title": "Sword of Honour",
           "price": 12.99
		  }
ac="pollo ruspante"
alert("ac e' un "+ac)
}
   </script>
   <script>
   sonocicap()
   function sonocicap() {
cicap="e' un signor pollo"
alert("cicap e' un "+cicap)
}
   </script>
e vedi cosa ti dice
--
ac

 ad un qualsiasi html.
In effetti io parlo una lingua che conosco, tu un po' meno. Comunque non 
ho capito cosa tu voglia dimostrare con quel paio di alert.