...
As mentioned in the previous documentation of Configuration management, the State is defined in a set of Configuration layers which in turn is a text file which described configuration by declaration.
The text language in which configuration is defined is called Digizuite configuration language (DCL).
The language
The language is a simple declarative language in which you can define the desired configuration. Below is a descriptions of the concepts.
Resources
A resource is the most basic thing in config management. Each resource entry corresponds to a single configuration in the Digizuite. It can be any configuration like a metafield, a user, or simply a single node in a tree metafield.
A resource has many properties, some that can be set as part of configuring the resource, and some that only exists after the resource has been created. This could for instance be an identifier that is generated on creation and used from other resources to easily link related resources together.
A resource can be created, updated and deleted by the config management system. This allows management of resources consistently between environments.
Resources use the following syntax in the DCL:
| Code Block |
|---|
resource metafield my_field {
name = "My Field"
}
```
### Variables
A `variable` is a special kind of value, where the value itself is not
defined as part of the configuration, but is provided from an external
system. This could be things like keys for Azure blob storage, which
is something that needs to be different between environments, but
where the underlying purpose of having a "blob storage" is the same.
Variables use the following syntax in the DCL:
```hcl
|
Variables
A variable is a special kind of value, where the value itself is not defined as part of the configuration, but is provided from an external system. This could be things like keys for Azure blob storage, which is something that needs to be different between environments, but where the underlying purpose of having a "blob storage" is the same.
Variables use the following syntax in the DCL:
| Code Block |
|---|
variable my_variable {
type = "string"
}
```
### Locals
Locals a temporary values that are used internally to allow easily reusing
certain values without repeating them over and over.
Locals use the following syntax in the DCL:
```hcl
|
Locals
Locals a temporary values that are used internally to allow easily reusing certain values without repeating them over and over.
Locals use the following syntax in the DCL:
| Code Block |
|---|
locals {
my_first_local = "Foo"
my_second_local = 42
}
```
### Layers
To achieve to ability to provide configurations that can be changed and
updated independently the config management system provides something called
|
Layers
To achieve to ability to provide configurations that can be changed and updated independently the config management system provides something called "layers".
...
Each
...
layer
...
is
...
a
...
separately
...
provided
...
configuration.
...
For
...
example
...
the
...
bottom
...
most
...
layer
...
is
...
likely
...
the
...
basic
...
DAM
...
configuration
...
that
...
is
...
required
...
for
...
the
...
DAM
...
to
...
even
...
be
...
able
...
to
...
start.
...
The
...
next
...
layer
...
up
...
might
...
be
...
the
...
Media
...
Manager
...
layer,
...
which
...
provides
...
all
...
the
...
metafields,
...
labels
...
and
...
other
...
configuration
...
Media
...
Manager
...
needs
...
to
...
start.
...
Layers
...
can
...
generally
...
be
...
separated
...
into
...
two
...
categories,
...
predefined
...
layers,
...
like
...
the
...
DAM
...
and
...
Media
...
Manager
...
layer
...
mentioned
...
above,
...
and
...
customized
...
layers
...
like
...
what
...
each
...
customer
...
would
...
do.
...
The
...
predefined
...
layers
...
are
...
not
...
editable
...
by
...
the
...
customer,
...
while
...
the
...
custom
...
layers
...
are.
...
Data
...
references
...
To
...
access
...
something
...
on
...
a
...
previous
...
layer
...
you
...
need
...
to
...
use
...
a
...
data reference.
...
Data
...
references
...
looks
...
like
...
normal
...
resources,
...
but
...
rather
...
than
...
creating
...
a
...
resource
...
that
...
matches
...
the
...
specified
...
description,
...
it
...
checks
...
all
...
previous
...
layers
...
for
...
a
...
unique
...
resource
...
that
...
looks
...
like
...
that
...
specified
...
definition.
...
Once
...
you
...
have
...
a
...
data
...
reference,
...
you
...
can
...
either
...
use
...
the
...
properties
...
when
...
creating
...
new
...
resource,
...
or
...
use
...
the
...
patch
...
functionality
...
to
...
modify
...
the
...
resource.
...
Data
...
references
...
use
...
the following
...
syntax
...
in
...
the
...
DCL:
...
| Code Block |
|---|
data metafield my_field {
Name = "My target field"
}
```
### Patches
The change a resource in a previous layer patches can be used. A patch takes
a target to update, and the new values the properties should have. It is only
necessary to specify the properties that should actually change in the patch
definition.
The target for a patch is always a data reference. If resource is defined
in the same layer, you can just go edit it directly, and then you do not
need a patch.
The syntax for patches are as follows:
```hcl
|
Patches
To change a resource in a previous layer patches can be used. A patch takes a target to update, and the new values the properties should have. It is only necessary to specify the properties that should actually change in the patch definition.
The target for a patch is always a data reference. If resource is defined in the same layer, you can just go edit it directly, and then you do not need a patch.
The syntax for patches are as follows:
| Code Block |
|---|
patch metafield my_patch {
target = data.metafield.my_field
Name = "The new name"
}
```
## The Digizuite Configuration Language |
The Digizuite Configuration Language (DCL)
...
The
...
DCL
...
consists
...
of
...
several
...
individual
...
parts
...
that
...
are
...
brought
...
together
...
to
...
allow
...
for
...
huge
...
flexibility.
...
The
...
language
...
is
...
heavily
...
inspired
...
by
...
HCL
...
from
...
Hashicorp:
...
https://www.terraform.io/docs/language/syntax/configuration.html .
...
The
...
major
...
building
...
blocks
...
will
...
be
...
shown
...
in
...
this
...
section,
...
and
...
then
...
we
...
will
...
finish
...
with
...
an
...
example
...
of
...
how
...
to
...
attach
...
these
...
things
...
together.
...
DCL
...
types
...
The
...
first
...
thing
...
you
...
need
...
to
...
know
...
about
...
the
...
language
...
are
...
the
...
available
...
primitive
...
types:
...
String
...
"foo"
...
,
...
is
...
a
...
string
...
with
...
the
...
value
...
foo.
...
Strings
...
are
...
easy
...
to
...
recognize
...
from
...
the
...
quotes
...
around
...
the
...
value.
...
Both
...
single
...
quote
...
and
...
multi
...
quote
...
strings
...
are
...
allowed,
...
and
...
support
...
the
...
exact
...
same
...
functionality.
...
Int
42, is an int with the value42. Ints can be recognized because they are numbers without quotes.Decimal
3.14, is a decimal with the value3.14. DCL makes no distinction betweenfloatanddoubletypes.Boolean
trueorfalse, are booleans with either the valuetrueor the valuefalse.
Next are the composite types:
Object, which is a collection of key-value pairs, where each value is one of the types described in this section. Keys are always strings, but without the quotes.
Array, which is an array of values of objects.
Example
A full example of using all these types can look like this:
| Code Block |
|---|
resource metafield title {
string = "My string"
int = 42
decimal = 3.14
bool = true
object = {
my_key = "my value"
}
array = [
{int = 41},
{int = 42}
]
}
```
|
Object
...
also
...
accepts
...
the
...
following
...
shorthand
...
syntax,
...
where
...
the
...
=
...
character
...
is
...
omitted:
...
| Code Block |
|---|
resource metafield title {
object {
my_key = "my value"
}
}
```
### Functions
DCL allows calling predefined functions to do things that are not directly
available in the syntax.
A function call looks like this:
```hcl
|
Functions
DCL allows calling predefined functions to do things that are not directly available in the syntax.
A function call looks like this:
| Code Block |
|---|
resource metafield title {
my_key = my_function("my first argument", "my second argument")
}
```
|
This
...
calls
...
a
...
function
...
called
...
my_
...
function and
...
passes
...
in
...
the
...
arguments
...
"my
...
first
...
argument"
...
and
...
"my
...
second
...
argument"
...
as
...
the
...
first
...
and
...
second
...
arguments
...
respectively.
...
Any
...
of
...
the
...
types
...
described
...
in
...
the
...
"DCL
...
Types"
...
section
...
can
...
be
...
passed
...
as
...
arguments
...
to
...
functions.
...
A
...
set
...
of
...
functions
...
are
...
available
...
out
...
of
...
the
...
box.
...
It
...
is
...
not
...
possible
...
to
...
define
...
custom
...
functions.
The available functions are as follows
file(<Relative path to file in the configuration file structure>)- function that can be used to refer to binary filestext_file(<Relative path to file in the configuration file structure>)- function that allows the user to have e.g. workflow definitions in separate files in a configuration layer
Both function input and outputs are strongly typed, and will be validated.
References
To make it easier to reuse parts between resources and link resources, DCL has a concept of references. References are a way of using a property of one resource in another resource.
In the simplest form it looks like this:
| Code Block |
|---|
resource meta_group asset_info {
// ...
}
resource metafield title {
name = "title"
group_id = resource.meta_group.asset_info.id
}
```
|
In
...
the
...
above
...
example
...
the
...
group_
...
id property
...
is
...
set
...
to
...
the
...
same
...
value
...
as
...
the
...
id property
...
of
...
the
...
"Asset
...
Info"
...
meta
...
group.
...
Accessing
...
nested
...
properties
...
is
...
also
...
possible
...
using
...
additional
...
.
...
s to
...
dig
...
into
...
the
...
object.
...
It
...
is
...
possible
...
to
...
use
...
properties
...
that
...
are
...
not
...
known
...
at
...
compile
...
time.
...
Because
...
of
...
this
...
the
...
config
...
management
...
engine
...
is
...
smart
...
enough
...
to
...
create
...
resources
...
in
...
the
...
correct
...
order.
...
In
...
the
...
above
...
case
...
the
...
meta_
...
group,
...
asset_
...
info,
...
would
...
be
...
created
...
before
...
the title metafield. In the same, but opposite direction, if there are no references, direct or indirect between two resources, they are freely be created in parallel.
References can also be passed as arguments to function, in which case the functions will only be called after the referenced properties are available.
String interpolation
All string types support string interpolation, which looks like this:
| Code Block |
|---|
resource meta_group asset_info {
// ...
}
resource metafield title {
name = "title ${resource.meta_group.asset_info.id}"
}
```
|
String
...
interpolation
...
allows
...
the
...
user
...
to
...
combine
...
multiple
...
values,
...
and
...
make
...
then
...
dependent
...
on
...
each
...
other.
...