Tinderbox Forum

Applying Prototype with Children to Container with Children

I seem to have run into a situation where PrototypeBequeathsChildren has no effect when a prototype is applied to a container. This is a bit confusing, but I’ll try to explain my situation as clearly as I can:

  • I have a container C with a child note CN1.
  • I have a prototype P that is based on a different container with a child note CN2.
  • When I set the container C to prototype P, some of the attributes change (e.g., colors). However, the prototype’s child note CN2 is not added to the container.
  • As a sanity check, If I set a different note with no children to prototype P, it is transformed into a container with child note CN2.

Is this the expected behavior? Based on my understanding of PrototypeBequeathsChildren, the immediate children of the prototype should be added to the note. Is this not the case when the note is a container?

It is my understanding – and experience going back many versions of Tinderbox – that children of a prototype are not added when that prototype is assigned to another note that already has children.

I’m not sure child bequeathal is commonly used, so it would be helpful if @eastgate could chime in here as to the expected results. I can see that bequeathal should not happen when a note already has children because the bequeathal might be disruptive or confusing.

1 Like

@PaulWaltersis correct: PrototypeBequeathsChildren is ignored if the instance already has children.

The original notion of $PrototypeBequeathsChildren was to accommodate structured information. For example, you might have a BOOK prototype which would always have a REFERENCE, a READING NOTE, and a READING GROUP DISCUSSION note.

Nowadays, I think you’d typically do this with a composite rather than with $PrototypeBequeathsChildren, but the older way of working remains for those who prefer it.

1 Like

I’ve updated my aTbRef note on prototypes to reflect the above, that notes with existing children will not inherit bequeathed children even if the prototype applied is configured to do so.

1 Like

Composites do not play nicely with views other than Maps, so it’s good that prototypes can bequeath children, in the manner described above.

2 Likes

Yep, this is what I am in the process of building. I’m setting up something similar to the BOOK prototype you described. Since I’m still in the process of working out its structure, I’ve been adding and removing children from the prototype, and that’s when I ran into the issue with children not being added/removed when the prototype was changed.

I didn’t realize that this could also be handled by composites. I’ll look into that today. In any case, good to know that this is the intended behavior! Thanks to you all for the help! :slight_smile:

I’d echo @PaulWalters’ point that composites are a map-only feature. No problem, unless you’re going scale. 50 notes on a map, fine: 5,000 items, less so. I must add that this is absolutely not * to disparage using map view, but depending on the size of your data set you do need to be pragmatic about where you can view your data. Part of getting comfortable in Tinderbox is getting to know what view works for what task at what scale.

* it’s too easy to miss-parse that observation as a critique of the app’s construction. Far from it, it is about scale. What works with a few things may involve much more efort for more items in a way that may not be obvious to us non-technical users.

1 Like