Started to add some documentation

README.md

@@ -55,6 +55,7 @@ use Symfony\Component\Validator\Constraints as Assert;
 
 #[Settings] // The settings attribute makes a simple class to settings
 class TestSettings {
+    use SettingsTrait; // Disable constructor and __clone methods
 
     //The property is public here for simplicity, but it can also be protected or private
     #[SettingsParameter(type: StringType::class, label: 'My String', description: 'This value is shown as help in forms.')]

docs/concepts.md

@@ -0,0 +1,33 @@
+---
+layout: default
+title: Concepts
+nav_order: 2
+---
+
+# Concepts
+
+This section describes the basic concept of the settings-bundle.
+
+## Settings
+
+Settings are the main concept and the core of the settings-bundle.
+To be typesafe, each settings is implemented as a class, which contains a set of parameters as properties.
+Instances of this class are retrieved via the SettingsManager and contain the current configuration.
+
+The idea behind the settings class is that they contain all necessary information and configuration of the settings as code metadata
+in form of attributes. This allows to make all necessary changes in a single file.
+
+## Parameters
+
+Parameters are properties inside a settings class, whose values are managed by the settings-bundle. The metadata of the parameters are used to determine how to handle the parameters (e.g. which parameter type to use, how to render them in forms, etc.).
+
+## Schemas
+
+The Settings and ParameterSchemas are a representation of the metadata of settings classes. They dont contain any data, but describe the structure of settings, their configuration and behavior. The schemas are used in other parts of the bundle to determine what to do.
+
+The schemas for specific settings classes can be retrieved by the `SchemaManagerInterface` service.
+
+## Storage adapters
+The settings-bundle is designed to be storage backend. That means that almost all functionality is implemented independently of a concrete storage backend. Therefore you can use all kind of different storage backends (files, database, etc.) and even implement your own storage backend without changing other parts of the bundle.
+
+The concrete storage implentation is done via storage adapters, which must implement the `StorageAdapterInterface`. The bundle comes with a few default storage adapters, but you can also implement your own storage adapters.

docs/usage/settings.md

@@ -0,0 +1,50 @@
+---
+title: Keybindings
+layout: default
+parent: Usage
+---
+
+# Defining settings
+
+Settings are defined as classes, which contain the parameters as properties. The classes are marked with the `#[Settings]` attribute, which makes them
+managable by the settings-bundle. Besides the attribute, the class is basically just a normal PHP class, which can contain any kind of methods and properties.
+Only classes with the `#[Settings]` attribute and which are contained in on of the configured settings directories will be usable by the settings-bundle. By default, this means that you should put them into the `src/Settings` directory of your symfony project (or a subfolder of it).
+
+Settings classes should be suffixed by `Settings` (e.g. `MySettings`), but this is not required.
+
+The properties of the class, which should be filled by the settings-bundle, are marked with the `#[SettingsParameter]` attribute. This attribute contains information about how the data of the parameter should be mapped to normalized data for the storage adapter and how the parameter should be rendered in forms, etc.
+
+```php
+<?php
+// src/Settings/TestSettings.php
+
+namespace App\Settings;
+
+use Jbtronics\SettingsBundle\Settings\Settings;
+use Jbtronics\SettingsBundle\Settings\SettingsTrait;
+use Jbtronics\SettingsBundle\Settings\SettingsParameter;
+use Jbtronics\SettingsBundle\ParameterTypes\StringType;
+use Jbtronics\SettingsBundle\ParameterTypes\IntType;
+use Symfony\Component\Validator\Constraints as Assert;
+
+
+#[Settings] // The settings attribute makes a simple class to settings
+class TestSettings {
+    use SettingsTrait; // Disable constructor and __clone methods
+
+    //The property is public here for simplicity, but it can also be protected or private
+    #[SettingsParameter(type: StringType::class, label: 'My String', description: 'This value is shown as help in forms.')]
+    public string $myString = 'default value'; // The default value can be set right here in most cases
+
+    #[SettingsParameter(type: IntType::class, label: 'My Integer', description: 'This value is shown as help in forms.')]
+    #[Assert\Range(min: 5, max: 10,)] // You can use symfony/validator to restrict possible values
+    public ?int $myInt = null;
+}
+```
+
+The parameter values are filled by the settings-bundle via reflection. Therefore the properties can be either public, where you access the properties directly, or protected/private, where you have to use the getter/setter methods. Please note that the properties get accessed directly via reflection, so that the getter/setter methods are not called.
+
+The only useful way to retrieve an instance of a settings class is via the SettingsManager. You can not instantiate the class directly, as it would not be initialized correctly. Therefore you should add the `SettingsTrait` to your settings class, which disables the constructor, `__clone` method, etc. so that you can not instantiate the class directly by accident. If you need to perform some more complex initialization of your settings class, see below how to do that properly.
+
+## Defining default values for parameters
+