Avoid config form field type "machine_name"

ishani patel → made their first commit to this issue’s fork.

Hello @jurgenhaas,
I've created MR.
Please check and review.

Thank you!

@ishani patel this is looking good for the first item in the proposed solution. We also need to look into the other two.

Hello @jurgenhaas,
Sure,Can I go with the below changes:

For point 2. (#token_type)
For point 3. (#element_validate)

Update the field definition like this:
2. Add Token Support to the Field Configuration:

$form['name'] = [
  '#type' => 'textfield',
  '#maxlength' => 1024,
  '#title' => $this->t('Machine name'),
  '#description' => $this->t('Specify the machine name / key of the render element. Tokens are allowed.'),
  '#default_value' => $this->configuration['name'],
  '#element_validate' => [[$this, 'validateName']],
  '#token_types' => ['node', 'user', 'custom'], // Based on your context
];

3. Add Custom Validation

public function validateName(array &$element, FormStateInterface $form_state, array &$complete_form) {
  $value = $element['#value'];

  // Allow token patterns like [entity:property]
  if (preg_match('/^\[.*:.*\]$/', $value)) {
    return;
  }

  // Otherwise, validate as a machine name.
  if (!preg_match('/^[a-z0-9_]+$/', $value)) {
    $form_state->setError($element, $this->t('The name must be a machine-readable name (lowercase letters, numbers, and underscores only) or a valid token like [node:title].'));
  }
}

Let me know your thoughts.
Thank you!

As for the token support, there are 2 ECA-specific attributes that we're using for the form fields:

'#eca_token_replacement' => TRUE,
'#eca_token_reference' => TRUE,

The first one indicates that tokens are allowed in the input field and the plugin will replace tokens with their value. The second one tells the user that a token name should be provided without the brackets.

As for the machine name replacement, we always need the eca_token_reference to be turned on. In some cases, this can also support eca_token_replacement, we need to check the code in detail if the access and execute methods do call token replacement on that config value.

We don't need to add anything to the description, though, as ECA takes care of it according to those two properties I described.

And then, the #token_types property is not required here, either.

When it comes to validation, it may be a bit more complex than this. Following the token properties above, we may or may not have brackets around the "machine name", and the content itself can contain strings and a few extra characters like colons, but e.g. no spaces (I guess). But it can certainly be more than one colon, e.g. for something like node:body:value.

In any case, the validator should go into a service or a trait, so that we don't end up with redundant code everywhere.