Newsgroup: it.comp.www.php
Titolo: File di configurazione

Ho un progetto abbastanza grande con un file di configurazione 
contenente circa 300 parametri.
secondo voi il miglior modo per gestire questo file (per ogni nuova 
installazione) �:
1) lasciare il file di testo ben formattato e pieno di commenti
2) fare una lunghissima procedura HTML
3) Creare un file .csv da dare in pasto ad un php in fase di installazione ?
4) ?
Grazie
-- 
AAAAAAAA American Association Against Acronym Abuse And Also Ambiguity

 4) ?
5) Config.php in una directory di include, ben commentato
6) File XML (e relativa classe / script php che lo carica)
-- 
Aiuta l'Alleanza Ribelle :
http://vwdarkside.com/it/jedi/maestro-padulo-132140

 installazione ?
Non ho capito la 2...
E nemmeno il resto, in realta`. Questa configurazione viene letta da ogni 
script (e quindi a ogni pagina) o serve per "l'installazione" 
dell'applicazione su un nuovo server?
Nel primo caso ti consiglio un file di config in formato .ini o .json, 
per cui PHP ha funzioni di parsing native, e quindi molto veloci.
Oppure un file in PHP con un array o un oggetto predefinito da includere 
semplicemente (questo e` il piu` veloce)
Ti sconsiglio XML (troppo lento) e csv (troppo poco flessibile)
Bye.

 Ti sconsiglio XML (troppo lento)
Uffa... :-)
Però è molto molto leggibile e abbastanza robusto contro gli errori di
scrittura, essendo /well formatted/ .



la tua numero 5 corrisponde alla mia numero 1
per procedura html intendo una di quelle pallose procedure di 
installazione (tipo quando si installa joomla o wordpress)
certo che con 300 parametri da impostare la vedo quasi impossibile.


 certo che con 300 parametri da impostare la vedo quasi impossibile.
Se tutti i 300 hanno un default e 290 di questi default non devono
essere cambiati... non la vedo impossibile.
Imposti per ogni parametro un gruppo di riferimento (db, directory,
memory size limit, ecc...), label e un default. Poi ti cicli il listone
e voilà l'"HTML" di cui parli per impostare i valori. Fai "Salva" e ti
crei il config.php per quell'installazione.


 4) ?
metterlo in una tabella di DB ti farebbe schifo?
un tracciato così:
+-----------+------+--------+---------+-------------+-------------+
| Parametro | tipo | valore | default | validazione | spiegazione |
+-----------+------+--------+---------+-------------+-------------+
penso sia autoesplicativo: cmq, in "validazione" ci puoi mettere se
necessario una regexp per controllare l'input, insieme con il campo
"tipo" (dal punto di vista del DB ovviamente saranno sempre stringhe),
mentre il campo "spiegazione" conterrà una descrizione del parametro
da usare come commento o per fare una procedura di input
semiautomatica.
bye!

 metterlo in una tabella di DB ti farebbe schifo?
Eh,
ma se la connessione al db è una di quelle cose da configurare... come
fai ad averla già.. nel db?


Innanzitutto dividiamo i prolemi:
1. Formato del file di configurazione finale
2. Metodo per crearlo
Per il problema 1 voto anche io per il Json, veloce, semplice e (cosa
non da poco) è praticamente universale anche su altri linguaggi.. solo
ricordati di mettere quel file FUORI dalla webroot.. almeno che tu non
sia propenso al suicidio.
Se invece ritieni che non dovrai MAI e dico MAI leggere quel file al
di fuori di php, allora ti consiglierei di usare un semplice array,
del tipo:
config.php
<?php
return array('foo' => 'bar');
?>
//file a caso che legge il config
<?php
$config = include('config.php');
echo $config['foo'];
?>
Il problema 2 è del tutto relativo: puoi farti una funzione/classe che
prende in pasto un file in qualsiasi formato (csv, txt, ini, xml, un
array, etc...) lo parsa come deve e poi scrive il file di
configurazione nel punto 1...
Volendo puoi anche farti la funzione per modificare/aggiungere voci di
configurazione al volo via web.

 2) fare una lunghissima procedura HTML
che vuol dire?


Immagino scrivere un documento Html con la procedura per creare il
file di configurazione... e spero di non sbagliarmi ;)


si intendevo una procedura guidata come quella di joomla o wordpress 
all'installazione...
googlando ho trovato anche questa
http://www.apphp.com/php-easyinstaller/examples/sample3/install.php
ma sinceramente per 300 parametri... di cui almeno 200 devono essere 
impostati manualmente per ogni installazione, credo che preferirņ un bel 
file config.inc.php ben commentato e formattato


 file config.inc.php ben commentato e formattato
Puoi fare entrambe le cose: crei il file default.config.ini (o .php,
ma .ini.php non ha senso) ben commentato e se uno vuole se lo modifica
a mano;
Poi crei anche il wizard html, per chi non ha voglia/modo di
modificare a mano il file di configurazione.
Ma sei poi davvero sicuro che 200 parametri devono essere messi a
mano?
Mi sembrano un pò tanti.. non è possibile fare un auto-detect di quei
valori, poi controllarli, e nel wizard html mostrare solo quelli
errati (o che non sei riuscito a impostare tramite auto-detect) e gli
altri mostrarli da qualche altra parte (tipo "Settaggi Avanzati"?)
L'utente medio che dovrà eseguire l'installazione in media che
conoscenza ha?
Considera che se Wordpress non aveva il wizard per la configurazione,
col cavolo che diventava la più diffusa piattaforma di blogging..
considera anche l'utenza che dovrà poi metterci le mani.

 scrittura, essendo /well formatted/ .
JSON e` piu` leggibile IMHO, ma e` vero che a un'occhiata veloce gli 
errori si notano meno (sono impazzito a trovare una virgola mancante in 
un file di 300 righe).
La cosa migliore e` proprio farlo in PHP: se c'e` un errore di sintassi 
ti scrive la riga esatta in cui e`, e` il piu` rapido da interpretare e 
non necessita di parser, ed e` anche il piu` flessibile.
Bye.

 fai ad averla già.. nel db?
Ovvio, ma se usi un qualunque framework o libreria o semilavorato i
settaggi del DB sono già gestiti da qualche altra parte, quindi li
davo per scontati.
Al limite, se non è così (ma nel 2011 c'e' ancora qualcuno che
sviluppa in php senza usare un layer DB precotto?), le informazioni
minimali per il bootstrap dell'applicazione le metti nel solito
include.php ;^)
bye!


invece io cercavo proprio un modo per generare agevolmente l'include.php
ma non c'� nulla di pi� agevole di un file ben commentato a quanto pare ;-)


 davo per scontati.
Uhm... no. Qualsiasi setting from scratch non può conoscere le
credenziali del db.
Il db è tuo (e diverso per chiunque fa l'installazine), come fa
l'applicazione a sapere il framework (o chi per lui) username, password,
db name, porta...  ?


 bye!
Ok, precotto o meno, framework o olio di gomito, i casi sono 3:
1. L'utente Volper telefona all'utente/cliente che riceve il
programma, gli chiede i dati del db e li scrive nel file di
configurazione, impacchetta tutto e manda lo zip al cliente/utente;
2. L'utente che riceve lo zip del programma si mette li ed edita/crea
il file di configurazione inserendo i dati del DB;
3. Volper crea un wizard dove chiede all'utente di inserire i dati del
db e poi, tramite php, crea il file di configurazione;
Il caso 2 e 3 sono proprio l'argomento di questo 3d, il caso 1 non lo
voglio commentare ;)
E ci sarebbe anche l'incontro del 4° tipo (come ho purtroppo già visto
fare): nelle istruzioni di configurazione si chiede di creare un db
indicando il nome del db, dell'utente e della password, lo script come
popola quel db, poi parte il wizard che chiede le altre informazioni
all'utente, e poi l'autore si domanda cosa cavolo aveva bevuto ;)

 ma non c' nulla di pi agevole di un file ben commentato a quanto pare ;-)
il fatto è che quello che è "agevole" per qualcuno può essere tedioso
o difficile per qualcun altro...
bye!

 db name, porta...  ?
E' ancora ovvio anche questo, evidentemente non riesco a spiegarmi
bene :^)
Lo scenario che avevo in mente è quello in cui il pacchetto è
sviluppato con un framework stile cake o con un layer precotto di
connessione al DB stile ADOdb.
Questi prodotti hanno una loro procedura di installazione e il loro
modo di mantenere le info di connessione, nativo.
I "300 parametri" invece immagino che abbiano un ruolo ben preciso
dentro l'applicazione, per cui vedevo sensato gestire le info sulla
connessione con la metodologia "basica" e invece cercare di gestire un
qualche modo l'input e la modifica di questi altri parametri.
bye!

 voglio commentare ;)
concordo sui casi 2 e 3, ma me ne vengono in mente anche molti altri
con ancora altre specificità, per questo sopra ho chiesto all'OP di
essere più preciso :)
bye!