alex-kalanis / kw_confs
Configs for accessing settings in KWCMS
Requires
- php: >=7.4.0
- alex-kalanis/kw_paths: >=4.0 <5
- alex-kalanis/kw_routed_paths: >=3.0 <4
Requires (Dev)
- friendsofphp/php-cs-fixer: ^3.0
- phpstan/phpstan: ^1.0
- phpstan/phpstan-phpunit: ^1.0
- phpunit/phpunit: >=8.0 <=9
- shipmonk/composer-dependency-analyser: ^1.4
README
Define used configurations inside the KWCMS tree. Parse them and return them.
PHP Installation
composer.phar require alex-kalanis/kw_confs
(Refer to Composer Documentation if you are not familiar with composer)
This package contains example file from KWCMS bootstrap. Use it as reference.
This config bootstrap is connected with KWCMS modules. Using it outside KWCMS means you need to know the tree structure of module system and positioning configs there.
The idea is about configs which are separated not just by their name (single namespace) but also with their module name - so you can use the same key in more modules with a bit different meanings.
The basic config itself is simple php file with defined array variable "$config" in which are stored key-value pairs like in normal php array. You need to specify module - it will be automatically set there into content array when config loads.
It's also possible to use your own loader which will read your config files by your own rules. So you can connect reading configurations from DB or INI file and that all will still behave the same way. Just it's need to respect that loader's input is module and sometimes conf name and output is array of key-value pairs which will be set into config array with module as primary key.
Examples:
For module 'image as part of content' there came array ['your internal config key' => 'this value will be get', 'another key' => false, ]
print \kalanis\kw_confs\Config::get('image as part of content', 'your internal system key', 'dummy');
And it returns 'dummy'
print \kalanis\kw_confs\Config::get('image as part of content', 'your internal config key', 'nope');
And it returns 'this value will be get'
The best usage is inside the controller classes across the other modules - you just fill
Config::get()
with your keys. It is possible to make a whole class which returns
the wanted configs which will be instance of IConf
and then pass it into lang loader.