On a regular blueprint, switching [Allow Antlers] for a field to on has the intended effect of enabling Antlers parsing for this field when rendering the webpage, be it in a text, textarea or bard field (and possibly more).
For instance the process of rendering {{ 1 + 2 }} by default in a text field (named "Test field") is:
In the blueprint, enable [Allow Antlers] and set the default value to {{ 1 + 2 }}.
Create the page using that blueprint. As configured, "Test field" is prefilled with {{ 1 + 2 }}.
Display the page using a compatible template. Thanks to [Allow Antlers], it should display 3.
When configuring a forms blueprint, the same [Allow Antlers] switch exists and has the same behavior of retrieving {{ 1 + 2 }}.
However, as forms are to be filled in the frontend part of the site, it would make sense to have Antlers parse the value directly.
What it allows is e.g.: a form for attendees to register to a company event can be prefilled for logged in users.
Ideally, the parsing could apply to properties beside the default value.
On a regular blueprint, switching [Allow Antlers] for a field to
on
has the intended effect of enabling Antlers parsing for this field when rendering the webpage, be it in a text, textarea or bard field (and possibly more). For instance the process of rendering{{ 1 + 2 }}
by default in a text field (named "Test field") is:{{ 1 + 2 }}
.{{ 1 + 2 }}
.3
.When configuring a forms blueprint, the same [Allow Antlers] switch exists and has the same behavior of retrieving
{{ 1 + 2 }}
. However, as forms are to be filled in the frontend part of the site, it would make sense to have Antlers parse the value directly.What it allows is e.g.: a form for attendees to register to a company event can be prefilled for logged in users. Ideally, the parsing could apply to properties beside the default value.