Newsgroup: it.comp.programmare
Titolo: File di config

Salve a tutti,
vorrei un consiglio. Dovrei realizzare un file di configurazione per
un'applicazione. Attualmente un file di configurazione esiste già ma
si tratta di un semplice file di testo formattato in un certo modo ed
in cui capirci cosa è un pò difficile. Mi è stato chiesto di
migliorare la situazione realizzando un file di config in cui
archiviare le informazioni e che sia facile da elaborare, a livello di
applicazione e comprensibile dal punto di vista umano in caso di
modifiche. In più considerando che in un futuro tale file possa essere
modificato tramite interfaccia web vorrei da voi un consiglio su che
genere di soluzione adottare. Oltre ad un database (la prima soluzione
che viene in mente) che ne pensereste di un file XML ?! Oppure ci sono
altre valide soluzioni?
Grazie a tutti

altre valide soluzioni?
Non dici su che sistema stai lavorando; se fosse Windows immagino che la
soluzione più ovvia sarebbe usare il registro (e pazienza se non è
umanamente comprensibile).
XML credo che sia proprio la peggiore idea che possa venire in mente (da
quando XML è "comprensibile dal punto di vista umano"? senza contare che
non è nato come formato di serializzazione dati, anche se tutti lo usano
per questo).
Meglio YAML, o i vecchi file .ini di Windows.
Ciao.

 altre valide soluzioni?
Un database per mettere delle informazioni di configurazione e'
decisamente pessima: i parametri di accesso al database dove li
configureresti?
XML invece e' un'ottima soluzione.
Inizialmente avevo pensato ad una struttura tipo .ini ma nel momento in
cui devi operare anche via web, XML e' proprio la struttura ideale.
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

cui devi operare anche via web, XML e' proprio la struttura ideale.
E perché? per quale motivo sarebbe piů facile modificare via web un file
XML, piuttosto che un .ini, uno YAML, la tabella di un database o qualsiasi
altra cosa? un form č un form, indipendentemente da dove siano memorizzati
i dati, e lato server non mancano certo gli strumenti per modificare
agevolmente qualsiasi formato dati.
Ciao.

 agevolmente qualsiasi formato dati.
Sara' perche' ci sono un sacco di librerie gia' pronte per maneggiare 
gli XML, mentre per qualunque formato ti devi scrivere del codice.
A me quando mi passano un XML mi tiro su la struttura in un attimo e so 
che tutte le variabili vengono valorizzate.
Quando mi passano un file di altri formati, mi devo adattare del codice 
che gia ho, ma che comunque devo testare etc...

[...]che ne pensereste di un file XML ?!
No, adotta un file .INI, va benissimo ed è più semplice da gestire.

XML credo che sia proprio la peggiore idea che possa venire in mente 
Concordo... forse non proprio la "più più più peggiore", ma comunque
un cannone per sparare alle zanzare.

gli XML, mentre per qualunque formato ti devi scrivere del codice.
Premesso che a me basta una semplice classe (in libreria) per leggere
un file .ini, perché dovrei appesantire la mia applicazione con un SAX
o un DOM parser?

Scusate la dimenticanza, lavoro su linux. Quindi niente registro.
Nulla togliendo ai file .ini, che potrebbero essere una buona
soluzione se un domani si rendesse necessaria la modifica della
struttura del file (ad es. un parametro contiene uno o più valori, o
addirittura sottoparametri) la classe eventualmente prevista per il
parsing del file non funzionerebbe più. Credo che XML sia più
flessibile da questo punto di vista. Che ne pensate?! Non conoscevo
invece YAML, da quanto leggo dalla homepage sembra essere
interessante.  Mi documenterò.
Grazie a tutti.

interessante.
YAML, a differenza di XML, è un linguaggio nato proprio per la
serializzazione dei dati, e consente di memorizzare qualunque struttura
dati, anche complessa, che possa essere rappresentata in Perl, Python,
Ruby, ecc. E' pensato, inoltre, per essere umanamente facile da leggere.
L'unico possibile problema è che, per quello che ne so, librerie e moduli
per accedere a YAML lavorano interamente in memoria (caricano interamente
il file in memoria prima di analizzarlo), così almeno il modulo YAML per
Perl. Non dovrebbe essere un grosso problema per un file di configurazione,
ma comunque è un limite da tenere presente.
Ciao.

gli XML, mentre per qualunque formato ti devi scrivere del codice.
Ci sono tonnellate di librerie già pronte per maneggiare qualunque formato.
Per un file .ini non devi scriverti nessun codice, così come per YAML, e
per una quantità di altri formati di serializzazione dati.
Ciao.

 o un DOM parser?
Forse perche' esistono anche classi gia' pronte per leggere i files xml,
senza scomodare un sax o un dom parser?
Io, per esempio, in perl includo un modulo gia' pronto, XML::simple, e
ho due bellissimi metodi: uno per leggere un xml e inserirlo in un hash,
e l'altro che scrive l'hash in un xml.
e non dubito che in tutti i linguaggi esista qualcosa di simile.


 per una quantità di altri formati di serializzazione dati.
Non dubito, ma e' necessario che questi formati di serializzazione dati
abbiano un certo standard e una certa diffusione affinche' vi siano
librerie gia' pronte per maneggiarli.
L'importante e' adottare un modello standard.
Poi la scelta del modello dipende anche da quali informazioni debbano
essere memorizzate, dall'ambiente in cui questa roba deve girare, dalla
frequenza in cui il file di configurazione deve essere modificato e da
un sacco di altra roba di cui noi non siamo a conoscenza e l'amico che
ha posto la domanda non ci ha informato.
Non ti piace XML, non usarlo.
Ma non c'e' una buona ragione per escluderlo.
E' una struttura standard, elastica e comprensibile, nonostante la tua
spiritosaggine qui sopra.
Altrettanto bene dovrebbe andare una struttura tipo .ini anche se
leggermente piu' limitata.
YAML non lo conosco, ma lo spessore della documentazione che ho trovato
mi suggerisce che sia valido.
Assolutamente da escludere, invece, un formato proprietario, o un
database, o campi di lunghezza fissa.


L'importante e' adottare un modello standard.
Questa parte l'avevo scritta in italiano, non in turco: ci SONO (non "ci
SAREBBERO, se il formato avesse una certa diffusione") librerie già fatte
per maneggiare file .ini, YAML e molti altri formati di serializzazione
dati, che SONO standard consolidati. Non esiste solo XML, e tutti gli
strumenti non sono un martello.
Ciao.

 fregato. Il file .ini è di gran lunga più semplice e sicuro.
Condivido questa opinione e credo che, per configurazioni semplici, gli 
.ini siano un'ottima soluzione.
I motivi che, in casi particolari, possono far preferire XML (o 
comunque che attenuano i difetti citat) possono essere:
- il programma usa già XML o librerie che lo utilizzano (in quel caso 
il discorso sull'overhead del parser, ovviamente, cade).
- possibilità di far modificare la configurazione anche ad un programma 
esterno (con l'ini è più complicato, soprattutto se devi sostituire dei 
parametri, a meno di non riscriverlo tutto, ma così ti perdi i commenti 
che in XML puoi preservare). 
Ovviamente la scelta, in questo caso, dipende da quanto spesso la 
configurazione viene essere effettuata da un umano rispetto a un tool 
esterno (ex: un'interfaccia grafica per tool a linea di comando).
- in XML si possono organizzare gerarchicamente i dati e strutturarli 
su più livelli ed è semplice inserire più parametri (nodi) dello stesso 
tipo. 
Nei file di .ini hai le sezioni ma non c'è modo di ripetere più volte 
lo stesso parametro. 
Ad esempio un programma che debba processare diversi tipi di file in 
diverse directory in XML potrebbe essere configurato così:
<directory path="C:\">
<filetype ext="jpg"/>
<filetype ext="gif"/>
<filetype ext="bmp"/>
<directory/>
<directory path="D:\pippo">
<filetype ext="jpg"/>
<filetype ext="gif"/>
<directory/>
In un file di ini potresti gestirla con sezioni diverse per le 
directory e parametri numerati per i file, oppure con parametri 
numerati per le directory e le estensioni separate da virgole etc., 
però queste soluzioni richiedono del codice ad-hoc.
-- 
Valter Minute
(the reply address of this message is invalid)
(l'indirizzo di reply di questo messaggio non è valido)

 file.ini
*Qualsiasi* file è incasinabile, ma incasinare un file .ini è veramente
difficile: devi essere un imbecille per compromettere una struttura
"attributo=valore".
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 struttura del file 
Il file .ini ha una struttura specifica moooolto semplice e non puoi, un
domani, cambiare la struttura, ma semplicemente cambiarne i contenuti.
Dal mio punto di vista, XML dovrebbe essere usato *SOLO* per lo scambio di
informazioni tra sistemi, evitando di dover fornire il classico "tracciato
record". La struttura sarebbe implicitamente ricavabile dal file stesso.
