This section deals with the mechanics of how inheritance works in the context of a prototype. Note: the same general process occurs if attributes are edited at a higher level in the cascade, e.g. at document level, and with or without the involvement of prototypes.
Are prototypes required in a document?
No. There is not a requirement for you to use prototypes at all, or to use them with all notes if present. They are simply an easy and powerful affordance offered by Tinderbox. It is important to understand how they work so you know their effect if you want to use them. Once comfortable with how prototypes work, their usefulness will become apparent.
A note can be turned into a prototype at any point. This is part of Tinderbox's ability to allow for emergent structure (delayed formalisation). In a traditional application, such usage would likely have to be planned and implemented before other content was added, or re-added.
Prototypes can even inherit from other prototypes allowing for quite nuanced behaviours.
Note: this section uses Displayed Attributes for illustrative purposes. Remember, Displayed Attributes are a means of displaying user-selected attributes. Displayed Attributes have no special importance beyond their display in the text pane.
Now to explore the inheritance process:
- Prototypes can change the cascade—I
- Prototypes can change the cascade—II
- Prototype values override document defaults
- Note local values override inheritance
- Can inheritance be restored after setting a local value?
- Re-enabling inheritance—I
- Re-enabling inheritance—II
- Inherited local values without a prototype
- Re-setting all defaults