diff --git a/README.md b/README.md
index 0cfd3c6..bb5d247 100644
--- a/README.md
+++ b/README.md
@@ -159,14 +159,17 @@ name.
Property page is used to define the layout of UI form for displaying object fields (known also as _properties_).
Property page configuration requires a JSON content file with the layout details. Object fields are wrapped in so-called
_property controls_. There are also different kind of _controls_ which are not related to properties
-like `separator`, `label` or _grouping controls_ like `group`, `columns`, `table` or `tabs`. The file structure is
-defined in JSON Schema files found [here](src/main/resources/json-schemas).
+like `separator`, `label` or _grouping controls_ like `group`, `columns`, `table` or `tabs`. The file structure is
+defined in JSON Schema files found [here](src/main/resources/json-schemas). For additional details on control-specific
+properties please check
+[this](#controls) section.
Below are some of the general details about grouping limitations:
- `columns` can have up to 4 nested controls, which are not a grouping controls.
- `table` can use only `checkbox`, `combo`, `date`, `datetime`, `money`, `number`, and `text` controls. Constraints are
- not allowed for these controls, and they are always required (except for checboxes, they have always only `true/false`
+ not allowed for these controls, and they are always required (except for checkboxes, they have always
+ only `true/false`
values). Tables cannot be present in any grouping control.
- `group` does not allow to nest another group within it. However `columns` or `tabs` are allowed.
- `tabs` allows to nest `columns` and `groups` without `tabs` nested.
@@ -179,15 +182,69 @@ Property page can be run in one of multiple context modes:
- `INSERT` - properties are editable but all `id` fields are hidden
- `EDIT` - properties are editable, `id`s of objects are passed to the property page
-#### Visibility and requirement constraints
+#### Accessibility constraints
-Apart from controls defined in `table`, property controls can have a `required` property defined, which tells if the
-value of property must be provided or is optional. For `checkbox` requirement means, the checkbox has to be checked.
+Apart from controls defined in `table`, property controls can have properties, which tells whether they should be
+readonly, required or visible. The basic ones are:
-Additionally, all controls apart from `table` nested properties and `columns` can have a visibility and requirement
-constraints defined. Visibility constraint tells the control should be hidden. Requirement constraint overwrites
-`required` property if specified. Constraints can be defined as [condition](#conditions) (visibility or requirement is
-determined based on the values of other properties) or by defining allowed property page context modes.
+- `required` property tells if the value of property must be provided or is optional. For `checkbox` requirement means,
+ the checkbox has to be checked.
+- `readonly` property allows to make control always read only. Please note if property page is opened in `READONLY`
+ context, this property is always overwritten to `true`
+
+To have more fine-grained control over properties behavior they can be configured with `constraints` node. There are
+three categories of constraints:
+
+- `visibility` constraint tells whether the control should be hidden
+- `requirement` constraint tells whether the control should be required and overwrites `required` property setting
+- `modifiable` constraint tells whether the control should be modifiable and overwrites `readonly` property setting.
+ Please note it has reversed meaning to the `readonly` - when resolved condition will return positive result, the
+ property can be modified.
+
+This applies to all controls apart from following exclusions:
+
+- `table` nested properties and `columns` are not controllable in such way
+- `group`, `tabs`, `label` and `separator` have only `visibility` constraint
+
+Constraints can be defined in two ways:
+
+- as [conditions](#conditions) (accessibility is determined based on the values of other properties)
+- by defining property page [context mode](#context-mode) in which behavior should be applied.
+
+#### Controls
+
+Apart from common properties described in the previous sections, controls can have many properties specific to them.
+Each control has also `type` property, which can take one of the values presented in the [main](#property-page) section
+and describes the control type. Property controls have to define `property` control to tell, which value will be read
+or write. For some controls (see `table`) it has additional meaning.
+
+##### Table
+
+| Property name | Type | Required | Description |
+|---------------|-----------|----------|--------------------------------------------------------------------------------------------------------------------------------------|
+| `label` | `string` | No | Label with the name of the table |
+| `fixed` | `boolean` | No | When set to yes, the possibility of adding or removing new rows should be forbidden (only modification of existing rows is possible) |
+| `property` | `string` | Yes | Root property name, maps to `java.util.List` field in the database entity |
+| `controls` | `array` | Yes | Array of controls for display root property properties. They are relative to the root `property`. |
+
+##### Combobox and radio button
+
+Both `combobox` and `radio` controls have to load some static or dynamic dictionary defined through `loadSettings`
+property. It can have one of two structures depending on the type of dictionary.
+
+For static dictionaries:
+
+| Property name | Type | Required | Description |
+|---------------|-----------|----------|----------------------------------------------------------------------------------------------|
+| `dictionary` | `string` | Yes | Name of the dictionary from the [zip configuration](#zip-configuration) |
+| `sortByLabel` | `boolean` | No | By default dictionary values are sorted by the values keys. This option allows to change it. |
+
+For dynamic dictionaries:
+
+| Property name | Type | Required | Description |
+|-----------------|----------|----------|---------------------------------------------------------------------------------------------------------------|
+| `type` | `string` | Yes | Name of the type, which should be queried |
+| `qualification` | `string` | No | Additional qualification to narrow the result. Qualification is a regular [condition](#conditions-processing) |
## Conditions processing
diff --git a/pom.xml b/pom.xml
index 0a9957f..80f9f8c 100644
--- a/pom.xml
+++ b/pom.xml
@@ -28,7 +28,7 @@
com.avispa
ecm
- 2.2.0-SNAPSHOT
+ 2.2.0
Avispa ECM
Simple ECM solution
diff --git a/src/main/resources/json-schemas/control-template/combo-template.json b/src/main/resources/json-schemas/control-template/combo-template.json
index 8b01cf5..fd408d9 100644
--- a/src/main/resources/json-schemas/control-template/combo-template.json
+++ b/src/main/resources/json-schemas/control-template/combo-template.json
@@ -27,7 +27,10 @@
"sortByLabel": {
"type": "boolean"
}
- }
+ },
+ "required": [
+ "dictionary"
+ ]
},
{
"additionalProperties": false,