I have a fairly complex doc with a lot of prototypes. I recently realized that I needed to add some key user-defined attributes to one of those prototypes, which I use a lot. One of the glories of Tinderbox is that I’m not penned in by decisions I made months ago about such things.
But when I turn to some older notes that take that prototype, they have not changed to reflect the changes I made in the prototype. The new attributes I created, which are in the prototype and which appear in a new note that takes it, do not appear in older notes. They still present key attributes of the older version of the prototype.
This is not a case of Tinderbox protecting some KA values from being modified. These new KAs are empty in the revised prototype and so I expected them to appear in all notes that take that prototype, regardless of when the notes were created.
I’m puzzled as to what I might have misunderstood here.
Tinderbox 8.2.1 on Mac 10.15.2 on a 2018 Macbook Air.
A note inherits its values unless it has a value of its own. Thus, if an old notes already has a value of (say) $KeyAttributes, that value overrides inheritance. So, if your old notes already have some value of $KeyAttributes, Tinderbox assumes that’s the value you want for that note.
You can remove an existing value with a stamp action
Thanks, Mark. Does that mean I have to do this note-by-note, value-by-value? What I want is to add some Key Attributes to older notes, via the prototype. I don’t see a way to tell TInderbox to do that all at once, for all old notes that so far lack those KAs.
Doing it note-by-note seems to defeat the purpose of using a prototype, but maybe I am missing something.
Is it easy to select all those notes? If so, select them and reset the value with Quickstamp or a stamp.
Or, use a stamp to remove the old $KeyAttributes and set the prototype in one step.
If you think about it, this is necessary for inheritance to be useful at all: otherwise, notes with a prototype would simply be aliases of the prototype!
Action code hasLocalValue(), which is useful for finding notes that don’t inherit but should (i.e. you have accidentally set that attribute in the note itself, blocking prototype-based inheritance)
There are so many powerful searching and filtering tools available within Tinderbox, that it should be possible to do this in an automated way–if the numbers are large enough that it’s too much of a chore to do them one-by-one.
Here are the basic approaches that occur to me, which you probably already have in mind:
An agent that will search for the ones you’re looking for – using criteria of $Created before a certain date, or existing $Prototype meeting some search standard, or $KeyAttributes containing or excluding some value, or $hasLocalValue($AttributeName) being true (rather than inherited) – or some combination thereof. Then you could have the Action for that agent being re-setting the prototypes (or the Key Attribute values) first to the default value, and then to the new one you want. Eg, as @mwra and @eastgate have set out in their notes, doing a sequence of $Prototype=; (to reset to default) then $Prototype="new value"
You could also use the similarly powerful query feature in the Attribute Browser (which uses the same language as agent queries, as far as I’m aware) to produce a display of the notes in question. I don’t think you can do a Select-and-Quickstamp operation on those results within the AB itself. But you would have a sense of which notes you were looking for.
Using approach one, of an Agent to find the notes you’re looking for. But then, rather than an Action to automatically shift all the notes it discovers, you could create a Stamp or Quickstamp, to be able to inspect the results and de-select any of them you’re not really looking for.
Good luck; many tools. If I’ve messed up the details, one of the experts can set us both straight!
Thanks, James Fallows (and both Marks!) for these insights. Maddeningly, I seem to have fixed this in the doc, but I don’t know how, because I lost track and can’t retrace my steps. Now, prototype changes are back to working (to my mind) logically: A new key attribute added to a prototype is added to ALL notes that take that prototype, because (to my mind) it cannot yet have any non-default values to protect.
But I’ve learned a lot from this discussion about how prototyping works and how to avoid confusion about it. For instance, I tend to think of “the attributes” as only those I can see and care about (ie Key Attributes). I forget there are many others, and I suspect protecting some of those was Tinderbox’s goal.
True, Mark B. But I think it’s reasonable to expect inheritance of a new KA that cannot have any value other than default. Which is what my Tinderbox docs do in any event – values of other KAs are protected and the new KA is added to all notes.
Pretty sure this arose from my using Map view extensively for the first time, which has been extremely helpful and interesting. But that’s material for another post, in the Tasks section, which I hope to write when I get a moment…
So it turns out the mysterious inability to add new attributes to a prototype’s descendants was caused by … my accidentally changing the name of the prototype.
Some words I’d meant to type elsewhere somehow got into the doc as the new name of the prototype. Notes that had the attribute $Prototype=Person were not picking up anything added to this proto that was no longer named Person.
I recount this user foolishness here only because it raises (for me) a question: Would it be possible for me to create a guardrail against this kind of thing? I envision some adept use of Tinderbox’s tools that would cause this doc to throw out a warning like “Attention! You are about to change the name of a prototype that has X descendants and is named in Y actions. Really, dude?”
I am very happy that Tinderbox is not clogged up with Word-style warnings and “are you sure?” and all that. But if a user can do it, I wouldn’t mind building in some warnings against things that could cause confusing behavior. Like putting a = in an action instead of a == .
Not asking Eastgate to supply these. Asking if I, as one idiosyncratic user, could create the ones that would help me.