Parameter types

When adding a parameter to the block or a query in your block definition or a query type, you can specify the parameter name, the type of the parameter and parameter options. This is achieved through an object called parameter builder which is provided to you in your block definition or a query type.

Parameter builder has methods for working with the parameters: adding, removing and fetching the parameters as well as setting parameter options.

When adding parameters to block definitions or queries, referencing the parameter type is done by specifying FQCN of the parameter type.

Common parameter options

In addition to the list of options specific to each parameter type, all types have seven common options: required, readonly, translatable, default_value, group, label and constraints.

required

type: bool, required: No, default value: false

Specifies if the parameter value is required or not.

readonly

type: bool, required: No, default value: false

Specifies if the parameter value will be readonly. If so, it can be set only in block definition or query type and cannot be changed via editing interface.

translatable

type: bool, required: No, default value: true

Specifies if the parameter value will be translatable.

default_value

type: mixed, required: No, default value: null

Specifies the default value of the parameter.

group

type: array of string values, required: No, default value: []

Specifies the parameter group. Groups are a generic concept when working with parameters. Netgen Layouts does not enforce or otherwise define how you use parameter groups. Internally, Netgen Layouts uses groups in block definitions to specify to which form (content or design) the parameter belongs and in query types to specify which parameters are advanced and hidden by default.

constraints

type: array of Symfony constraints or closures, required: No, default value: []

This parameter specifies the list of constraints that will be applied to a parameter in addition to constraints specified by the parameter type itself. These can be useful if some of your parameters have special needs from validation.

You can provide either a list of Symfony constraints, or closures that return a constraint. Closures can be useful when you need to validate the value of a parameter against other fields in the block or query. This is achieved by providing three parameters when your closure constraint is called, respectively:

  • the value of the parameter

  • an array of all parameters

  • the parameter definition of the parameter, which is an instance of Netgen\Layouts\Parameters\ParameterDefinition

An example closure constraint would be one that checks that one datetime parameter value is larger than the other datetime parameter value:

$builder->add(
    'visible_to',
    ParameterType\DateTimeType::class,
    [
        'constraints' => [
            static function (mixed $visibleTo, array $parameters): Constraint {
                $visibleFrom = $parameters['visible_from'];

                if (
                    !$visibleFrom instanceof \DateTimeInterface
                    || !$visibleTo instanceof \DateTimeInterface
                ) {
                    return new Constraints\Valid();
                }

                return new Constraints\GreaterThan(value: $visibleFrom);
            },
        ],
    ],
);

label

type: string, false or null, required: No, default value: null

Specifies the human readable name of the parameter. In Netgen Layouts this label is for example used in Symfony forms which edit blocks or queries.

Tip

Use false to disable parameter label in Symfony forms. If null is specified, the label will be generated by using Symfony translation component from the parameter name.

List of built in parameter types

The following lists all parameter types built into Netgen Layouts together with the options available in each parameter type.