Переменные конфигурации CMS

[foter]

Переменные конфигурации CMS

Пусть переменные конфигурации CMS хранятся в файле config.php

В каком формате лучше хранить переменные конфигурации: в виде собственно переменных или все же в виде констант?
Обоснуйте ответ.

 

[Фанат]

В виде ini-файла.
Обоснование попробуй сообразить сам, в виде домашнего задания.

 

[foter]

*****, я уже давно не видел CMS, где бы настроийки хранились в виде ini-файла.

Обоснование даже придумывать не буду, так как считаю абсолютно не логично использовать ini.

 

[Angerslave]

Гыгы, прям как задание из теста... Я лично сделал класс-обёртку для работы с конфигами и сами значения хранятся в виде переменных.

 

[Апокалипсис]

ох - поищи в поиске вроди с год назад была длинная тема по сабжу.

-~{}~ 16.03.08 00:13:

Angerslave
+1 я тоже не видал

 

[Farsh]

В dle например конфиг - это .php с настройками в виде массива )
То есть include и весь array при тебе .
Только не понял - а какая разница в каком виде хранить настройки ?
Тут уже стоит понять само отличие переменных от констант ..

 

[Angerslave]

Поговаривают, что константы жрут больше памяти...

 

[dimagolov]

основное отличие констани (кроме того, что их поменять нельзя), это то, что для их использования в ф-ях не надо их прописывать как global переменные.

 

[Angerslave]

dimagolov, да, я тож думал, что это удобнее, не надо о глобалах заботиться, но функция-обёртка меня сейчас больше прикалывает

 

[dimagolov]

тогда singltone

 

[Духовность™]

singltone

В singlton ИМХО надо передавать переменные конфигурации, но никак не хранить в singltone. Т.е. при инициализации класса надо сначала получить эти переменные. А мы не знаем, где их хранить

 

[Angerslave]

triumvirat, почему бы не сделать систему импорта\эскпорта настроек и хранить их где-нить в базе\+кеше в сериализованом виде? В ZF, насколько я понял, так и сделано.

 

[weregod]

Автор оригинала: foter
*****, я уже давно не видел CMS, где бы настроийки хранились в виде ini-файла.

Обоснование даже придумывать не буду, так как считаю абсолютно не логично использовать ini.

логика Ваша хромает, что мешает использовать settings.php как ini-шку:

;<?php die(); ?>

[section1]
var1 = val1
....


зато до сих пор встречается код, части которого имеют расширение .inc, при этом может остутствовать .htaccess и вообще, нет гарантий, что .htaccess отработает, в результате имеем при запросе по http

http://somedomain.com/includes/config.inc открытый код.

 

[Духовность™]

triumvirat, почему бы не сделать систему импорта\эскпорта настроек и хранить их где-нить в базе\+кеше в сериализованом виде?

ну а разница? все равно в синглтон это все пихать.

что мешает использовать settings.php как ini-шку:

ЗАЧЕМ?

По-моему, достаточно создать config.php и тупо писать

$_CONFIG['key'] = 'val';
$_CONFIG['key1'] = 'val1';
$_CONFIG['key2'] = 'val2';

Во-первых, это не будет доступно из вне, если "нет гарантий, что .htaccess отработает", во-вторых любой даун сможет отредактировать данные настройки под себя.

 

[fixxxer]

если даун ошибется в инишке, то не будет ничего страшного
если даун ошибется в синтаксисе php будет parse error

 

[Angerslave]

если даун ошибется в инишке, то не будет ничего страшного

Смотря как ошибётся... Уж лучше parse error чем убитая база данных.

 

[Духовность™]

если даун ошибется в синтаксисе php будет parse error

и? весь мир рухнет?

 

[bgm]

Яблоки нынче уродились кислые...

 

[foter]

А может ли взломщик получить через http-протокол значения переменных хранящихся в файле config.php , который не защищен .htaccess?

 

[Духовность™]

foter
Если файлы с расширением php не зарегестрированы на PHP-обработчик, т.е. имеют тип обычных текстовых файлов, то да.