From 1c94fb14db0fd4df52356636f54dcafd5fd64c92 Mon Sep 17 00:00:00 2001 From: blam Date: Thu, 25 Jul 2024 08:52:31 +0200 Subject: [PATCH] chore: fix Signed-off-by: blam --- .../README.md | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/beps/0009-scaffolder-templating-in-parameters/README.md b/beps/0009-scaffolder-templating-in-parameters/README.md index 450538ab8a..d5fc78497c 100644 --- a/beps/0009-scaffolder-templating-in-parameters/README.md +++ b/beps/0009-scaffolder-templating-in-parameters/README.md @@ -167,6 +167,20 @@ This is a pretty ugly workaround, but maybe the only option we have. Also at thi Perhaps we just accept this as a limitation, and document it as such. +Templating for `errorMessages` has been solved by using the `ajv-errors` library https://github.com/backstage/backstage/pull/25624, you can see more about [backrefs and pointers here](https://ajv.js.org/packages/ajv-errors.html). Any other template strings that will be passed through the underlying components and to be left untemplated should be encapsulated with options instead of passing through raw strings. The below example illustrates an `entityAndName` format, which under the hood, might do something like `${{ parameters.entity }} - ${{ parameters.name }}`, but this implementation never leaks out to the templating language. + +```yaml +parameters: + properties: + ... + description: + type: string + default: Test-description + ui:field: CustomDisplayField + ui:options: + format: entityAndName +``` + ## Release Plan