When we should use a child entity?

Hi there,
I was reading throw the documentation, and I still do not get when I should use or implement an entity child.
If I can use the analogy of a Grasshopper or Dynamo node I would say:
The Controller class is the interface of an entity (node) meaning: it is what defines its shape, how is visualized, how behaves, and the outputs.
The Parametrization class defines the parameters of the entity (node), so the inputs of our node.
If the analogy makes sense so far, when and why I should implement an entity child ( a child node )?

If the Controller is the framework of the app, and the Parametrization the entry points, having an entity child means we have a sub-application?

When I read your documentation where you write:
As a metaphor (thinking in terms of the Python language): the entity type would be a ‘class’ this makes total sense to me, so I see a child as a sub-class inheriting from the main class, but it is not like that.
Should I think an entity child is like another class with different behaviors without any relation to the entity parent?

Thanks in advance to help me clarify this point.
Cheers.

Hi,

You can look at an entity as an object with a dedicated editor. It is indeed more like a different class with its own properties and methods. The names ‘parent’ and ‘child’ are more similar to the way it is used in ‘parent folder’, rather than a parent-class. In many applications, we see the following structure

  • A project with an editor to set some properties relevant for all designs in the project
    • a few different designs with similar editors but different properties
    • a few different input files with a separate editor
  • A second project with some properties for this different project
    • a few different designs
    • …

In that case, the project would be of type Project and will have two child entity types Design and InputFile.

From an entity of type Design I can access the data of the associated parent entity of type Project (e.g. the project name) trough the API. But otherwise the entity of type Design can have totally different properties and methods. For each entity of type Design there is only one parent entity Project, similar to how a file is only has one parent folder.

Like a folder can contain multiple files, an entity of type Projectcan contain multiple designs and multiple input files. If the input file contains location, I could visualise all the locations for all the input files of this specific project in the project editor, and not get distracted with input files that are associated to other projects for instance.

I hope that helps.

Paulien

The tree-type app tutorial implements a parent-child hierarchy. Maybe it helps you understanding the concept.

Should I look at the use of the child as a Separation of duties between dedicated editors? Because this is the only reason I see looking at the tutorial.

So, let’s use the tutorial as an example to expand it with another child, we will have:

  • GeoPoint (child) captures a point on a map
  • Calculation (child) use the result of the GeoPoint to make some calculations using a table.
  • Overview (parent) visualize the data from GeoPoint and the result from Calculation

Is this correct?

Thanks, @Puijterwaal for the explanation.