I prototyping a site “page” content model, to which I can add a list of nested component (a group of fields).
One of the nested fields is a "reference schema field. However, I want to select a set of schemas, a mixed list of what I deem editorial content types (for example - article, story, blog, generic, etc).
Is there a method to set this reference field to validate against a list of types? A multi-select of the schemas allowed on the validation?
If this has been discussed before, please point me to the prior convo.
When rendering a list of references displays a list of names on the parent content form. I would rather show name along with an icon/graphic/image of my referenced schema.
An ask of me as I evaluate this tool was to shakedown a bit of its usability by just a marketing team. When a marketing editor is managing pages/layout schema, we want to give visual cues to how the page is structured. Thus, as I said, displaying the static graphic of a component schema (i.e. angular/react) in the Squidex UI.
Can you describe if such a thing would be possible? I imagine I would need to build the squidex code from scratch myself and tweak the logic underneath. I believe this ask lies outside the realm of a custom editor.
If the only way is to create a “preview” of the schema (page), then I would have to investigate this building out the preview link.
thanks for your feedback.
About the first question: It is not possible (yet?). The reason is that content items do not have a generic name attribute, something that can be used to display them. If you would reference multiple schemas there is no good way to show them in a good way in the table layout that we have at the moment.
About the second question: Is it related to this feature request: One-to-many relationship display on Content section ??
I really dig this feature as well i guess this could doable if this is getting implemented Schema content part / mix-ins / inheritance / snippets ?
@arnfasto: How would this help?
@Sebastian if you introduce inheritance in schemes, a content reference could be to the parent scheme and by that be able to reference all its children. This would also ensure that the have the same name that could be be showed in the table layout.
It would make sense in the setup that we are running, where most of the models/schemes has the same fields, and we would like to be reference all the different types contents without having to create a field per content type
I was thinking about inheritance and my idea so far is to introduce variations within a schema, so you could have a variation called “X” which has some fields defined that are only valid if this variation is chosen.
I just started using Squidex and stumbled upon this question, as I tried to realize the same concept as “nested component”.
A simple use case would be to define a “References”-Field and allow the content editors to place content components, based on multiple schemes (like Text, Image Gallery, Teaserlist, etc.) in whichever order they prefer.
Do you had a static concept in mind when it comes to the structure of different content parts/modules of a page or is there already another solution available, to allow a content editor to place/mix components of multiple schemes in the same “References”-Field?
My concept was to make a single schema that can have multiple representations, e.g. some fields are in common and some fields are defined by a content-type per item.
The problem with a generic references field is graphql where it would be very difficult to have a dynamic structure. Furthermore It is difficult to render multiple content types with different structures in one view.
I hope I can start working on that next week or the week after. A next big feature will be released soon
Thank you for pointing to the Roadmap. I’ll follow the related issue there.
This is a feature that we really would like to have as well
Currently i’m trying to define a smart way to make sure that all our models are based on the same base model.
My solution so far is to build an alternative model structure that is converted to schemas and then synchronized to the app/apps.
Another solution could be concatenate all reference fields to a single column in the references table.
Sorry, my problem was not related to the topic specificly, but more the need of having a shared base model across schema , it’s for streamlining the model when used in the application consuming the API’s
But the inheritance will also have a few restrictions as it is planned. I think your approach using the CLI or an external tool is the best. You could provide a PR for the CLI if you want.