Tree structure based on parent-child relationship among content types I want to store technical_specifications of various products. As different product categories obviously have very different types of specifications, what I had in mind was a tree structure of content types, only to find out that Drupal's content types don't support parent - child relationship out of the box (ie. a content type cannot inherit fields from another one)
I'm thinking something along the lines of
- PRODUCT   
- price  
- weight  
- url
    - COMPUTER  
    - (inherits everything from product, plus)  
    - processor  
    - RAM  
    - (...)
        - LAPTOP  
        - (inherits everything from computer, plus)  
        - battery  
        - touchscreen?     
        - screen size  
        - (...)
    - TV  
    - (inherits from product, then)  
    - screen size  
    - contrast ratio     
    - resolution  
    - refresh rate  
    - (...)
    - BOOK  
    - (inherits from product, plus)  
    - author  
    - title  
    - genre  
    - publication date

...you get the idea.
What is the 'Drupalish' way to achieve this?
I could, of course, create separate content types for every product category (since you only create every content type once, and you can re-use existing fields, it's not a whole lot of extra work), but that wouldn't reflect the structure and hierarchy of the product categories
Or I could dump every field in one big content type, make them optional and only fill out what's relevant to that specific product (or category, rather)
Neither of these sound optimal. Any better ideas?
thanks!
(I'm running Drupal 8, btw, if that is of any importance)
I think there is a lot more to unpack here than it seems at first sight.
Usually when we talk about inheriting things it's actual data referencing other data (sets of data), it's not structures inheriting structures automatically.
Just because a laptop shares properties with a computer doesn't mean that a laptop node will reference a particular computer node, so it's not data referencing data.
Although you can choose to implement things in different ways, and there are usually reasons why you should go with a chosen option, I think in this case it makes the most sense to create a separate structure for each data set that is &quot;standalone&quot;.
Without any other info about your site, assuming from your current description and my past experience building sites I would structure it this way:
Content types and their fields:
COMPUTER    
- processor  
- RAM  
- (...)
LAPTOP  
- processor
- RAM
- battery  
- touchscreen?     
- screen size  
- (...)
TV  
- screen size  
- contrast ratio     
- resolution  
- refresh rate  
- (...)
BOOK    
- author  
- title  
- genre  
- publication date
PRODUCT   
- price  
- weight  
- URL
- !! Entity Reference Field !!

Notice the computer fields in laptop that are the same as in computers are repeated under laptop. You can reuse existing fields, I recommend you do especially if you plan to do any comparisons between different nodes that may be different category product but share the same properties/fields. But there are no field references between computer and laptop, they are independent from each other, even if they share some properties.
Different product categories have different product properties, and it makes sense to keep them separate.
When selling products they all share the same properties with regards to selling, and when selling a product you're selling one set of data, not the structure. You're selling one specific computer, not category of computers in general.
That's why it makes sense to have the saleable entity as a separate structure, and you pull specific data from a particular node that exists of some product category.
Through the Entity Reference field you can show entire node information on the Product node that references it.
Structurally you could have a specific computer node, lets say node ID 5 with all the computer fields describing it (RAM, CPU).
Then you would have another node, of the Product type, node ID 6 for example, that would list the price and reference node 5. Node 6 would show everything on its page. Node 5 can even be hidden from public, better SEO whatnot...
With the module Inline Entity Form (which was created with excommerce in mind) or some similar solution you can solve the editors problems of having to first create the &quot;computer&quot; node before creating the &quot;sell computer&quot; node. With this module you will be able to create both at the same time, in one go.
This way you're fast when entering content and maintaining your site, while your structure is still flexible enough that it's easy to create different lists you might need with Views (using Paragraphs and keeping everything in the same type can hinder you there) and you can change things in one place because it's all kept in sane compartments.
For example if in the future you need to add some sales tax field you can do it on the Product type and it will appear for all saleable products, you won't have to edit many CTs (in case you have them all separate without ER to product) and you won't have to do complex Views to gather different Paragraph interconnections just because you have everything in one Conent Type.
If you've read it, I think it will help no matter what you decide because it at least gives you some other considerations to think about. If I've been clear enough that is :þ