#backport

Should we probably introduce a flag in \Drupal\eca\Plugin\DataType\DataTransferObject to optionally turn off rekeying which should be called right before calling $list->set($index, $item); in the action plugin?

Either this, or initialize a DTO with a rekey option, or do both. Maybe then let the user decide whether rekey should happen, by adding a corresponding option to the "List: add item" action? There is another place where someone can add an item to a list, for example with "Token: set value" using token name [mylist:+]. But I think that one is probably never used by anyone. Still there may be other places where an item is being added to a list (other actions, such as merging).

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.

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!

@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,
I've created MR.
Please check and review.

Thank you!

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