Сейчас для себя делаю один скрипт. В нем присутствует файл настроек (json). Возник вопрос: как работать с настройками, например, в функциях? Вижу несколько выходов: 1. Глобальный массив $config. В функциях писать global $config или обращаться через $GLOBALS. 2. Класс и статические переменные. В функциях ничего не надо дополнительно писать, сразу обращаться к конфигу через config::$param. 3. Константы. Ну это не подходит, так как информация может меняться (конфиг) в процессе работы. 4. Функция, возвращающая конфиг. У функций, вроде, глобальная область видимости, если они не описаны внутри класса. Как вы считаете, какой вариант лучший?
а чем константы не подходят ? их нельзя менять, но можно ведь присвоить значение в переменную и делать с ней все что надо, что у вас там в файле настроек?Вообще конечно интересно что у вас там такое, что нужно менять ...
какой-то объект, который будет передаваться по цепочки в контроллеры/виджеты/блоки и из которого можно будет получить любой сервис и настройки для него. Ну или на худой конец статический класс, который будет делать то же самое
эм, ну вообще-то PHP: <?php $thing = 4221; define('THING', $thing); $thing = 'test'; echo THING; ?> данный код выведет именно 4221. Так что не подходит. Константы на то и константы, чтобы иметь всегда одно и то же значение. Пример вещицы из файла настроек: id приложения, может меняться по get-запросу (а-ля ?app_id=45192). и это id приложения используется почти во всех функциях.
start2dev я не это написал и не это имелл ввиду, почему не передавать ваш массив в конструктор класса?
Аллах. Для этого придуман шаблон реестр (Registry). Это типичный синглтон. Класс регистрируется при создании экземпляра приложения и хранит в себе настройки. Из любого места программы можно обращаться к данным этого класса. Например: PHP: <?php $config = Registry::getInstance()->config;
бл я, шаблоны шаблонами, объекты объектами, смотря что делается и где - и регистр может быть вообще не уместным решением...
Вообще хорошо бы подумать над системой связей. Чтобы подгружать что надо централизовано. Контроллеры при загрузке делают записи в реестр. С другой стороны, обращение к ветке контроллера в реестре приводит к подгрузке контроллера.
ну это приминительно конкретно к реестру. Когда нам надо получить из него какую-нибудь информацию, которую в него обычно записывает другой контроллер во время инициализации. Мы ее запрашиваем (обращаясь к ветке ресстра с именем нужного контроллера), контроллер подгружается и инициализируется, записывая в реестр нужные данные. Конечно, не нужно при инициализации реестра создавать в нем ветки для каждого контроллера - надо при обращении к несуществующей ветки проверять наличие контроллера и создавать ее.
вот я о чём и говорю, у меня вообще контроллеры в никакие реестры ничего не записывают, так что всё зависит от всего
Re: Как работать с конфигурационными настройками в программе ужас-ужас я делаю таки config::get() и config::set() хотябы для того, чтобы избежать бесконечных PHP: $value = isset(config::$param['key']) ? config::$param['key'] : NULL; у меня это завернуто в get() плюс оставляет возможность для развития, например можно придумать реализацию своего session/flash variables через по тому же принципу правильно - может меняться в run-time и конфиги имеют свойство распухать. не напасёшся на него констант если у тебя всё в процедурном стиле, то почему бы нет. а смешивать классы и функции как-то непоследовательно. imho, реестр через класс со статическими методами. не надо заниматься самообманом а-ля config::getInstance() - в данном случае это онанизм, безвредный, но бесполезный.
я не спорю. когда надо что-то наскоро проверить или сконвертировать разово - нормально. а ТС планирует какую-то серьезную систему с настоящим конфигом. при таких раскладах глобалы это запрограммированная головная боль.
artoodetoo кроме шуток, започем состряпаешь/спроектируешь систему юзерконфиг<->БД если заранее не известны параметры, которые хранить?
Конфиги с неопределённым набором полей в БД можно представить как минимум двумя способами — либо как сериализованный массив в одном BLOB, либо как таблица имя-значение [sql]create table config(fieldname varchar(80), fieldvalue text);[/sql] Вычитываем с базы, фигачим в реестр. Эффективнее иметь кеш (файловый) в котором будет слепок текущего состояния этой таблицы. При изменении таблицы кеш сбрасываем.
Если конфиг привязан к конкретной сущности, например пользователю, то усложняем схему еще одним полем: [sql]create table config(userid int, fieldname varchar(80), fieldvalue text)[/sql] это кагбе eav