Variables / Field Names - How to use!
Describe the Request
I am trying to link different fields with each other, via variables ($Current_User) or via other fields. I came across the Javascript notation {{ }} by chance via the videos, but have not seen any documentation on it.
I would need more information on how this works and what limits it has.
Example: I want to make a filter by taking the data from another field via a Many to Many link. Concrete example: Table Group has 2 fields: Members and Moderators, both an M:M relationship with Directus_Users. You can only be a moderator if you are also in the Members field. So how can I say, please show me ONLY the users that are also in Members?
I can't find any documentation on this - if there is any, please accept my apologies. (You could also explain the filters better/clearer directly)
Maintenance Strategy
The documentation only needs to be adapted if new variables are added or the field syntax changes. However, both are very elementary parts of Directus that should be explained in any case.
The templating syntax cannot be used as you described, they are currently only supported in specific presentational interfaces/displays. Where this is supported the {{ }} syntax is generally abstracted away from the user in a clickable interface (unless you are editing the RAW data)
For example this is used to set what information is rendered in the interface and display for an many-to-many relation:
https://github.com/user-attachments/assets/10b9d49c-a120-4a24-8f9a-e5c5abb174a3
The templating syntax cannot be used as you described, they are currently only supported in specific presentational interfaces/displays. Where this is supported the
{{ }}syntax is generally abstracted away from the user in a clickable interface (unless you are editing the RAW data)For example this is used to set what information is rendered in the interface and display for an many-to-many relation: firefox_1Aqqj96A1h.mp4
This issue should actually be a request for documentation.
The following topics are missing from the documentation:
- variables. What variables are there and how and when are they used?
- which fields are used and how.
If there is a restriction on how to use fields, then it should be in the documentation. However: Why is there a restriction? That would be a really cool advantage, in contrast to the databases - and it would save a lot of work. (But the issue is not about extensibility, but about documentation).
Best regards, Kal
Hmm thats not entirely true though, the templating syntax can be used as they describe. I don't quite understand the gaslighting π Theres even fancy semantics and highlighting for it
And it even works as expected, consistently in all filter rules.
The limitation is that it can't apply a value that is not already saved in the DB (so you need to add the values to filter by, save, and go back in and now it uses the filter correctly) and that (as far as I could tell) it does not work for nested values. So it's not a very useful feature, unfortunately.
Hmm thats not entirely true though, the templating syntax can be used as they describe. I don't quite understand the gaslighting π Theres even fancy semantics and highlighting for it
And it even works as expected, consistently in all filter rules.
The limitation is that it can't apply a value that is not already saved in the DB (so you need to add the values to filter by, save, and go back in and now it uses the filter correctly) and that (as far as I could tell) it does not work for nested values. So it's not a very useful feature, unfortunately.
Hereβs what I meant. As you mentioned, we can work on improving it. However, this feature should also be explained for new beginners, as even long-time users are unaware of it. π
Oh yeah, totally. I chanced upon this notation in the videos just like you have. Color me surprised. I'm with you, I commented on this:
the templating syntax cannot be used as you described, they are currently only supported in specific presentational interfaces/displays. Where this is supported the {{ }} syntax is generally abstracted away from the user in a clickable interface (unless you are editing the RAW data)
Which was odd to read as I arrived to this issue because I wanted to understand the limits of this largely undocumented syntax, and these were not them lol
And it even works as expected, consistently in all filter rules.