Template Settings Attribute: validate and visualize template settings directly

[BigRoy]

Story

It often comes up that it's hard to define anatomy templates because admins type invalid values or don't know what tokens are available when specifying templates like:

{root[work]}/{project[name]}/{hierarchy}/{folder[name]}/publish/{product[type]}/{product[name]}/{@version}

Problems

• Don't know the available template keys
• There's no validation whatsoever on the keys
• There's no 'example' of what a resulting string may look like.

Proposal

This is just an idea

What if we were to create a special "type" that displays a specialized frontend field that uses additional metadata.

Like:

my_template: Template = TemplateSettingsField(
    allow_custom_tokens=False,
    example_token_data={
        "folder": {
          "name": "folder_name",
          "path": "/path/to/folder_name"
        },
        ...
    }
)

The frontend could then use this to:

• Validate whether {} and optional keys are actually validly opened and closed, e.g. invalidating {{folder[name]} directly in the input field
• Allow to visualize the entered template value directly with the "example data" to show an 'example' use case
• Allow custom tokens would define whether tokens are allowed that are not in the example data (like if at settings definition time we just don't actually now all valid tokens)
• When e.g. richt clicking (or through some button) it could allow you to pick from the predefined set of tokens to add them.

If this would work - one may not need to resort to going to (outdated) documentation to find what template keys might be available for a certain settings field?

TODO

• [ ] Define what is needed to accurately define a Template field (e.g. describe the tokens, etc.)
• [ ] Potentially it may need to allow adding tokens from other settings fields, e.g. {@version} coming from the versioning template?
• [ ] Frontend UI would need to be design

Attachments

[philippe-ynput]

I wrote these RenderMan for Maya text field widgets who support multiple syntaxes: When a token is detected as you type:

• the tokens are colored if they valid tokens
• an eye toggle appears on the left side for you to preview the (non-editable) substituted string.

It was sub-classing QPlainTextEdit and leveraged QSyntaxHighlighter to support multiple syntaxes (file paths and light path expressions).

In other widgets I used completion as you type, which can be complementary.

[BigRoy]

Just wanted to cross-reference this issue that came up on Discord here which sounds like something we could even catch NOW in settings by adding a simple validation to these anatomy attributes (e.g. checking whether {} are closed accordingly)

Also, a simple "Anatomy path builder" HTML page got shared on discord here so i wanted to attach it to this issue because it seems so closely related.

AYON_VPC_v1.01.zip

Amazingly simple of course, but it gets the idea across. Something we could do much better potentially by allowing e.g. a user to 'pick an example entity context' and it'd auto-populate all data.