Hello guys. First of all thanks for helping out newbies like me.
I have a collection for user badges where I have a title field and then an object field with an image of the badge and a description.
Then I have a members collection with a relation widget searching inside my badges collection.
The problem I have is that I don’t know how to make my relation widget get the entire object of badges as value.
I have tried setting the valueField of my relation widget in different ways such as: valueField: "badge.*." valueField: "badge*" valueField: ".*" valueField: "*"
And the only way it works is if I only get only one value, for example: valueField: "badge.description"
The wildcard * character is used for referencing list fields.
It is important to remember that the value field should be used as a unique identifier for the relation, so using fields that might change can break the relation.
However you can reference multiple fields via string templates, e.g. valueField: {{fields.badge.description}} - {{fields.badge.image}}
Hi, i react to this thread because i think it can be nice to add possibility to extract nested datas in objects… (using first object keys in first depth level)
For the context i had to fetch languages from an object like this. This object is customisable in a file collection (check yaml code below, corresponding to full netlifycms config.yml)
The object generated i want to fetch from a relation :
[en]
languageName = "English"
title = "Alouette house"
[fr]
languageName = "Français"
title = "Maison alouette"
And with a relation field i wan’t to extract a language code from another file collection by using wilcard in nested objects. I’ve seen wilcard only work with list widget but it can be nice to use it also in objects
admin/config.yml
backend:
backend:
name: git-gateway
proxy_url: 'http://localhost:8081/api/v1'
repo: loic-roux-404/hugo-netheme
squash_merges: true
use_graphql: true
local_backend: true
media_folder: exampleSite/assets/medias
public_folder: /medias
collections:
- extension: toml
files:
- fields:
- collection: international
file: languages
label: Disable Langs
name: disable
display_fields:
- en.title
search_fields:
- en.title # Here i want to use *.title to also target both fr.title and en.title
- en.languageCode
value_field: en.languageCode
widget: relation
file: exampleSite/config/_default/config.toml
label: Core hugo config
name: core
label: Settings
media_folder: ../../exampleSite/assets/medias/settings
name: settings
public_folder: /medias/settings
- extension: toml
label: International configuration
name: international
files:
- file: config/_default/languages.toml
name: 'languages'
label: Languages metadatas
extension: toml
fields:
- label: Language metas (French)
name: fr
widget: object
fields:
- name: languageName
required: true
widget: string
- label: Title
name: title
required: true
widget: string
- label: Language metas (English)
name: en
widget: object
fields:
- name: languageName
required: true
widget: string
- label: Title
name: title
required: true
widget: string
In autocomplete (relations suggest) i want to see names fields of object fr and en in file collection named languages.
Someone think it’s possible to do that for now or implement in a future version ?
PS : Not the subject, but is it possible to choose a dynamic object name key in list widget using types ?
widget: list
types:
- { widget: object, name: "defined by user or by a field ?", object_key: 'toto', fields: [...] }
Hi @loic, you’re correct this is not supported yet.
I recommend opening an feature request for it or structuring languages.toml as a list. In your case using the latter makes sense to me (you could also add a key field for the relation, e.g en, fr)
Not sure I understand this - you cannot have dynamic field names. What is your use case for that request?
I need to choose key for objects, and add unlimited translations like we can do with listtype feature.
It seems to be not possible but do you think it’s can be an useful feature ? Or is it a too much special case and a more adapted solution is a custom widget.
I’m going to submit a custom widget here when I will be able to make it work in my project…
Not sure, I think it might be easier to add an additional step to transform the CMS data to the structure expected by Hugo before passing it to Hugo (that might solve the other issue as well).