Dlaczego publiczne aplikacje internetowe nie używają plików INI do konfiguracji


10

Prawie każdy publiczny CMS używa pliku konfiguracyjnego .php do ustawień bazy danych i tak dalej. Na przykład WordPress automatycznie tworzy plik konfiguracyjny .php podczas instalacji.

Dlaczego po prostu nie używają pliku .ini? PHP ma już parse_ini_file () i jestem pewien, że inne języki mają podobne funkcje.

Odpowiedzi:


9

W szczególności z PHP; różnica między plikiem .ini a plikiem .conf.php jest znikoma.

Używanie PHP bezpośrednio do konfiguracji ma tę wyraźną zaletę, że musi odnosić się tylko do jednej dobrze zdefiniowanej, przenośnej składni do konfiguracji, a fakt, że plik konfiguracyjny jest poprawnie kodowany, jest czasami przydatny.

W porównaniu z tym; plik ini ma niewiele do zaoferowania; i include, requirei require_oncewszystkie są dobrze znane i (głównie) dobrze zrozumiane.


relate to one well-defined, portable syntax for configurationNie rozumiem tego Pliki ini mają również dobrze zdefiniowaną i przenośną składnię. Każdy .conf.phpplik ma własną strukturę, większość jest oparta na tablicy, ale nie różni się tak bardzo od pliku ini.
yannis

7
Zauważ też, że plik PHP może zapewnić pewne podstawowe zabezpieczenia. Gdyby Joomla używał XML lub .iniplików do przechowywania konfiguracji, bez wątpienia uruchomionych byłoby wiele źle skonfigurowanych instancji, w których konfiguracja była publicznie dostępna, co zwykle nie jest dobrą rzeczą. W przypadku plików PHP bardzo rzadko zdarza się, że serwer jest źle skonfigurowany, aby wyświetlać zawartość gościowi.
Tom Marthenal,

4

Ogólnie rzecz biorąc wolę .inipliki konfiguracyjne XML. W większych systemach często ktoś inny niż programista będzie musiał zmienić wartość konfiguracji, na przykład DBA lub sysadmin. Większość administratorów DBA i sysadminów, które znam, nie miałoby problemu z nawigacją po prostym skrypcie PHP, ale wolałbym, gdyby tak nie było. Jeden mały błąd może zaszkodzić całej aplikacji na kilka sposobów.

Ale w mniejszych systemach niezwykle wygodne jest używanie skryptów PHP do konfiguracji. Bawiłem się dzisiaj z AWS SDK , który do konfiguracji używa również skryptu PHP:

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

Zamiast na stałe a default_cache_config, przekazuję temp systemu, i to działałoby w każdym systemie, w którym wdrażam skrypt. Ten skrypt jest niewielkim dowodem koncepcji, który zostanie przekazany około 10 programistom, i chcę, aby działali w niezmienionej formie, nie mając o czym myśleć. Jeśli prototyp ewoluuje, połączę go z moją klasą konfiguracyjną XML (i oczywiście nie będę polegać na pamięci podręcznej systemu plików).


„Jeden mały błąd może zaszkodzić całej aplikacji na kilka sposobów”. Jakby nieprawidłowe wartości dla ini nie? A może XML jest bardziej przyjazny?
whatsisname

@whatsisname Zazwyczaj, jeśli niepoprawnie ustawiona wartość konfiguracji hamuje system, wtedy twoje problemy są gdzie indziej. Myślałem bardziej o niezamierzonym fragmencie kodu w konfiguracji skryptu, robiąc coś ekstremalnego, coś, czego doświadczyłem więcej niż raz. Jest to niemożliwe w przypadku pliku ini / xml. Najważniejsze jest to, że konfiguracja skryptu nie jest czymś, czym chciałbyś się podzielić z innymi programistami.
yannis,

3

Odpowiedź jest prosta: conf.php wymaga praktycznie zerowej pracy, aby mógł działać. To tylko kolejny plik źródłowy.


0

Przyczyną może być również prędkość bez buforowania. W razie potrzeby konfiguracja PHP może być przezroczyście buforowana opcode. Podczas gdy plik INI musi być analizowany tekstowo za każdym razem, gdy jest czytany, i musisz samodzielnie utworzyć pamięć podręczną. W przypadku małych plików jest to w porządku, ale z setkami wierszy parsowanych na każde żądanie, może wzrosnąć do dziesiątek milisekund, co jest całkiem sporo jak na 200ms zoptymalizowany internet.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.