Tinderbox Forum

Applying Rules Through Prototypes

I want know what expectations I should have in the following situations:

  1. Assigning a rule to a prototype

Having assigned a rule to a prototype I expected that the same rule would appear in the “Rule” panel of any note to which the Prototype was assigned but that appears to not be the case. The “Rule” panel of the note remains blank (no additional rules were added) while the Prototype displays the rule. Is that correct behavior?

  1. Displaying Attributes in the Text Panel
    If I set up the prototype to display attributes at the top of the text panel I had an expectation that the same display would occur in any note to which the prototype was attached. However, it appears that is not the case. Attributes displaying in the prototype text panel do not automatically display in the note using the prototype. Is that the correct behavior and if so is there any way to control the display of attributes in the note from the prototype? I’m attempting to display a certain set of attributes in the note and then change their value so that certain actions occur based on the values that I insert for each attribute. I realize that I could use the attribute browser to change the values but I have a limited set that I want to use and it will be faster to make changes if they are displayed as a set.

Thanks.

Not sure about the 2nd but for your 1st question I tested in a separate document.

  1. Create prototype “proto” with $Color=“red” as the rule
  2. Create Note called “Note 1”
  3. Assign “Note 1” prototype “photo”

As you can see in the illustration below the Note has the same rule as it’s prototype. I’m using TB9.0 but pretty sure same applies for previous version of TB.

If a note has no $Rule and a prototype is assigned, it will inherit that prototype’s rule unless the note already has a rule. The inheritance is not additive. Your comment,

no additional rules were added

suggests you were expecting the prototype’s rule code to be added to the already in the note. Instead, Tinderbox’s inheritance model means the local rule in the note is retained as it ‘blocks’ inheritance from the prototype.

If that doesn’t answer the case, it might help if you could upload a small TBX showing the problem. This stage of learning the app can be confusing as experiments trying things out can result in doing things like unexpectedly breaking inheritance. Though it can seem counter-intuitive and a chore, a good idea is to explore issue like inheritance is in a new doc you’ll throw away once the procedure is understood. This saves making mess in your main ‘work’ doc(s).

What is shown in a note’s Displayed Attributes table is stored in $DisplayedAttributes so the same inheritance as above applies.

An easy way to reset Displayed Attributes is to click the table-like button top right of the text pane, which opens the Displayed Attributes pop-over. Click the ‘reset’ button and the value of $DisplayedAttributes will now inherit from the prototype and the Displayed Attributes table will populate as desired.

Keep the laws of inheritance in mind. For any normal* attribute:

  1. If a note has an assigned value, that’s the value.
  2. If the note has a prototype, and if the prototype has a value, that’s the value.
  3. If the prototype has a prototype, and if that prototype has a value, that’s the value. (Repeat as necessary)
  4. The value is the attribute’s default value.

Note that this means that every note has a value for every normal* attribute.

  • FINE PRINT: a few system attributes are never inherited because, for them, inheritance makes no sense. These are intrinsic attributes: every note has its own assigned value for each intrinsic attribute. For example, $Xpos is intrinsic: if you move a prototype a bit to the right, you wouldn’t want every instance of that prototype to move to the same place.

‘Intrinsic attributes’, you say. Why yes, there is a list for that: Intrinsic Attributes. :slight_smile:

@mdavidson

Thanks.

Knowing what to expect helps with experimentation.

Apologies, poorly worded description. What I meant to say was that the “Target Note” did not have any rules added to the note. What I intended to convey was that I didn’t do anything that would have interfered with the application of the rule.

I did create a new test document and did get the correct result where the rule from the prototype appears in the note and attributes are displayed.

However, I’m left with a bit of a dilemma and wondered if you have any advice.

The malfunctioning note does not have any code or text in its inspector panel, and the Rule does not appear in the inspector when the prototype is applied. The attributes list in the Text panel does show the word Rule but there is no code showing.

I tried removing the prototype and using the Reset on the attributes popover. Then applying the prototype. I still get the same result:

  • The result of the rule is produced - Color is changed to red
  • The word Rule appears in the attributes list but with no code
  • The inspector window for Rule is blank.

Something appears to be blocking the appearance of the code, probably something produced by my experimentation.

So I’m wondering if there is a way to universally clear a note without having to delete the note and start again.
I have added another note to the same container and it works with the prototype as expected so the initial note that is malfunctioning appears to be contaminated in some way.

And to be clear I’m not asking “what’s the source of the problem”, only - is there a way to universally reset a note.

I’m asking because I don’t want to get buried in the Production Document and find that I’ve committed some coding sin that is corrupting the operation of Tinderbox without having a way to quickly reset and fix the problem.

AND… thanks as always your explanation is edifying.

Out of interest I think you are saying that the most senior parent drives the value. ie if there is a grandparent then it drives the parent, which drives the child.

But if you change the value in parent I assume that is what drives the value in the child? Not sure why you would do that but the question occurred to me.

Thanks for the feedback.

For example, let us say we have a prototype MAMMAL.

We have another prototype, DOG, which inherits from MAMMAL.

We have an instance, RALPH, which inherits from DOG.

We ask, how many eyes does RALPH have? Ralph has no specific value for $EyeCount, so we look at DOG. DOG has no specific value for $EyeCount, so we look at MAMMAL. MAMMAL tells us that mammals have two eyes.

We ask, how many eyes does LARS THE PIRATE TERRIER have? Lars has one eye; dogs usually have two, but Lars is a pirate. So, $EyeCount(LARS THE PIRATE TERRIER ) is 1, overriding inheritance.

We might also ask whether an animal has a tail. $Tail(/MAMMAL) is false. Some mammals have tails, others don’t; we’ll say that mammals have no tails unless specified otherwise.

CAT inherits from MAMMAL. Cats typically have a tail, so CAT overrides MAMMAL and asserts that $Tail(CAT) is true. Fluffy is a cat; $Tail(Fluffy) is true (from CAT), and $EyeCount(Fluffy) is 2 (from MAMMAL).

2 Likes