Problem/Motivation

Currently, only token source is able to use token replacement.
to cope with issues like #3496209, let's introduce a deeper token support, available for all sources.

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

just_like_good_vibes created an issue. See original summary.

just_like_good_vibes’s picture

Title: [2.0.8] Enlarge the support of tokens in sources » [2.0.9] Enlarge the support of tokens in sources

just_like_good_vibes’s picture

Assigned: just_like_good_vibes » christian.wiedemann
Status: Active » Needs review

Christian, would you like to review please?

The support of attributes will be made in #3496209: Add token replacement support to AttributesWidget using new centralized token and normalizer services from SourcePluginBase, but that issue would need a little refactor and simplification when the current issue would be merged.

pdureau’s picture

Title: [2.0.9] Enlarge the support of tokens in sources » [2.0.10] Enlarge the support of tokens in sources
christian.wiedemann’s picture

1. From my point of view the PropTypeConversionTrait should be a service (PropTypeConverter). And the base class should simple provide the service for easy access.
2. We should avoid renderInIsolation. What is the use case behind. Can we check for '#markup' or #plain_text'?

$renderer = \Drupal::service('renderer');
      $value = (string) $renderer->renderInIsolation($array);
      if ($strip_tags_from_render_arrays) {
        $value = strip_tags($value);
      }

christian.wiedemann’s picture

Status: Needs review » Needs work
christian.wiedemann’s picture

just_like_good_vibes’s picture

hello,
renderInIsolation was already there. it is used, when component props are receiving render arrays instead of the type expected by the props. this is the usual case when people are using twig to pass data from twig to props.

in those case, we always render the data to cast it to the right format. And we render with "renderInIsolation".

just_like_good_vibes’s picture

Assigned: just_like_good_vibes » christian.wiedemann
Status: Needs work » Needs review

and, unfortunately, no we can't make a service out of prop type normalization, because basically we need static methods to use those "helper functions" in the trait. let's take as an example public static function normalize(mixed $value, ?array $definition = NULL): mixed; from PropTypeInterface.

I started the conversion to a service and i was then faced by this wall.

so, given my two answers, should we have a consensus for merge :) ?

just_like_good_vibes’s picture

Ok, discussed during weekly :
- let's be careful about changing methods inside EnumTrait or PropTypeConversionTrait, and deprecate them, not remove them (thanks Florent for the suggestion)
- we will introduce classes instead of a traits. But,
-- option a) "no service" : our static methods from traits are static methods in a class, and those static methods are called directly from static method or normal methods
-- option b) "with service" : our static methods from traits are now normal methods in a class that is a well-identified new service, those methods (in the service instance) are called in normal methods thanks to service injection, and called from static methods with a static instanciation of the service first

between a) and b), performance was a question.

we did not decide yet if b) or a), probably it will be b)

just_like_good_vibes’s picture

Assigned: christian.wiedemann » just_like_good_vibes
Status: Needs review » Needs work
just_like_good_vibes’s picture

Assigned: just_like_good_vibes » christian.wiedemann
Status: Needs work » Needs review

ready ;)

just_like_good_vibes’s picture

Assigned: christian.wiedemann » Unassigned
Status: Needs review » Fixed

Now that this issue is closed, please review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, please credit people who helped resolve this issue.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.