Реестр настроект для сайта

Одной из лучших «фишек» считается ее реестр. Есть, конечно, и те, кто реестр считает самым большим злом в мире. У каждой стороны есть свои аргументы. Главный козырь противников реестра — непереносимость софта и невозможность сделать рабочую настроенную версию данной программы. Главный козырь защитников — все настройки хранятся в одном месте, в которое имеют доступ все программы и пользователь. Это облегчает создание снапшотов системы и возможность написания огромного количества разного рода твикеров. Теоретическая упорядоченность реестра за счет дерева каталогов тоже плюс. А так же удобным является автоподстановка ветки текущего пользователя, залогиненного в систему.

Теперь рассмотрим преимущества реестра в применении к веб-сайту.

Во-первых, сайт — это по сути обычная многопользовательская система с удаленным доступом. Большинство сайтов имеют собственную пользовательскую подсистему (логин), а случаи доступа незалогиненных пользователей можно рассматривать как гостевой доступ (учетка guest).

Во-вторых, сайту, как и обычному приложению для , требуется где-то хранить ряд своих настроек. Одни из них в процессе жизни сайта не меняются (такие настройки часто устанавливают прямо в коде в виде констант), другие можно менять (в CMS обычно есть страничка «настройки»; примерами таких настроек может служить информационное сообщение на всех страницах сайта или количество записей на одной странице в списках). Третье настройки зависят от текущего пользователя (обычно это какие-либо привилегии, часть которых часто реализуется в системе прав доступа, и персональные установки пользователя).

Настройки всегда касаются либо всего приложения в целом (например, путь к www_root), либо отдельных его компонентов (например, количество новостей в блоке на главной странице).

Когда разложена по полочкам классификация настроек, можно прикинуть предположительную структуру реестра настроек сайта:

  • ветвь глобальных настроек приложения, которые касаются всех пользователей;
  • ветвь локальных настроек модулей, которые касаются всех пользователей;
  • ветвь настроек текущего пользователя (подставляется в зависимости от залогиненного пользователя);
  • ветвь настроек пользователя по умолчанию (all users).

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

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

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

Ветвь настроек пользователя по умолчанию — это настройки анонима. Т.е. на практике эти настройки касаются всех пользователей сайта. Ветвь настроек текущего пользователя — это настройки, которые касаются только того пользователя, который сейчас залогинен в систему. Ядро должно автоматически подставлять в эту ветвь соответствующие значения при запросах. В этих ветках могут быть и глобальные настройки системы, и локальные настройки компонентов, которые различаются для разных залогиненных пользователей. Информация должна быть так же разложена по подкаталогам.

Такая система позволит упорядочить огромный массив настроек сайта, ядра, компонентов, в удобном виде хранить пользовательские настройки, а так же применить систему каталогов (и подкаталогов) для хранения настроек и удобного доступа к ним. Остается решить самую сложную задачу — эффективно реализовать такой относительно сложный алгоритм системы. Так как настройки нужны в коде постоянно и к менеджеру подсистемы настроек будет довольно много обращений за один запрос пользователя, самым важным качеством такой подсистемы является высокая производительность.

Реестр настроект для сайта: 2 комментария

  1. Насколько знаю, в UMI.CMS такой реестр уже реализован и довольно успешно используется. Но, как ты сам сказал, тормоза — основной побочный эффект такого удобства, и в юми его не отнять =(

    PS: сам храню настройки системы в памяти в виде дерева, подгружая нужные ветви при запросе из файлов/кеша/mysql. На данный момент мне этого предостаточно

  2. До нынешнего времени не сталкивался с такими практическими реализациями в ЦМСках. У себя в движке блога отвёл под это дело таблицу и связал через ядро, но там только общие настройки, пользователя я пока не учитываю (блог как никак). На работе такие штуки в коде до сих пор хранятся. Мысль вынести в БД была только для того что-бы можно было потом действительно как в реестре через админку редактировать параметры той или иной функциональности.

Обсуждение закрыто.