PHP include_once: обработка импорта, т.е. для файлов конфигурации

Предположим, что мы имеем следующую структуру:

index.php config.inc.php \ lib \ lib \ common.php 

Несколько параметров, таких как имя базы данных, user & co, настраиваются в config.inc.php . Каков правильный способ доступа к ним, т. Е. Из функции, расположенной в \lib\common.php . Должен ли я действительно делать include_once("config.inc.php") внутри каждой функции?

Кажется, что это не работает, если:

  • config.inc.php включается один раз в index.php, прежде чем включать \lib\common.php там
  • если config.inc.php определяет все переменные перед включением \lib\common.php и всех других файлов (таким образом, мне нужно было бы включить config.inc.php во все «центральные» файлы на уровне index.php
  • он также не работает, если config.inc.php включен в начало \lib\common.php

Большое спасибо – я не смог найти решение с Google!

Решение

Я включил config.inc.php один раз в index.php (как было предложено Галеном) и использовал глобальный (как предложил Дэвид). Все работает так, как я ожидал, большое спасибо!

Позже я обязательно посмотрю auto_prepend как это было предложено n3rd, tkx!

Solutions Collecting From Web of "PHP include_once: обработка импорта, т.е. для файлов конфигурации"

Вы должны использовать ключевое слово global для доступа к переменным, которые были определены вне функции:

 $var1 = "muh"; $var2 = "foo"; function test() { global $var1; echo "var1=$var1; var2=$var2\n"; } 

будет печатать "var1=muh; var2=" .

Вы просто делаете:

 include_once("..\\config.inc.php"); 

наверху common.php.

Теперь есть несколько вещей: сначала обратные косые черты раздражают, и вы можете (даже на окнах, обменивать их на косые черты («../config.inc.php»). Если у вас есть каталог, где config.inc. php содержится внутри вашего пути include, вы даже можете сделать «config.inc.php».

И последнее, и не в последнюю очередь, если данные в config.inc.php необходимы для работы common.php, я предлагаю вам вместо этого переключиться на require_once () , поскольку это вызовет вызов exit () или die () в случае, если файл не может быть включен, следовательно, прекращение дальнейшего выполнения.

EDIT: А я не заметил, что говорили другие. Чтобы использовать переменные, объявленные вне функции внутри функции, вам нужно сообщить функции, что ей нужно «вытащить» эти переменные внутри области функции, используя глобальное ключевое слово (как говорили другие).

Рассмотрим следующий пример:

 $var = "Hello World"; function changeVar(){ $var = "Bye World!"; echo $var . "\n"; } changeVar(); echo $var; 

Выход выше указанного кода НЕ:

 Bye World! Bye World! 

скорее:

 Bye World! Hello World 

Это связано с тем, что $ var INSIDE функции – это ее собственная переменная, отличная от $ var, определяемой OUTSIDE функции. Измените это на:

 $var = "Hello World"; function changeVar(){ global $var; $var = "Bye World!"; echo $var . "\n"; } changeVar(); echo $var; 

И теперь у вас есть ожидаемый результат:

 Bye World! Bye World! 

Если вы включите файл config.inc.php в файл index.php … все файлы, которые будут включены после этого, смогут использовать данные внутри него.

Если у вас есть функции в common.php, вам нужно будет использовать ключевое слово global или передать данные в качестве аргументов, чтобы получить доступ к данным в config.inc.php

U использует функцию auto_prepend чтобы сделать именно это. Предварительный файл затем ищет иерархию каталогов из текущего сценария и ищет файлы, заканчивающиеся на «.autoinc.php», и включает их в обратном порядке, то есть те, что в подкаталогах могут перезаписывать материал, определенный в файлах, далее по иерархии. Это устанавливается один раз и работает автоматически везде и совершенно ненавязчиво. Я считаю, что это довольно красивое и универсальное решение.

ИМХО, это не очень хорошая практика для определения переменных в конфигурационных целях. Вы можете переписать их внутри своего кода. Лучше определить константы. В качестве преимущества – они находятся в глобальном масштабе, и вы можете использовать их из любого места без «глобального» ключевого слова.

Обычно я использую абстрактный класс Config со статическими методами, который анализирует внешние данные (я использую файлы конфигурации XML вне DOCUMENT_ROOT), а затем предоставляет его, отбрасываемый объектам, с кодом, подобным этому

 $dbalias = Config::get('db'); DB::connect($dbalias); echo $dbalias->user . '@' . $dbalias->host; 

Это очень полезно, когда вы работаете с командой и используете средство управления версиями (например, SVN). Evereyone в вашей команде работает на localhost, фиксирует все, кроме локального файла конфигурации, который не управляется версиями.

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