Core Setting

The Setting component provides a generic interface for handling configuration options. Configuration data can be stored in the database or the file system and can be manipulated through a GUI or the command line.

Integration

Initialization

The first step is to initialize a repository. A repository is a container of setting options of a specific component. The repository can either be stored in the database or in the file system using the appropriate storage engine. All options in a repository are organized in groups.

Note

If the repository does not yet exists, it'll be created on the fly on storage.

The syntax to initialize a repository is as follows:

\Cx\Core\Setting\Controller\Setting::init('<component>', '<group>', '<engine>');

Where the arguments have the following meaning:

Argument	Description	Optional
<component>	The component to load the options from. I.e: 'Shop'	No
<group>	Load only the options of group <group>	Yes
<engine>	Set engine to use	Yes

Example

Initialize repository of component TodoManager with engine FileSystem:

\Cx\Core\Setting\Controller\Setting::init('TodoManager', null, 'FileSystem');

This will store the setting data in the file config/TodoManager.yml.

Add/define configuration options

A setting repository can hold an unlimited number of options.

The syntax to add a new configuration option is as follows:

\Cx\Core\Setting\Controller\Setting::add(
    '<option-name>',
    '<option-value>',
    <order-id>,
    '<option-type>',
    '<option-data>',
    '<group>'
);

Where the arguments have the following meaning:

Argument	Description	Optional
<option-name>	The name of the configuration option to add	No
<option-value>	The initial default value of the configuration option	No
<order-id>	An integer used to put the option in order (in a GUI) in relation to the other defined configuration options. The higher the integer is, the later will the option be parsed (in relation to other options having a lower integer set).	Yes
<option-type>	Any of the available option types. Defaults to 'text'.	Yes
<option-data>	Additional option types specific data. I.e. for option type Radio the available radio options are defined through this argument.	Yes
<group>	Assign the option to the specified group. If left empty, the option will be added to the last registered/initialized group.	No

Example

Warning

The repository must have been initialized before a new option can be added.

Add a simple text option to group config:

\Cx\Core\Setting\Controller\Setting::add(
    'simpleTextOption',
    'defaultText',
    1,
    \Cx\Core\Setting\Controller\Setting::TYPE_TEXT,
    null,
    'config'
);

Add settings for a component

The easiest way to add settings for a component is to specify them in Component.yml. The structure defined for this is as follows:

<group>:
  -
    name: <option-name>
    value: <option-value>
    ord: <order-id>
    type: <option-type>
    values: <option-data>
    flags:
      - <flag>
      ...

The placeholders have the exact same meaning as specified in the table above. All indexes except for flags are mandatory. The following flags are known:

user: Creates a user-specific setting.
preInit: Set this if you need this setting to be available in preInit hooks.

The "section" is automatically set to the component's name.

By default the "Database" engine is used, unless one of the component's settings has the preInit flag set in which case the "FileSystem" engine is used for all settings for this component.

Show configuration GUI

A simple configuration GUI can be generated from an initialized setting repository. If the setting repository contains more than one group, then only the options of a selected group can get parsed or the options of each group can be parsed into a separate tab.

The basic syntax is as follows:

\Cx\Core\Setting\Controller\Setting::show(
    <template-object>,
    '<url-of-current-section>',
    '<component>',
    '<tab-name>',
    '<text-variable-prefix>',
    <readonly>
);

Where the arguments have the following meaning:

Argument	Description	Optional
<template-object>	Instance of \Cx\Core\Html\Sigma into which the configuration GUI will be parsed into. The instance can either be empty (no template loaded) or have a custom template set to be used for parsing the configuration GUI. If the instance has no template set, then the default template for the configuration GUI will be used and parsed. After the GUI has been parsed it can be fetched from the template instance using the method \Cx\Core\Html\Sigma::get().	No
<url-of-current-section>	The URI of the current backend section. I.e.: /cadmin/Config	No
<component>	The component to parse the options from. If not set, then options of the currently initialized component are parsed.	Yes
<tab-name>	When set, it will generate a tab by the name <tab-name>. This is used if there are more than one group present in the setting repository.	Yes
<text-variable-prefix>	For each configuration option, a label and tooltip can be assigned through a Text-Variable. The taken Text-Variable for the label of the option is based on the capitalized form of the option's name and the prefix <text-variable-prefix>. The <text-variable-prefix> defaults to TXT_. I.e. for option simpleTextOption the Text-Variable for the label has the form TXT_SIMPLETEXTOPTION. Note: According to the guidelines the prefix must have the following scheme: TXT_<COMPONENT>_. More information can be found here: Text-Variable.	Yes
<readonly>	Whether the configuration GUI shall be in read-only mode which does not allow any modification of the parsed options. Defaults to false	Yes

Example

The following generates the configuration GUI for the options of group general of component TodoManager:

$template = new \Cx\Core\Html();
\Cx\Core\Setting\Controller\Setting::init('TodoManager', 'general');
\Cx\Core\Setting\Controller\Setting::show(
    $template,
    '/cadmin/TodoManager/Setting',
    'TodoManager',
    'General',
    'TXT_TODOMANAGER_'
);
echo $template->get();

Store changes from configuration GUI

Changes made to any options in the configuration GUI can be updated in the repository using the method \Cx\Core\Setting\Controller\Setting::storeFromPost().

Example

Automatically store all options from POST-data (from auto-generated view):

\Cx\Core\Setting\Controller\Setting::init('TodoManager', 'general');
if (isset($_POST) && !empty($_POST['bsubmit'])) {
    \Cx\Core\Setting\Controller\Setting::storeFromPost();
}

Fetch data of options

The data of the configuration options can be accessed using the method \Cx\Core\Setting\Controller\Setting::getValue().

Warning

Before any data can be accessed, the setting repository must be initialized first.

Example

$mode = \Cx\Core\Setting\Controller\Setting::getValue('mode');

Once a setting repository has been initialized, it can be accessed in the same cx-request without having the need to re-initialize it again. To ensure the option is fetched from the repository of choice, simple add the repository's component as second argument to \Cx\Core\Setting\Controller\Setting::getValue():

$mode = \Cx\Core\Setting\Controller\Setting::getValue('mode', 'Config');

Global Configuration

The Global Configuration section (Administration > Global Configuration > System) does use this library to store and manage its configuration options. As a special extension to the Setting library, the configuration options of the Global Configuration are shadowed into the file config/settings.php. This is used to make the Global Configuration options available in a very early stage of the bootstrapping process.

Note

The Setting library is not available until the postInit-hook. To overcome this issue, the Global Configuration options are accessible through $this->cx->getConfig()->getBaseConfig($key) in earlier stages.

Warning

However, from the postInit-hook onwards you must always use the Setting library to access the Global Configuration options. Accessing the Global Configuration options through $this->cx->getConfig() after the postComponentLoad-hook (which is the predecessor of postInit) is regarded as deprecated code. More information can be found here: postInit.

Engines

The interface provides the following storage engines that can be used as the target medium for storage.

Database (default)

Stores the configuration options in the database (table contrexx_core_setting)

FileSystem

Stores the configuration options in the filesystem in plain YAML notation (in ''config/

.yml'')

Yaml ^Deprecated

Stores the configuration options as serialized objects in the filesystem in YAML notation (in ''config/

.yml'')

Option Types

The library supports the following option types.

Option	Type (PHP)	Type (CLI)	Description	Additional specific data	Examples
Dropdown	TYPE_DROPDOWN	dropdown	A HTML-select dropdown. Options are defined in attribute values either as a static comma-separated list or dynamic by referencing a callback function.	Static list: Separate options by comma: To use custom option keys, do use the scheme : Dynamic list: Use the following scheme to specify a callback function to fetch the available options: `{src:\Fully\Qualified\ClassName::Method()}`	`\Cx\Core\Setting\Controller\Setting::add( 'dropdownOption', '0', 1, \Cx\Core\Setting\Controller\Setting::TYPE_DROPDOWN, 'first-option,second-option,third-option', 'demo' );` `\Cx\Core\Setting\Controller\Setting::add( 'dropdownOption', '0', 1, \Cx\Core\Setting\Controller\Setting::TYPE_DROPDOWN, 'option1:first-option,option2:second-option,option3:third-option', 'demo' );` `\Cx\Core\Setting\Controller\Setting::add( 'dropdownOption', '0', 1, \Cx\Core\Setting\Controller\Setting::TYPE_DROPDOWN, '{src:\\' . __CLASS__ . '::getOptions()}', 'demo' );`
Multiselect	TYPE_DROPDOWN_MULTISELECT	dropdown_multiselect	A HTML-select element with multiple selection.	Options are defined analogous to type Dropdown	`\Cx\Core\Setting\Controller\Setting::add( 'multiselectOption', '0', 1, \Cx\Core\Setting\Controller\Setting::TYPE_DROPDOWN_MULTISELECT, '{src:\\' . __CLASS__ . '::getOptions()}', 'demo' );`
User profile attribute dropdown	TYPE_DROPDOWN_USER_CUSTOM_ATTRIBUTE	dropdown_user_custom_attribute	HTML-select dropdown of preconfigured profile attributes of users	-	`\Cx\Core\Setting\Controller\Setting::add( 'userAttributeOption', '0', 1, \Cx\Core\Setting\Controller\Setting::TYPE_DROPDOWN_USER_CUSTOM_ATTRIBUTE, null, 'demo' );`
User group dropdown	TYPE_DROPDOWN_USERGROUP	dropdown_usergroup	HTML-select dropdown of existing user groups	-	`\Cx\Core\Setting\Controller\Setting::add( 'userGroupOption', '0', 1, \Cx\Core\Setting\Controller\Setting::TYPE_DROPDOWN_USERGROUP, null, 'demo' );`
WYSIWYG	TYPE_WYSIWYG	wysiwyg	WYSIWYG-editor for HTML content	-	`\Cx\Core\Setting\Controller\Setting::add( 'wysiwygOption', '', 1, \Cx\Core\Setting\Controller\Setting::TYPE_WYSIWYG, null, 'demo' );`
File upload	TYPE_FILEUPLOAD	fileupload	Uploader-element	-	`\Cx\Core\Setting\Controller\Setting::add( 'wysiwygOption', '', 1, \Cx\Core\Setting\Controller\Setting::TYPE_FILEUPLOAD, null, 'demo' );`
Text	TYPE_TEXT	text	A regular HTML-input element	Set special input parsing behavior through JSON-encoded option `type` in attribute values. The following types are supported: `filesize`: causes the value to be converted into a literal representation of a file size (i.e.: 1 KB instead of 1024): `{"type":"filesize"}` `senderAddress`: add input validation for email address sender validation: `{"type":"senderAddress"}`	`\Cx\Core\Setting\Controller\Setting::add( 'wysiwygOption', '', 1, \Cx\Core\Setting\Controller\Setting::TYPE_TEXT, null, 'demo' );` `\Cx\Core\Setting\Controller\Setting::add( 'wysiwygOption', '', 1, \Cx\Core\Setting\Controller\Setting::TYPE_TEXT, '{"type":"filesize"}', 'demo' );`
Multiline text	TYPE_TEXTAREA	textarea	HTML-textarea	-	`\Cx\Core\Setting\Controller\Setting::add( 'wysiwygOption', '', 1, \Cx\Core\Setting\Controller\Setting::TYPE_TEXTAREA, null, 'demo' );`
E-mail	TYPE_EMAIL	email	HTML-input type for email	-	`\Cx\Core\Setting\Controller\Setting::add( 'emailOption', '', 1, \Cx\Core\Setting\Controller\Setting::TYPE_EMAIL, null, 'demo' );`
Checkbox	TYPE_CHECKBOX	checkbox	HTML-input type checkbox	-	`\Cx\Core\Setting\Controller\Setting::add( 'checkboxOption', '0', 1, \Cx\Core\Setting\Controller\Setting::TYPE_CHECKBOX, null, 'demo' );`
Radio	TYPE_RADIO	radio	HTMl-input type radio	Options are defined analogous to type Dropdown	`\Cx\Core\Setting\Controller\Setting::add( 'radioOption', '0', 1, \Cx\Core\Setting\Controller\Setting::TYPE_RADIO, '0:first-option,1:second-option,2:third-option', 'demo' );`
Date	TYPE_DATE	date	Date selector	-	`\Cx\Core\Setting\Controller\Setting::add( 'dateOption', '', 1, \Cx\Core\Setting\Controller\Setting::TYPE_DATE, null, 'demo' );`
Datetime	TYPE_DATETIME	datetime	Datetime selector	-	`\Cx\Core\Setting\Controller\Setting::add( 'dateTimeOption', '', 1, \Cx\Core\Setting\Controller\Setting::TYPE_DATETIME, null, 'demo' );`
Image	TYPE_IMAGE	image	An image selection option. Two modes are suppored: reference (default) and copy	Reference Mode reference is used to store the path to the selected image. Copy Mode copy is used to copy the selected image to the location set in attribute value.	`\Cx\Core\Setting\Controller\Setting::add( 'imageOption', '', 1, \Cx\Core\Setting\Controller\Setting::TYPE_IMAGE, null, 'demo' );` `\Cx\Core\Setting\Controller\Setting::add( 'imageOption', 'favicon.ico', 1, \Cx\Core\Setting\Controller\Setting::TYPE_IMAGE, '{"type":"copy"}', 'demo' );`
File content	TYPE_FILECONTENT	file	A HTML-textarea with content of specified file.	Specify path of file to edit in attribute values. Path to file must be relative to the installations document root.	`\Cx\Core\Setting\Controller\Setting::add( 'fileContentOption', '', 1, \Cx\Core\Setting\Controller\Setting::TYPE_FILECONTENT, 'robots.txt', 'demo' );`
Button ^Experimental	TYPE_BUTTON	button
Checkbox group ^Experimental	TYPE_CHECKBOXGROUP	checkboxgroup

Advanced usages

Conditional option adding

Add new configuration option only if it does not yet exist and throw exception in case the operation fails.

// initialize section
\Cx\Core\Setting\Controller\Setting::init('Demo', 'config', 'FileSystem');

// add new configuration option, if it does not yet exist
if (
    !\Cx\Core\Setting\Controller\Setting::isDefined('simpleTextOption') &&
    !\Cx\Core\Setting\Controller\Setting::add(
        'simpleTextOption',
        'defaultText',
        1,
        \Cx\Core\Setting\Controller\Setting::TYPE_TEXT,
        null,
        'config'
    )
) {
    throw new \Exception("Failed to add new configuration option");
}

Array populating options

If section is already initialized, we can define behavior of populating this section with data. For that purpose we have 5th parameter. Assuming we have already initialized section Config\Yaml and have following data in it's array: array(1,2), and by calling init of this section we would retrieve array(2,3,4). Then:

NOT_PUPULATE (default)

// would check if section exists and returns, doing no action; We still have array(1,2)
\Cx\Core\Setting\Controller\Setting::init('Config', '','Yaml', null, Setting::NOT_PUPULATE);

POPULATE

// would retrieve elements from Yaml and add elements that not exist to array; In the end we will have array(1,2,3,4)
\Cx\Core\Setting\Controller\Setting::init('Config', '','Yaml', null, Setting::POPULATE);

REPOPULATE

// would replace array with new data;  In the end we will have array(2,3,4);
\Cx\Core\Setting\Controller\Setting::init('Config', '', 'Yaml', null, Setting::REPOPULATE);

Switching section, engine, module

There are several ways to switch between section and engine once initialized.

By calling setEngineType (Recommended)

// initialize section
\Cx\Core\Setting\Controller\Setting::init('Config', '','Yaml');

//would switch to the section TodoManager, engine FileSystem and group config; If engine not exists - returns false;
\Cx\Core\Setting\Controller\Setting::setEngineType('TodoManager', 'FileSystem', 'config');

By calling init()

// initialize section
\Cx\Core\Setting\Controller\Setting::init('Config', '','Yaml');

//would switch to the section TodoManager, engine FileSystem and group config; if section not exists - would initialize it
\Cx\Core\Setting\Controller\Setting::init('TodoManager', 'config','FileSystem');

Fetching data

Fetch all configuration options at once:

getSettings() (Recommended)

Fetch all options from a repository:

\Cx\Core\Setting\Controller\Setting::init('TodoManager', '', 'FileSystem');
$engine = \Cx\Core\Setting\Controller\Setting::getSettings('TodoManager', 'FileSystem');
$data = $engine->getArraySettings();

Fetch options of a specific group of a repository:

\Cx\Core\Setting\Controller\Setting::init('TodoManager', '', 'FileSystem');
$data = \Cx\Core\Setting\Controller\Setting::getSettings('TodoManager', 'FileSystem', 'config');

getArray()

Fetch all options from a repository:

\Cx\Core\Setting\Controller\Setting::init('TodoManager', '', 'FileSystem');
$options = \Cx\Core\Setting\Controller\Setting::getArray('TodoManager');

Fetch options of a specific group of a repository:

\Cx\Core\Setting\Controller\Setting::init('TodoManager', '', 'FileSystem');
$options = \Cx\Core\Setting\Controller\Setting::getArray('TodoManager','config');

Display configuration options

Integrate external data into configuration GUI (like MailTemplate GUI)

// initialize section
\Cx\Core\Setting\Controller\Setting::init('Shop', 'config');

// show external generated view of MailTemplate
$objTemplate = new \Cx\Core\Html\Sigma('/path/to/html/template');
\Cx\Core\Setting\Controller\Setting::show_external(
    $objTemplate,
    'Mail Templates',
    \MailTemplate::overview(
         'TodoManager',
         'config',
         \Cx\Core\Setting\Controller\Setting::getValue(
             'numof_mailtemplate_per_page_backend'
         )
    )->get()
);
\Cx\Core\Setting\Controller\Setting::show_external(
    $objTemplate,
    'Manage Mail Template',
    \MailTemplate::edit('shop')->get()
);

// TODO: instead of using echo, do assign the returned string to a template variable 
echo $objTemplate->get();

Update configuration option

Update single configuration option

// initialize section
\Cx\Core\Setting\Controller\Setting::init('TodoManager', null, 'FileSystem');

// set new value to configuration option
\Cx\Core\Setting\Controller\Setting::set('email', $email);

// store changed configuration option
if (\Cx\Core\Setting\Controller\Setting::update('email')) {
    echo 'Config successfully updated';
}

Update multiple configuration options

// initialize section
\Cx\Core\Setting\Controller\Setting::init('TodoManager', null, 'FileSystem');

// set new values to configuration options
\Cx\Core\Setting\Controller\Setting::set('email', $email);
\Cx\Core\Setting\Controller\Setting::set('address', $address);
\Cx\Core\Setting\Controller\Setting::set('user', $user);

// store all changed configuration options
if (\Cx\Core\Setting\Controller\Setting::updateAll() === true) { // updateAll() returns NULL on a no-op
    echo 'Config successfully updated';
}

CLI

The Setting component is available through the CLI interface of Cloudrexx.

It provides the ability to list all options from a specific repository or to add/remove and get/set options in a repository.

Fetch options

Synopsis

cx Setting list <component> [-group=<group>] [-engine=<engine>] [-repository=<repository>]

Argument	Description	Optional
<component>	The component to load the options from. I.e: 'Shop'	No
<group>	Load only the options of group	Yes
<engine>	Set engine to use	Yes
<repository>	Relative path to the directory where the repository is located. I.e. if the repository of the component Shop is located at tmp/data/Shop.yml then you would set this argument to: tmp/data This option defaults to directory "config" of the Cloudrexx installation.	Yes

Example

List all options from Yaml repository of component Config:

cx Setting list Config -engine=Yaml

Add option

Synopsis

cx Setting add <component> [-group=<group>] [-engine=<engine>] [-repository=<repository>] <name> <value> <ord> <type> <values>

Argument	Description	Optional
<component>	The component to load the options from. I.e: 'Shop'	No
<group>	Load only the options of group	Yes
<engine>	Set engine to use	Yes
<repository>	Relative path to the directory where the repository is located. I.e. if the repository of the component Shop is located at tmp/data/Shop.yml then you would set this argument to: tmp/data This option defaults to directory "config" of the Cloudrexx installation.	Yes
<name>	The name of the configuration option to add	No
<value>	The initial default value of the configuration option	No
<ord>	An integer used to put the option in order (in a GUI) in relation to the other defined configuration options. The higher the integer is, the later will the option be parsed (in relation to other options having a lower integer set).	No
<type>	Any of the available option types. Defaults to 'text'.	No
<values>	Additional option types specific data. I.e. for option type Radio the available radio options are defined through this argument. Note: For option types without specific data do set to an empty quoted string `''`	No

Examples

cx Setting add Config -group=site -engine=Yaml useVirtualLanguageDirectories on 1 radio on:TXT_ACTIVATED,off:TXT_DEACTIVATED

cx Setting add Config -group=administrationArea -engine=Yaml portBackendHTTPS 80 1 text ''

Alter option

Synopsis

cx Setting alter <component> [-group=<group>] [-engine=<engine>] [-repository=<repository>] <name> <new_type> <new_values> [<new_group> [<new_ord>]]

Argument	Description	Optional
<component>	The component to load the option from. I.e: 'Shop'	No
<group>	The group to load the option from	Yes
<engine>	Set engine to use	Yes
<repository>	Relative path to the directory where the repository is located. I.e. if the repository of the component Shop is located at tmp/data/Shop.yml then you would set this argument to: tmp/data This option defaults to directory "config" of the Cloudrexx installation.	Yes
<name>	The name of the configuration option to alter	No
<new_type>	Any of the available option types.	No
<new_values>	Additional option types specific data. I.e. for option type Radio the available radio options are defined through this argument. Note: For option types without specific data do set to an empty quoted string `''`	No
<new_group>	New group to assign the option to	Yes
<new_ord>	An integer used to put the option in order (in a GUI) in relation to the other defined configuration options. The higher the integer is, the later will the option be parsed (in relation to other options having a lower integer set).	Yes

Examples

cx Setting alter Config -group=site -engine=Yaml useVirtualLanguageDirectories checkbox ''

cx Setting alter Config -group=administrationArea -engine=Yaml portBackendHTTPS text '' administrationArea 10

Delete option

Synopsis

cx Setting delete <component> [-group=<group>] [-engine=<engine>] [-repository=<repository>] <name>

Argument	Description	Optional
<component>	The component to load the options from. I.e: 'Shop'	No
<group>	Load only the options of group	Yes
<engine>	Set engine to use	Yes
<repository>	Relative path to the directory where the repository is located. I.e. if the repository of the component Shop is located at tmp/data/Shop.yml then you would set this argument to: tmp/data This option defaults to directory "config" of the Cloudrexx installation.	Yes
<name>	The name of the configuration option to delete	No

Example

Delete option used to define if virtual language directories shall be used:

cx Setting delete Config -engine=Yaml useVirtualLanguageDirectories

Update option

Synopsis

cx Setting set <component> [-group=<group>] [-engine=<engine>] [-repository=<repository>] <name> <value>

Argument	Description	Optional
<component>	The component to load the options from. I.e: 'Shop'	No
<group>	Load only the options of group	Yes
<engine>	Set engine to use	Yes
<repository>	Relative path to the directory where the repository is located. I.e. if the repository of the component Shop is located at tmp/data/Shop.yml then you would set this argument to: tmp/data This option defaults to directory "config" of the Cloudrexx installation.	Yes
<name>	The name of the configuration option to update	No
<value>	The new value of the configuration option to store	No

Example

Activate the use of virtual language directories:

Setting set Config -engine=Yaml useVirtualLanguageDirectories on

Fetch option

Synopsis

cx Setting get <component> [-group=<group>] [-engine=<engine>] [-repository=<repository>] <name>

Argument	Description	Optional
<component>	The component to load the options from. I.e: 'Shop'	No
<group>	Load only the options of group	Yes
<engine>	Set engine to use	Yes
<repository>	Relative path to the directory where the repository is located. I.e. if the repository of the component Shop is located at tmp/data/Shop.yml then you would set this argument to: tmp/data This option defaults to directory "config" of the Cloudrexx installation.	Yes
<name>	The name of the configuration option to fetch	No

Example

Get if the usage of virtual language directories is activated:

1	`cx Setting get Config -engine=Yaml useVirtualLanguageDirectories`

API Documentation

TODO: This should be moved into the API documentation

static function changed()
- TRUE, if minimum one of the loaded setting has been changed (updateAll() will check these)
- \Cx\Core\Setting\Controller\Setting::changed()
static function tab_index($tab_index=null)
- Get or set the current tab
- \Cx\Core\Setting\Controller\Setting::tab_index(integer $tab_index)
static function init($section, $group = null, $engine = 'Database', $fileSystemConfigRepository = null, $populate = 0)
- Activate or load the setting for a specific module (as the case may be constricted on a given group)
- Section must be set up
- The Engine type Database or File system, Default to set Database, You may use engine type FileSystem
- Database engine: \Cx\Core\Setting\Controller\Setting::init($section, $group,$engine = 'Database')
- FileSystem engine: \Cx\Core\Setting\Controller\Setting::init($section, $group,$engine = 'FileSystem')
- Yaml engine: \Cx\Core\Setting\Controller\Setting::init($section, $group,$engine = 'Yaml')
- Once you initialize section, it is stored in global Setting array and you don't not need to reinitialize it, unless other specified.
- You may set behavior of what to do when section already exists with $populate:
  - \Cx\Core\Setting\Controller\Setting::NOT_POPULATE - do nothing, return; default behavior
  - \Cx\Core\Setting\Controller\Setting::POPULATE - add values to existing array
  - \Cx\Core\Setting\Controller\Setting::REPOPULATE - reload section; default behavior in old logic
  - Example: \Cx\Core\Setting\Controller\Setting::init($section, $group, $engine, null, \Cx\Core\Setting\Controller\Setting::POPULATE)
static function flush()
- Reset the content of the class (forces for example the re-initialization at the next getArray())
- \Cx\Core\Setting\Controller\Setting::flush()
static function getArray($section = null, $group=null)
- Returns array of current engine based on $section and $group.
- If no section is specified, currently set section is taken into consideration.
static function getValue($name, $section = null)
- Returns the value for the setting with the given name
- If $section is specified, loads value from $section, otherwise loads value from currently set section
- \Cx\Core\Setting\Controller\Setting::getValue($name, $section)
static function set($name, $value)
- Set the value of the setting with the given name
- \Cx\Core\Setting\Controller\Setting::set($name,$value)
static function updateAll()
- Stores the loaded settings into the database or FileSystem\Yaml (only if minimum one change have been done)
- \Cx\Core\Setting\Controller\Setting::updateAll()
static function update($name)
- Stores one setting (without check!)
- Updates the value for the given name in the settings,note that this method does not work for adding new settings.
- \Cx\Core\Setting\Controller\Setting::update($name)
'static function add($name, $value, $ord=false, $type='text', $values=, $group=null)'''
- Adds a new setting to the group
- This method is only used for an installation script for a new module or will be used in update.
- \Cx\Core\Setting\Controller\Setting::add( $name, $value, $ord, $type, $values,$group)
static function storeFromPost()
- Update and store all settings found in the post array
- \Cx\Core\Setting\Controller\Setting::storeFromPost()
static function delete($name=null, $group=null)
- Deletes the setting with the given name. Only for advanced users!
- Delete one or more records from the Database or FileSystem
- At least one of the parameter values must be non-empty.
- \Cx\Core\Setting\Controller\Setting::delete($name, $group)
static function show(&$objTemplateLocal, $uriBase, $section=, $tab_name=, $prefix='TXT_')
- Shows the settings in the given template object
- \Cx\Core\Setting\Controller\Setting::show($objTemplate, $uriBase, $section, $tab_name, $prefix)
static function show_section(&$objTemplateLocal, $section=, $prefix='TXT_')
- Shows the settings for the given group in the given template object
- \Cx\Core\Setting\Controller\Setting::show_section($objTemplate, $section, $prefix)
static function show_external(&$objTemplateLocal, $tab_name, $content)
- Includes an external site (e.g. MailTemplates) into the Setting view (as a new tab)
- Adds an external settings view to the current template
- \Cx\Core\Setting\Controller\Setting::show_external($objTemplate, $tab_name, $content)
static function storeFromPost()
- Stores POST data and saves it to Database\FileSystem\Yaml using set() and updateAll().
- Should always be used to store POST data.
- \Cx\Core\Setting\Controller\Setting::storeFromPost()
static function getSectionEngine($section = null, $engine = null)
- Returns engine of section.
- If no section specified takes currenty set section.
- If section don't exist throws exception.
- If $engine don't exist takes default engine of section.
- \Cx\Core\Setting\Controller\Setting::getSectionEngine($section, $engine)
static function getSectionEngine($section = null, $engine = null)
- Returns engine of section.
- If no section specified takes currenty set section.
- If section don't exist throws exception.
- If $engine don't exist takes default engine of section.
- \Cx\Core\Setting\Controller\Setting::getSectionEngine($section, $engine)
static function setSectionEngine($oSectionEngine, $populate)
- Sets engine for section. Uses by init() but can also be called separately;
- If engine of section already exists - acts depending of $populate behavior:
  - \Cx\Core\Setting\Controller\Setting::NOT_POPULATE - do nothing, return; default behavior
  - \Cx\Core\Setting\Controller\Setting::POPULATE - add values to existing array
  - \Cx\Core\Setting\Controller\Setting::REPOPULATE - reload section; default behavior in old logic
- \Cx\Core\Setting\Controller\Setting::setSectionEngine($oSectionEngine, $populate)
static function setEngineType($section, $engine, $group = null)
- Sets current section, engine and group;
- Once all data is initialized, should be used instead of init(); in case you want to get specific section\engine\group (i.e. in tabs)!
- \Cx\Core\Setting\Controller\Setting::setEngineType($section, $engine, $group)
static function addToArray($name, $value)
- Adds an element to array.
- Current section and engine are taken into consideration.
- \Cx\Core\Setting\Controller\Setting::addToArray($name, $value)
static function getSettings($section = null, $engine = null, $group = null)
- Basic method to get data array easy based of section, engine and group. Recommended to use!
- If section is null returns whole multidimensional array of all engines and sections.
- If section is set returns multidimensional array of all engines of that section.
- If section and engine is set returns data array from that section and engine.
- If section, engine and group are specified returns elements of concrete group from section and engine array.
- ''\Cx\Core\Setting\Controller\Setting::getSettings($section = null, $engine = null, $group = null)
static function getCurrentSettings()
- Returns data array based on currently set section, engine and group.
- Current section, engine and group can be set up via \Cx\Core\Setting\Controller\Setting::setEngineType($section, $engine, $group)
- Recommended to use in most of cases (i.e. in storeFromPost or other functions that work with data arrays).
- \Cx\Core\Setting\Controller\Setting::getCurrentSettings()