OrchardCore
OrchardCore copied to clipboard
OrchardCMS
Feature Request: Namespaces/categories for content type definitions
I think it would be a good idea to have the content definitions grouped into namespaces or some container strategy. For example all the blog content types can go in the Blog namespace and all the regular website content types can go in a website namespace and all the product content definitions can go in a Product namespace
This problem arose when I liked the agency recipe for the website but I need other definitions for blogging and I need other definitions for products. Switch or deciding between recipes doesn't make sense because I need all the content definitions from multiple recipes.
Currently it looks really messy for all these different categories of content definitions. It would be nice if they were grouped by synergy.
We talked about adding a Category metadata to types, like we have Stereotypes, which would let us group Widgets for instance. Would that solve your issue? We would use this category in the admin screens to group types.
I guess my next question would be an xml hierarchy question in the recipes and content definition file. Would you have parent xml nodes for these categories? Or would you just keep one linear list of content types? This is more of an implementation thing.
Categories would be seen as a flat list of content types. Just groups of one level. A property for each content type.
If someone finds the issue that talks about it already, please reference this one
I was also thinking about micro frontends. This would address the data schema aspect of a micro frontend I suspect? Now that 1.0 is out will this issue be on the agenda? @sebastienros
I think prefixing Content Types technical names might be a good approach for this as of now. Then, adjust the admin UI in consequence. Else, having the same technical name for different Content Types might get messy over time. Also, having a dependency on a parent category to decide which Content Type is what might require some breaking changes. I'm not against it, but it might be a bigger challenge going that path so I think the prefix is simpler to implement.
Also, adding a category on Content Types might lead to needing complex hierarchy of categorization like "taxonomies" over time. So, the idea here is to be able to have multiple Content Types which have a similar name and function but with slight differences between them. So, regrouping them in different containers would allow using the same technical name in each containers for micro frontends type of use cases.
Ok but would it use periods or underscore? Forum.Post Forum.Contact CRM.Contact for example?
And the next issue would be more than one prefix for example:
companyname.microfrontendname.contentypename
You can fake namespaces by removing the dot which is not allowed. Will be the same in the end. As for the UI, the only thing we can do is add a category as I suggested, which could then be used by some admin screens.
Category: string This can be done anytime and won't break anything.
While category is fine, I still think something more official along the lines of namespaces is preferred. Maybe underscore is used and the admin UI shows this in a tree. The current problem is I think the admin shows display name and not technical name which is another issue.
Well maybe a field called Namespace is added. Internally the List holding the content type names could stay the same and you could make a different structure for holding content types which have a namespace != null. I suppose you could put a single wrapper class around both lists.
Then there would have to be a bunch of if statements(if namespace != null) sprinkled all over the code including queries.
So namespace is exactly like category? However handling hierarchies is harder in terms of UI. Nothing prevents you from having underscores or even dots in a category. I would keep the word category as namespace is very much only used in C#.
well whatever strategy is used it needs to allow duplicate content type names which would cause collisions.
Ok lets rename namespace to subdomain because thats what this is really about: Domain Driven Design.
Actually lets just stick with PACKAGE as the field name. There is no need to show the entire heirarcy in the Admin UI. Just one level for the package name and then the content types below it in a liner list. You dont have to show a treeview for each period.
I guess I can settle for category now. @sebastienros
In the future I would like a discussion on domain types.
Duplicate by https://github.com/OrchardCMS/OrchardCore/issues/11556. See it for some more notes.
