Подтвердить что ты не робот

My_config.ini vs my_config.php

При работе мы используем файл .ini для установки переменных до вызова остальной части фреймворка (я думаю, что он идет

function getConfigVars(){
    //read my_config.ini file
    ....
    //call framework
}

и я всегда задавался вопросом, есть ли такая возможность для этого.

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

Итак, зачем использовать my_config.ini, а не my_config.php? Это не похоже на то, что кто-то должен прикасаться к нему после того, как он настроен, и кажется более удобным просто вызвать переменные и иметь возможность автоматизировать свой IDE файл, где бы вы ни использовали переменные ini/анализировать его на наличие ошибок.

4b9b3361

ОТВЕТЫ

Ответ 1

Zend Framework содержит анализы конфигурации, которые анализируют файлы, написанные в формате ini (Zend_Config_Ini), похоже, что это то, что вы используете.

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

Формат INI специализирован для обеспечения как возможности иерархии ключей данных конфигурации, так и наследования между разделами данных конфигурации. Иерархии данных конфигурации поддерживаются путем разделения ключей на символ точки или периода (.). Раздел может распространяться или наследоваться из другого раздела, следуя имени раздела с символом двоеточия (:) и именем раздела, из которого данные должны быть наследованы.

От страницы Zend_Config_Ini.

Zend Framework использует его, чтобы позволить вам иметь несколько параметров конфигурации: один для этапа, один для разработки и один для производства. Это также позволяет легко настраивать параметры базы данных для производства, а также для разработки и иметь две очень разные настройки. Различные пути, установленные в файле ini, где они расположены, находятся. Это значительно облегчает переход кода от разработки к производству, зная, что сразу все, что является развитием, будет отключено.

Конечно, это было бы возможно с PHP script, но для этого потребовалось бы большее разбор различных переменных конфигурации, а также выполнение if/then проверок, тогда как использование parse_ini_file() делает все это для вас автоматически.

Другие ответы также уже указывали на то, что не программистам, возможно, потребуется изменить переменные и/или что-то на веб-сайте, который задан как переменная конфигурации (например, название сайта, которое используется в макете сайтов). Файлы INI легко понять и прочитать даже для тех, кто никогда не программировал раньше.

Пример с веб-сайта, над которым я сейчас работаю:

[production]
phpSettings.display_startup_errors = 0
phpSettings.display_errors = 0
includePaths.library = APPLICATION_PATH "/../library"
bootstrap.path = APPLICATION_PATH "/Bootstrap.php"
bootstrap.class = "Bootstrap"
resources.frontController.controllerDirectory = APPLICATION_PATH "/controllers"
resources.layout.layoutPath = APPLICATION_PATH "/layouts/scripts"
resources.db.adapter       = "PDO_SQLITE"
resources.db.params.dbname = APPLICATION_PATH "/../data/db/users.db"

resources.view[] =

[staging : production]

[testing : production]
phpSettings.display_startup_errors = 1
phpSettings.display_errors = 1
resources.db.params.dbname = APPLICATION_PATH "/../data/db/users-testing.db"

[development : production]
phpSettings.display_startup_errors = 1
phpSettings.display_errors = 1
resources.db.params.dbname = APPLICATION_PATH "/../data/db/users-dev.db

Это упрощает сбор нескольких наборов данных для различных сред, в которых может выполняться код.

Ответ 2

Для тех, кто приходит к этому вопросу, потому что они хотят знать, есть ли какие-либо различия в производительности между использованием INI файла, который должен быть проанализирован, и PHP файл, который просто включен (и может быть кэширован PHP): Да, там являются различиями, но они настолько малы, что это не имеет большого значения.

Мой тестовый сценарий представляет собой файл config.ini с 20 парами ключ/значение и файл config.php с теми же 20 парами ключ/значение, записанными как определяет. Версия PHP - 5.4.9 на Ubuntu Linux 13.04.

key1 = value1
...
key20 = value20

против.

<?php
define("key1", "value1");
...
define("key2", "value20");

Два тестовых сценария, включая конфиги:

<?php
$CONF = parse_ini_file("config.ini");

против.

<?php
require_once "config.php";

Я тестировал производительность с помощью ab -c 25 -n 10000.

Результат без кеша PHP:

ini: Requests per second:    2660.89 [#/sec] (mean)
php: Requests per second:    2642.28 [#/sec] (mean)

Результат с кешем PHP APC:

ini: Requests per second:    3294.47 [#/sec] (mean)
php: Requests per second:    3307.89 [#/sec] (mean)

Я запускал тесты несколько раз, естественно, цифры будут меняться каждый раз, но консенсус таков: config.ini немного быстрее, когда не используется кеш PHP, config.php немного быстрее, когда кеш PHP используемый. Но разница настолько мала, что решение не должно основываться на производительности.

Ответ 3

Конечно, ваш вопрос поднимает справедливую точку.

Несколько точек в пользу файлов .ini:

  • Использовать файл с другим языком. Если вы когда-либо хотели иметь Perl, Python, Ruby и т.д. script делать что-то, что особенно просто с этим языком и необходимо получить доступ к настройкам проекта, вам не повезло, если вы сохранили свои настройки в файле PHP.

  • Человеческое редактирование данных. Хотя вы отклонили его в своем вопросе, намерениях или нет, очень вероятно, что кто-то может оказаться там, и это может быть не технический человек. Формат INI намного менее страшен, чем PHP-код, даже если это всего лишь куча объявлений переменных

  • Обновление настроек. Я думаю, что гораздо проще создать новый файл INI, а не писать PHP файл. Однако это довольно субъективно, но стоит упомянуть.

  • Связь между настройками переменных. Это довольно просто/интуитивно, чтобы дать вашим настройкам иерархию с INI файлом. Хотя это также возможно с PHP, оно не так аккуратно и может стать неприглядным, если вы пытаетесь сделать глубоко вложенные ассоциативные массивы для хранения информации.

В дополнение к этим, поступок INI "необходимости защиты от доступа к сети" не имеет отношения к большинству сценариев, так как большинство проектов PHP (по крайней мере, те, из которых я часть) содержат достаточное количество кода из корневой папки, и настройки обычно идут туда.

Ответ 4

Ну, может быть, проще, чтобы не программист мог изменять конфигурационные переменные... Если это необходимо на вашем рабочем месте.

Я обнаружил, что тщательное размещение <?php и ?> может помешать его отображению, в то время как parse_ini_file() все равно получит соответствующие данные из файла.

Лучший способ защитить его - это разместить его над docroot и запретить доступ к *.ini в настройках вашего сервера.