OrchardCore
OrchardCore copied to clipboard
OrchardCMS
The best way to relate hierarchical structure
For a structure such as
Sector > Program > Project > Albums, what is the best way to design the relation between them?
I think using the container/list will make the UI too complex because of the nested structure. Right now the way I think about it is to create a text field (with predefined input) for each children content to relate to their parents. The problem of course this list needs to be maintained manually.
Therefore
- Program will have ProgramSector text field
- Project will have ProjectProgram text field
- Album will have AlbumProject text field
I wonder if there's a better way.
Ok it looks like the better way is simply to do
- Sector -> ListPart of Program
- Program -> ListPart of Project
- Project -> ListPart of Album
This type of content editing experience can really use breadcrumbs (https://github.com/OrchardCMS/OrchardCore/issues/3687)
ContentPickerField
Oh I didn't know this. Excellent.
Tags & Taxonomies
Sector > Program > Project > Albums. It's hard to accommodate this using taxonomies. The relations are direct.
Sector > Program > Project > Albums. It's hard to accommodate this using taxonomies. The relations are direct.
Ya if it represents an entity aka content type, so ContentPickerField is the a good option
Wouldn't using List a more natural? Is there any downside of using List that I am not aware of?
I don't think there are downsides. The only thing content picker field allows you to do is reuse a piece of content in many parents. For example, I am using the same form in many pages so I reference the form with a content picker.
OK so we can use:
- ListPart
- ContentPickerField
- Taxonomy
for relating contents. Do I miss anything else?
It would be nice to know when choose what, for instance Use Taxonomy for create tagging, ListPart for ... etc
@dodyg There is also a LocalizationSetContentPicker for multilingual content.
Use case:
Event that has LocalizationPart. Team that does not have a LocalizationPart but relates to the event. Team would have a LocalizationSetContentPickerField that points to the event to be able to get the localized version based on the current culture when rendering.
I have been greatly interested in this ability for a while now, its important to hammer this out. One of the other issues is if I am on a child how do I discover my parent?
@JoshTango
The highlighted part is the content id of the parent, then you can use
{% assign my_content = Content.ContentItemId[Model.ContentItem.Content.ContainedPart.ListContentItemId] %}
to obtain the parent info.
or better
{% assign my_content = Model.ContentItem | container %}
For more info, check here (https://orchardcore.readthedocs.io/en/dev/OrchardCore.Modules/OrchardCore.Liquid/#container)
@dodyg this is specific to Lists. For the content picker(s) the code is a bit different see: https://orchardcore.readthedocs.io/en/dev/OrchardCore.Modules/OrchardCore.ContentFields/#contentpickerfield
I am using ListPart for now but I am not sure whether this will be the final decision. I am still exploring.
I am looking to do something similar as well. @sebastienros suggested I try with a taxonomy to define the hierarchy and just select the taxonomy term with a field in my types. This keeps all types flat but allows you to define a hierarchical structure of content without having lots of nesting.
@dodyg in your hierarchical Content Items with ListPart are you also have experiencing this #4749 (see second comment) ?
@jptissot that looks like an interesting approach actually. I wonder how it will look like in being able to query them though.
If my hierarchy is Sector > Program > Projects, I will need to show
"Sector : Social Empowerment"
- Program A
- Program B
- Program C
I believe there is a way to get all ContentItems that are tagged with a Taxonomy term. We would need to investigate and try.
My use case was a Knowledge Base. So I had a Knowledge Base Article, which would be tagged with a Category.
So far, for this type of structure Sector > Program > Project > Albums., ListPart is the most obvious way to structure them.
- Sector has ListPart of Program
- Program has ListPart of Project
- Project has ListPart of Albums
The problem with this arrangement though, when you are in the child content editor UI, you don't know what the parent is. It's not displayed.
So if I am editing a 'Program', I have no idea what Sector it belongs to.
The problem of using Taxonomy for Sector > Program > Project > Albums. structure can be seen here.
- The first level in the hierarchy is Sector
- The second level is Program
This display is a taxonomy field in the "Project" content type. As you can see from the UI, the field shows the whole hierarchy. User can pick the taxonomy term that is meant for "Sector" because there is no way to limit that user can only select "Program" taxonomy term.
there is no way to limit that user can only select "Program" taxonomy term.
Isn't there? At least in Orchard 1 we have an option to define which level of the taxonomy can be selected. Don't we have it here too? If not we could add it. I am pretty sure we can already limit to "leaves" (last level)
At least in Orchard 1 we have an option to define which level of the taxonomy can be selected.
This doesn't exist at the moment
I am pretty sure we can already limit to "leaves" (last level)
Yes this exists
I assume it would be useful for your use case if the Taxonomy picker field could also be limited to display a subset of terms
Yes. I can think of two ways:
- Filter by one or more levels, e.g. show level 2, 3 and 4 here.
- Filter by one or more of the properties of the Taxonomy Term properties, e.g. show me all the taxonomy terms that has
{Type : "Project"}.
The larger issue here is finding the best way to relate one content to another.
Parent > Child (List Part)
Right now to associate a child content to a parent via ListPart is to create the child content through the List Items interface of the parent Content Item. This is very restrictive. There is no way current to create a child content and associate it to the parent item.
I'm going to throw in a different idea. In the entity framework system if I have 2 entities with a relationship to each other we actually have 3 objects. 2 for the entities and 1 for the relationship. I had thought about making a content definition type just for the relationship. This is actually best for many to many relationships.
I don't believe any of this relationship stuff was thought through properly when Orchard Core was designed. The issue here is that I bet orchard core attracts a lot of developers where as drupal and wordpress attract a lot of web designers. We are trying to be developers with orchard core which is good.