Configuring schemas to restrict field values based on another document type
8 replies
Last updated: Sep 11, 2022
M
Question about configuring the schemas in the Studio:
I have a document type called
What I would like to do is have the value of
Does that make sense, is it possible to do?
I have a document type called
positionto represent a political position of a public figure. The position document has the fields
issue(the name of the issue, i.e. abortion, gun control, etc), and
stance, i.e. pro-choice, pro-life, pro-gun control, pro-2nd amendment, etc.
What I would like to do is have the value of
issueand the value of
stanceto be restricted based on another document type called
positionDefinition. So,
positionDefinitionwould have the fields
issueName(string) and
stances(an array of strings). To create a
positionthe editor has to first create a
positionDefinition. Then they can create a
positiondocument where the
issuefield is one from a
positionDefinitionand the
stanceis one of the stances that were defined for that issue in
positionDefinition.
Does that make sense, is it possible to do?
Sep 8, 2022, 8:24 PM
S
Can they reuse existing
In theory this would be possible with some tweaking of the
What is your overall goal with this though? Which part will you reuse how in your front-end ?
š¤
positionsDefinition?But a question I ask myself is why you need them to be separate docs. But let's think about this later...
In theory this would be possible with some tweaking of the
desk structureand the
create newfunctionality (in the top bar) and using
initialValueTemplateswithin the panes, which set the references in
positionto the created
positionsDefinition.Basically you would create
documentListswhich follow that logic but hide all other functionality to create the "nested"
childrenfrom being accessible in the desk structure.
What is your overall goal with this though? Which part will you reuse how in your front-end ?
š¤
Sep 8, 2022, 9:43 PM
S
This might not make too much sense unless you know what I mean exactly and it's pretty complex š«£ so let's not worry about the details and concentrate on the beginning. Give me more information and then we brainstorm š
Sep 8, 2022, 10:17 PM
M
Thanks
To answer your question on why I'd need them to be separate documents, it's because I want the fields in the
user J
! I think your suggestion makes sense. I'll look into some desk structure code samples to understand how to implement this.To answer your question on why I'd need them to be separate documents, it's because I want the fields in the
positiondocument to not be a freeform text. At the same time, I don't want to embed the accepted values in the code itself. I'd like something in between, where editors can specify accepted values somewhere. Then use those accepted values.
Sep 9, 2022, 6:01 PM
S
Ah okay that makes sense ... Kind of like tags right? I will prepare something for you in the next days ( a small instruction, but I need to test first)
Sep 9, 2022, 6:05 PM
S
Could you in the meantime sketch up a simple Mindmap of how this should functionally look? š
Sep 9, 2022, 6:06 PM
M
Thanks
Can we wait on that until I gain more clarity on the requirements myself? I'd like to reach back to you at a later time, if that's okay?
user J
I appreciate it! Yeah it's a lot like tags.Can we wait on that until I gain more clarity on the requirements myself? I'd like to reach back to you at a later time, if that's okay?
Sep 9, 2022, 6:10 PM
S
Sure, you can tag me then! Happy Weekend š
Sep 9, 2022, 6:12 PM
S
I marked it as solved so nodody else from our team re-reads or gets in here unnecessarily. When you get more insight, just repost here, it will apprear in my inbox then (or tag me in another post)
Sep 11, 2022, 9:41 PM
Sanityā build remarkable experiences at scale
Sanity is a modern headless CMS that treats content as data to power your digital business. Free to get started, and pay-as-you-go on all plans.