Open magomimmo opened 4 years ago
Thanks @magomimmo, will this be covered by implementing https://github.com/netlify/netlify-cms/issues/1975 along with using the hidden
widget https://www.netlifycms.org/docs/widgets/#hidden?
Thanks @magomimmo, will this be covered by implementing #1975 along with using the
hidden
widget https://www.netlifycms.org/docs/widgets/#hidden?
I'm using @d4rekanguok 's ncw-id
and ncw-file-relation
widgets. IMHO these two widgets, with few improvements, have to be part of the standard set of NetlifyCMS widgets
With the recent addition of being able to use string templates with the relation widget, I think the only missing feature is to target a specific file (correct me if I'm wrong). Having two relation widgets might be confusing... Regardless, there is a separate issue for that https://github.com/netlify/netlify-cms/issues/800
As for the Id widget, the main use case for it is with the relation widget, which you can now set valueField: '{{slug}}'
as a unique identifier (or even {{filename}}
).
The main advantage of that approach is that you don't need an extra id field on the referenced collection.
I agree the CMS should supply a built in Id widget functionality and have an option to hide any widget. Hiding widgets is covered in https://github.com/netlify/netlify-cms/issues/1409#issuecomment-458781037.
Clarifying my suggestion - supporting a built in {{uuid}}
template variable in default values might make an Id widget redundant, e.g. doing - {label: "Id", name: "id", widget: "hidden", default: "{{uuid}}"}
should serve the same purpose.
Am I making sense here?
supporting a built in
{{uuid}}
template variable in default values might make an Id widget redundant, e.g. doing- {label: "Id", name: "id", widget: "hidden", default: "{{uuid}}"}
should serve the same purpose.
This would make sense yes.
Having two relation widgets might be confusing...
Agree, but we should be able to unify the corresponding configuration options
As for the Id widget, the main use case for it is with the relation widget, which you can now set
valueField: '{{slug}}'
as a unique identifier (or even{{filename}}
). The main advantage of that approach is that you don't need an extra id field on the referenced collection.
It makes sense
Clarifying my suggestion - supporting a built in
{{uuid}}
template variable in default values might make an Id widget redundant, e.g. doing- {label: "Id", name: "id", widget: "hidden", default: "{{uuid}}"}
should serve the same purpose.Am I making sense here?
Yes, it makes a lot of sense.
Just adding the following note on the this discussion.
As said in a previous post I use ncw-id
widget the identifier_field
for all the collections not having a natural primary key.
While using the relation
widget, this approach has the very bad effect of not allowing to use any field of the referenced collection in the slug or in the summary of the referencing collection.
Here is the minimal case:
# Referenced folder colleciton
- label: Referenced Folder collection
name: referenced
identifier_field: id
folder: content/referenced
create: true
slug: '{{year}}{{month}}{{day}}{{hour}}{{minute}}{{second}}-{{last}}-{{first}}'
summary: '{{last}}, {{first}}'
editor:
preview: false
fields:
- label: ID
name: id
widget: ncw-id
- label: Last Name
name: last
widget: string
- label: First Name
name: first
widget: string
- label: Referencing Folder Collection
name: referencing
identifier_field: id
folder: content/referencing
create: true
slug: '{{year}}{{month}}{{day}}{{hour}}{{minute}}{{second}}-{{referenced.last}}'
summary: '{{referenced.last}}, {{referenced.first}}-{{referenced}}'
editor:
preview: false
fields:
- label: ID
name: id
widget: ncw-id
- label: Referenced Entry
name: referenced
widget: relation
collection: referenced
searchFields: ['last', 'first']
displayFields: ['{{last}}, {{first}}']
valueField: id
As you can see in the attached screenshot, the summary of the referencing collection can only show the id
of the referenced one.
HIH
Thanks @magomimmo, that's actually a though one. The CMS only stores the valueField
in the referencing collection data file so you can't use the referenced collection fields in the referencing collection summary. For that to work the CMS would need to read and parse each referenced entry which it doesn't at the moment (it only does it when you open the editor).
Ugh. @erezrokah that's a pity. What about to save the summary of the referenced entry in the valueField
? Does it has any drawback?
As long as you are sure the summary
values won't change you can use:
valueField: '{{last}}, {{first}}'
and then in the summary just use summary: {{referenced}}
.
I actually think a better approach is to allow users to customise the cards https://github.com/netlify/netlify-cms/issues/2868#issuecomment-603119488. Then you could fetch any information you'd like.
Thanks @erezrokah
Hello @erezrokah :wave:
If I read well your last message, it seems possible to use a template in the value_field
of a relation widget, but I can't achieve to make it work.
My need is the same that this issue: I have a file collection with fields a
and b
(in a list) and I want to reference them from a relation widget, but it says "No options" if I use a template string.
value_field: 'a is {{mylist.*.a}} - and b {{mylist.*.b}}'
search_fields: ['mylist.*.a', 'mylist.*.b']
With the following, I have my items properly displayed:
value_field: 'mylist.*.a'
search_fields: ['mylist.*.a', 'mylist.*.b']
Did this feature disappear, or do I miss something? Thanks a lot :pray:
Hi @vnourdin, this seems like a bug/something we missed when implementing the wildcard access pattern via *
.
I suggest opening a new issue so we can look into it.
A better way to approach it is to create a uniquely identified field in mylist
and use that as a reference for simplification.
If you need the reference field to be dependent on a
and b
maybe create a custom widget for it?
I open a new issue then.
I did that with the preSave
event as a workaround, but it's probably a better approach indeed.
Is your feature request related to a problem? Please describe.
Whenever you model a collection you need an identifier field for its entries. Most of the time the collection does not have a natural identifier field (i.e. a primary key in RDBMS parlance). For this reason the community developed a range of custom widgets to fill this hole in the NetlifyCMS standard widget library, that does not offer such a basic widget.
Describe the solution you'd like
Create an
id
widget to generate an universal unique id code (i.e. UUID). This widget should also have a booleanhide
option to allow the associatedfield
to be hidden from the UI.Describe alternatives you've considered
Use a community based custom widget, but none of them currently allows to hide the field from the UI.
Additional context
Anyone intending to migrate a three-tire web application to JAMstack architecture will need to model collections and collection relationship. And you can't do this without having an
id
widget resembling synthetic primary key in RDBMS parlance.