Once we've the typed data API in place for entities we have everything in place to navigate through entities similar to using tokens, e.g. you can do $comment->node->entity->title->value
; I think we should leverage this and build the token system on top of it.
My initial thoughts:
- The token API should be built upon Typed Data, i.e. not depend on entity interface but on typed data interface
- Use the typed data API as source for support data types and available properties. For adding a new token you can add a new computed property.
- Care about ways of formatting data only based upon data types. It should be possible to register a new token format for e.g. integers, dates, nodes, or date fields.
- Use the Typed Data API to get the value then format the value.
A possible problem with that approach I see in providing tokens. While you can typed-data enable any kind of data you cannot add new computed properties to any kind of data. You can only do so if the implementing class allows you to, e.g. as entities do. So it wouldn't be a problem for entities but should we also support adding new tokens to e.g. a date field's item? Or to a module's custom non-entity data structure?
I'm not sure this would be an acceptable restriction?
Comments
Comment #1
fagorelated: #2002254: Add support for typed data selection
Comment #2
Xano#2002254: Add support for typed data selection adds a solution to select data from any typed data based on selectors. This can be leveraged by token API by simply using the tokens as data selectors. This will remove the need for 90% of the existing hook_tokens() implementations as drilling down the data will be done by core, similarly to how Rules does it now. A few other things that will need to be added before we can completely replace hook_token_info() and hook_tokens():
- Add global context plugins: tokens for the site, the current date and time, and the currently logged-in user are global. We need plugins to expose and fetch these typed data types, and in order to prevent collisions, we will put them in the "global" token namespace (
site:name
becomesglobal:site:name
, for instance).- In order for token browsers to work, we may need to find a way to expose non-global typed data as well.
- We need to find a solution for accessing extra information of non-complex data, such as timestamps, which can be fetched in different human-readable formats, or from which things like the year, day, and month can be extracted. A working solution would be to convert these data to complex types and use computed properties, but this has some drawbacks @fago and @berdir can probably explain better than I can.
Comment #3
Dave ReidI'm just not really in favor of this change until we can get a working token browser in core because ensuring that this data can be exposed in an a friendly way in the UI is really, really important to me. TypedData concerns me since it's new and untested (it hasn't been used in contrib for a core cycle yet). I'm tempted to just mark this as postponed.
Some specifics:
We need to consider this will break existing tokens and we need to provide an upgrade path for those tokens. I'm guessing that we'd have more tokens that have TypedData replacements but don't use the same 'name' as the D7 token equivalent.
Comment #4
XanoI agree on the importance, but not having a token browser (or a typed data browser) in core is not a regression.
This will definitely break existing tokens. This was done for a good reason, but we can probably just as easily not use the
global
namespace. An upgrade path seems impossible to me, simply because there is no knowing where tokens may have been used.Comment #5
amateescu CreditAttribution: amateescu commentedA simple upgrade path could be just a mapping of old/new tokens.
Comment #6
XanoAlso see #2008386: Global contexts.
Comment #6.0
XanoUpdated issue summary.
Comment #7
XanoFor a more realistic solution for Drupal 8, see #2164635: Automatically expose typed data to token API.
Comment #8
catchThis doesn't need to be against 9.x, it could likely be done with a bc layer, might be won't fix though?
Comment #18
darvanenClosed #2924819: Make Tokens a special case of Typed Data as a duplicate of this issue.