Конфігурація сайту 1 введення, блог го

Сьогодні заведемо розмову на таку, здавалося б просту, тему, як конфігурація сайту. Тобто поговоримо про такі речі, як параметри підключення до БД, різні настройки, як все це зберігати і як з усім цим працювати.

Розіб'ємо цю розмову на три частини:

• У поточній розглянемо різні варіанти організації конфіга. Ця частина в першу чергу орієнтована на новачків.
• У другій задумаємося над більш складними речами. Наприклад, як підтримувати набір відрізняються конфігов для однієї системи.
• А в третій частині спробуємо все це висікти в коді.

Отже, де ж можна зберігати налаштування системи?

Ніде не зберігати

Можна взагалі не напружуватися з окремим зберіганням налаштувань, а використовувати їх безпосередньо в потрібному місці:

mysql_connect ( 'localhost', 'vasa', 'qwerty');

І так бажано зробити в кожному файлі, де потрібен доступ до бази. Тоді спроба змінити якийсь параметр обов'язково перетворитися на незабутнє свято.

Після використання даного підходу деякий час на сайтах об'ємом більше трьох файлів, розробники зазвичай розуміють, що далі так жити не можна.

Глобальні змінні

Перше що роблять після усвідомлення того, що налаштування системи слід оголошувати раз і в одному місці:

Вже краще, але є і мінуси. Ті ж самі, що і взагалі у глобальних змінних. Запаскудили глобальний контекст неоднорідними, неструктурованими даними. З областями видимості будуть постійні проблеми. А так як і вся система при такому конфіги, очевидно, буде побудована на глобальних змінних, то постає питання конфлікту імен з усіма неприємно витікаючими наслідками.

define ( 'DB_HOST', 'localhost'); define ( 'DB_USER', 'vasa'); //.

Тепер ми запаскудили глобальний контекст неоднорідними, неструктурованими константами. Єдина радість: вони доступні в будь-якій області видимості і їх не можна випадково змінити.

Маючи невелику перевагу перед глобальними змінними, в деяких випадках константи навіть гірше них.

База даних

Налаштування можна зберігати в базі даних (ну, крім, власне, параметрів підключення до бази), а при необхідності, вибирати їх звідти запитами.

На перший погляд це дуже веселе і має право на існування рішення. Тим більше, що багато популярних форуми і блоги використовують його.

Але при більш детальному розгляді, це саме ідіотське, що можна придумати на цю тему. У базі можна зберігати налаштування, які будуть змінюватися через веб-інтерфейс, а також налаштування користувачів і т.п. Зберігати там загальну конфігурацію, це піз.ц.

Таке рішення зазвичай передбачається гнучким, оскільки дозволяє змінювати налаштування через якусь адмінку, не маючи доступу до коду (або не важко цим доступом). На ділі для загальних налаштувань це нахрен не потрібно. Нікому в житті не знадобитися змінювати шлях до папки з темами для форуму SMF. А якщо і знадобитися: йому все одно доведеться лізти в код і копіювати цю папку на нове місце.

Змінити щось не передбачене в подібній адмінки, а тим більше додати новий параметр виливається в безліч неприємних відчуттів. А спроба скопіювати собі сайт на локалку для розробки, перетворюється взагалі на щось мазохістське. Після копіювання потрібно лізти в базу і вишукувати там всі параметри, які необхідно змінити. Особливо радує, що зберігаються вони зазвичай в абсолютно нестравною форматі.

Тепер у нас все в окремому конфігурації масиві і не засмічує глобальну область.

Можна ще позбутися шкідливих звичок і згадати, що асоціативний масив дозволяє нам по-людськи все структурувати:

Тепер і оці приємніше і можна працювати не з усім масивом, а з його частинами.

return array ()

Не всі знають, що обробку файлу можна завершувати, як і для функції, за допомогою оператора return. Більш того, з нього можна повертати значення, яке стане результатом include або require. якими ми цей файл підключили.

Створимо файл конфігурації (config.php. Допустимо):

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

$ Config = include ( '/ path / to / config.php'); // Прочитуємо конфігурацію з файлу в змінну

$ Config = Config :: get (); // в потрібному місці

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

Але набагато важливіше інше: ми розділили зберігання конфігурації і інтерфейс доступу до неї. Код, Новомосковскющій конфігурацію, не обтяжує себе знаннями про те, де вона лежить, в якому вигляді і якими шляхами (може бути досить складними) формується. Можна повністю змінити спосіб зберігання - на прикладної код це не вплине.

З цього моменту питаннями зберігання конфіга можна займатися не замислюючись про питання його використання і навпаки.

поліпшення інтерфейсу

Інтерфейс доступу до конфігу (в попередньому випадку це Config :: get ()) можна покращувати нескінченно і на свій смак.

Прибрати статику, а на об'єкт навішати магічних методів і SPL-інтерфейсів, щоб вийшло щось на зразок:

$ Db_host = $ config-> db-> host; $ Db_user = $ config-> db-> user;

Отримання config-об'єкта можна зробити через IoC-контейнер або через якусь іншу хитромудрих річ.

З приводу поліпшення інтерфейсу можна придумати багато чого, а ще більше можна знайти готового в інтернеті. Залишимо цю тему і в подальшому сконцентруємося суто на способі зберігання конфігурації.

Формати зберігання: адаптери

Як показує практика, найбільш зручним для використовує коду, форматом подання конфігурації є деревоподібна структура. Тобто все той же асоціативний масив.

А ось для зберігання можуть бути зручні різні формати. Знову-таки масив (як вище), xml, ini-файл або ще щось.

Так як зберігання від уявлення ми вже відокремили, зберігати ми можемо в чому завгодно, ніяк не впливаючи цим на інтерфейс. Єдине, що потрібно, це перетворювати обраний формат зберігання до деревовидної структури для доступу до неї (тобто використовувати різні адаптери для завантаження).

Один із прикладів такого підходу: Zend_Config.

P.S. Що зберігати в конфіги

В кінці вступної частини задумаємося над тим, що взагалі слід зберігати в конфігурації сайту, а що не слід.

Ось такого ось робити не треба:

$ Dir_root = '/www/site.ru/htdocs'; $ Dir_image = '/www/site.ru/htdocs/image'; $ Dir_thumbs = '/www/site.ru/htdocs/image/thumbs'; $ Dir_css = '/www/site.ru/htdocs/css'; // і ще десяток шляхів

Буде потрібно щось змінити, перенести на інший сервер, скопіювати на локалку: про таке можна вбитися.

Всі значення, які можна згенерувати на підставі якогось базового, краще генерувати:

$ Dir_root = '/www/site.ru/htdocs'; $ Dir_image = $ dir_root. '/ Image'; // Або шаблон виду "> / image", який обчислювати в потрібному місці. $ Dir_thumbs = $ dir_image. '/ Thumbs'; $ Dir_css = $ dir_root. '/ Css';

Базове значення в прикладі, також в більшості випадків можна отримати автоматично на підставі $ _SERVER [ 'DOCUMENT_ROOT'] або dirname (__ FILE__).

Не треба намагатися конфігурувати кожну дрібницю: зайвої роботи ви і ті, хто прийдуть після вас, отримаєте гарантовано, а зайва гнучкість знадобиться далеко не завжди.

Для початку, мабуть вистачить. В наступній частині поговоримо про більш цікаві речі.

У Пітоні все прикольніше, наприклад маємо settings.py:
DATABASE_NAME = 'name'
DATABASE_USERNAME = 'username'
DATABASE_USERNAME = 'password'

і юзаем де треба:
import settings
або
from settings import DATABASE_NAME, DATABASE_USERNAME
і т.д.

Мені такий спосіб зберігання конфігов куди більше подобається :)

Не бачу особливої ​​різниці, якщо чесно.
А в наступній статті напишу речі трохи складніше, розкажеш як таке в Пітоні зробити.

Я про те, що не треба ніяких зендконфігов та іншої каламутна ... І це не (супер) глобальні змінні і т.д.

Спасибі, порадував. Здебільшого так і роблю, мабуть я на правильному шляху :).

phpdude, чого притиснув? Поржал?

artoodetoo, я в тобі і не сумнівався :)

цікаво як зберігати налаштування для всього сайту і реврайтіть деякі для піддоменів, наприклад ...?

Бля, Вася_ц, пароль «qwerty» - це ж просто триндец, сайти твої поламають на раз-два-три. Поміняй на щось путнє!

> Цікаво як зберігати налаштування для всього сайту і реврайтіть деякі для піддоменів, наприклад ...?
не зрозумів

> Не зрозумів
ну заходить юзверя на піддомен, а там функціонал на інший СУБД висить ...

kostyl, в наступній статейці подружжя.

vasa_c,
Ви рекомендуєте використовувати формат return array (...);
і далі пишіть «Все значення, які можна згенерувати на підставі якогось базового, краще генерувати:»
Підкажіть як об'єднати вище написане?
На прикладі наступного файлу конфігурації:
$ CONFIG = array (
'A' => «1»,
'B' => «2»,
'Ab' => $ CONFIG [ 'a']. $ CONFIG [ 'b'],
);

2. У випадку з шляхами, зазвичай виходить побудувати навколо __DIR__.

vasa_c, спасибі за ідеї! Для моєї поточної завдання скористаюся полухаком.

Я теж часто користуюся полухакамі, благо до return можна виробляти роботу ...

Хороша ідея, отказался от define!