Perché le applicazioni Web pubbliche non utilizzano i file ini per la configurazione


10

Quasi tutti i CMS pubblici là fuori usano un file di configurazione .php per le impostazioni del database e così via. Ad esempio WordPress crea automaticamente un file di configurazione .php quando lo si installa.

Perché non usano semplicemente un file .ini? PHP ha già parse_ini_file () e sono sicuro che altre lingue abbiano funzioni simili.

Risposte:


9

Con PHP in particolare; la differenza tra un file .ini e un file .conf.php è trascurabile.

L'uso diretto di PHP per la configurazione ha il netto vantaggio di dover ricorrere solo a una sintassi portatile ben definita per la configurazione, e il fatto che il file di configurazione sia correttamente un codice è occasionalmente utile.

Rispetto a quello; un file ini ha poco o niente da offrire; e include, requiree require_oncesono tutti ben noti e (principalmente) ben compresi.


relate to one well-defined, portable syntax for configurationNon capisco. i file ini hanno anche una sintassi ben definita e portatile. Ogni .conf.phpfile ha una propria struttura, la maggior parte sono basati su array, ma non è così diverso da un file ini.
yannis,

7
Si noti inoltre che un file PHP può fornire una protezione di base. Se Joomla usasse XML o .inifile per archiviare la configurazione, senza dubbio ci sarebbero molte istanze mal configurate in esecuzione in cui la configurazione era accessibile pubblicamente, il che di solito non è una buona cosa. Con i file PHP, sarà molto, molto raro per un server essere configurato in modo errato per offrire il contenuto di esso a un visitatore.
Tom Marthenal,

4

In generale, preferisco .inii file di configurazione XML. Nei sistemi più grandi, spesso qualcuno diverso dallo sviluppatore dovrà modificare un valore di configurazione, possibilmente un DBA o un amministratore di sistema. La maggior parte dei DBA e amministratori di sistema che conosco non avrebbe alcun problema a navigare attraverso un semplice script PHP, ma preferirei che non lo facessero. Un piccolo errore può danneggiare l'intera applicazione in diversi modi.

Ma nei sistemi più piccoli, è estremamente conveniente usare gli script PHP per la configurazione. Oggi stavo giocando con l' SDK AWS , che utilizza anche uno script PHP per la configurazione:

CFCredentials::set(array(
    'development' => array(
        'key' => 'xxx',
        'secret' => 'xxxx',
        'default_cache_config' => sys_get_temp_dir(),
        'certificate_authority' => true
    ),
    '@default' => 'development'
));    

Invece di hardcoding a default_cache_config, sto passando la temp di sistema, e funzionerebbe in ogni sistema in cui dispongo lo script. Questo script è una piccola dimostrazione del concetto che verrà trasmessa a circa 10 sviluppatori e voglio che lo eseguano così com'è, senza che ci sia molto da pensare. Se il prototipo si evolve, lo collegherò con la mia classe di configurazione XML (e ovviamente non farò affidamento sulla cache del filesystem).


"Un piccolo errore può danneggiare l'intera applicazione in diversi modi." Come se i valori non validi per ini non lo fossero? O che XML è più amichevole?
whatsisname

@whatsisname In genere se un valore di configurazione impostato in modo errato frena il sistema, i problemi si trovano altrove. Stavo pensando più a un pezzo di codice involontario nella configurazione dello script che faceva qualcosa di estremo, qualcosa che ho sperimentato più di una volta. Questo è impossibile con un file ini / xml, il punto principale è che una configurazione di script non è qualcosa che vorresti condividere con i non sviluppatori.
yannis,

3

La risposta è semplice: un conf.php ha praticamente zero lavoro richiesto per funzionare. È solo un altro file sorgente.


0

Anche la velocità senza memorizzazione nella cache può essere la ragione. La configurazione di PHP può essere memorizzata nella cache del codice operativo in modo trasparente, se necessario. Considerando che il file INI deve essere analizzato testualmente ogni volta che viene letto e devi creare tu stesso la cache. Per file di piccole dimensioni è ok, ma con centinaia di righe analizzate su ogni richiesta può arrivare a decine di millisecondi, il che è abbastanza per un web ottimizzato a 200ms.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.