One of the reservations the Tinderbox-curious sometimes express is that it looks complicated, or intimidating. That is often the way things that are unfamiliar appear. And we have a tendency to impose expectations on something that we decide that something unfamiliar might be, and then get upset when it doesn't match those expectations.

Tinderbox is pretty unique, but it has some features that may make it appear to be one thing or another, when it's usually both, or neither. So it's probably best to just kind of let go of your expectations and explore the app and ignore the feelings that come up when your "monkey-brain" keeps insisting, "Oh! It's an outliner," or "Oh! It's a mind-map!" Just let it go and keep exploring.

The marketing slogan is that it's "The tool for notes," and we all think we know what a "note" is.

Well, I hope I'm not adding to the confusion, but it's more like, "The tool for nodes." A note is the fundamental unit of Tinderbox, and it has a flexible facility for adding attributes to a note. Even the text of the note is an attribute, and it's called $Text.

Agents are notes that can find and collect other notes, based on a query regarding attributes. The marmot's home page is created by an Agent that collects all the posts I write today, because the Agent compares today's date with the $PublicationDate of the post. It's an ephemeral construct. All the posts I write this month really live in a container note (node), called February 2024, which, while not inert, is nevertheless fixed in terms of its location in the hierarchy, which happens to be a chronological structure in the context of a blog, and all it does is look after its children.

Agents are fundamentally different than a "note," in that their essence is to work with other notes. It doesn't have children of its own, but it does gather other notes' children for the whatever the author's purposes may be. In my case, to have the most the day's posts on the most recent day I've blogged, appear as the home page at the marmot.

That's why I like to think of the fundamental unit as a "node." A node is "a point at which lines or pathways intersect or branch; a central or connecting point." Since each note has a location, be it in a map or in a hierarchy of notes, in relation to other notes, and that location is merely another attribute, it maybe helpful to think of the fundamental unit as a "node," and perhaps that will help reduce the burden of expectations for a "notes app."

"February 2024" is merely a container in the Tinderbox document (TBX) that is the marmot. It is a child of the container "2024," which is in turn a child of the container "Archive." All these containers have a job to perform, and it involves having "children" and looking after them to see that they have all the "attributes" necessary to be productive elements of the marmot (or society).

"Archive" is the senior member of the clan. It mostly sits there, quietly, observing its children. But it does know the time. Specifically, the year. In an attribute called an "Edict" is a bit of "Action code," that looks at today's year, and then looks at its children and makes sure there's a child called 2024. If there is, it just sits and waits.

At some moment, early on the 1st of January 2024, Archive noticed that there wasn't a child called "2024," so it created one. Archive only creates one "kind" of child, a container whose name is the current year. It creates that specific kind of container from a "Prototype." A Prototype is a note with a given set of attributes, among which is the Action code that allows it to perform its function with its children.

So, Archive begat 2024. 2024 opened its eyes, noted the date and discovered that it had no children! In an Edict in the year prototype (called "p_Year" in the marmot), is the code that tells a newborn year to be fruitful and multiply. The Edict says that if you have no child named (current month) 2024, then create one! In another attribute within 2024, inherited from p_Year, is a bit of code in an attribute called "OnAdd." The Edict attribute of note 2024 created January 2024, the OnAdd attribute assigned its prototype, "p_Month."

Archive begat 2024, 2024 begat January 2024, and February 2024 and in 8 days will create March 2024.

I felt very clever when I built this into the marmot late last year.

For every year prior to 2024, since 2013, at the end of the year I manually created a new year container, then also manually created a new month container, and manually copied and pasted all the code necessary for a month container's OnAdd action, also manually editing that code to reflect the current month and year. This sometimes resulted in typographical errors that, temporarily, "broke" the marmot.

Well, computers don't make typographical errors. So I learned how to tell Tinderbox to do all that infrastructure stuff.

Computers do exactly what you tell them to do, so imagine my distress when 2023 went on creating January 2024 as one of its children! "You're only supposed to have twelve! At the most!"

So I had to look at the code in the p_Year Edict and see why it was doing 2024's job. 2024 was doing fine at the time, but it would have acted just like 2023 at the end of the year.

Well, p_Year knows the date, and it knows to look at its children and make sure it has one for the current month. On January 1, 2024, 2023 looked at its children and noticed it was missing a January 2024! So it created one. Argh!

At first I thought I had to figure out some way to tell it to stop after 12 months. Notes can count their children.

Then I had another thought. I'd make having children conditional. An "if" statement was necessary. Something that said if your name is 2023, then don't make any children with 2024 in the name. So that was a bit of a head-scratcher, since I don't do this often.

I knew I had to wrap the code in the Edict in a set of curly braces so that it would only fire if the conditional were true. Or false. Something. So what would my conditional statement be? My default setting is to look at note names, but the $Name is just one of many attributes, and I was dealing with dates anyway, not names.

A note knows when it was created. It's automatically populated in the $Created attribute. And a note knows what date and time it is at every moment. So I figured I had to write a statement that said something like "If today's year is not equal to the year you were created, then don't create any children."

This was the wrong approach, but I learned something fumbling around with it. The "equals" value comparison operator is "==", to set an attribute value you use "=". So I figured "not equals" as a comparison would be "!==" where "!" negates the equality comparison.

Well, no. That "doesn't equal" comparison operator is really "!=". Details matter.

Anyway, it dawned on me that I was making it too complicated. I only wanted the Edict to fire if the current year was the same as the year it was created.

That looks like this:

if($Created.year == date("today").year)

Then there's the existing code, now wrapped in curly braces:

{

$MyDate="today";

$MyString=$MyDate.format("MM y");

create($MyString);

}

So the 2023 year container knows it's 2024. It knows it was created in 2023. The comparison fails, so it doesn't carry out the rest of the code.

Now, I can't tell you, step by step, how I figured all this out. I tried, but there was a fair amount of trial and error, some frustration, and a walk in all this. But I did figure it out. Maybe that's a product of 10,000 hours of futzing.

I am struggling with trying to figure out an "On this day..." Agent. But I'll noodle around with it some more, and if I can't figure it out, I'll ask at the forum.

Anyway, this is just a long way of saying, "If I can figure this stuff out, you can too."

I mean, I went to a trade school, so...

Originally posted at Nice Marmot 06:11 Wednesday, 21 February 2024