Tinderbox Meetup - Saturday 4 May

The day went sideways for a number of folk, so this was an informal meet. For the record, there was a meet but it was unrecorded as we weren’t sure it was a meet—until those there all decided it was. About 11 Tinderbox folk made the meeting and Tinderbox was discussed in the round though there were no demos as such—so if you weren’t there don’t worry about missing

We discussed ‘template’ documents and how to store code/config centrally. I think consensus was that whilst this seem good, in practice it is hard unless all your docs relate to a consistent task. In looking at the wider context and how to capture intent for future self or other, @echuck made a very pertinent point about documenting the how and why if your intent at the time.

In the moment I couldn’t check. But, whilst createAttribute() only allow the name and date of a user attribute, attribute("name")["description"] allows writing a description to an extant attribute. IOW:

attribute("FooBar")["description"] ="This is why I created this attribute...";

Other attribute aspects can be edited, see: attribute(attributeNameStr)[keyStr].

Other ways to document important info:

  • action code allows code comments
  • any note can be used to document process
  • use specimen/starter note (via favorites folder)
  • use library notes containing functions that configure attributes and code

Long-time users will attest that what is obvious today, is easily erased by the Blessed Sponge of Amnesia in less time than we’d hope. If you care about it, stick some metadata on its finger.

I think that was the major takeaway from another interesting meet.

Note to the community: we might make a discussion/demo about how to record process, document attributes, etc. There’s no single ‘right’ way, but doing something, anything, can pass by many of us in our busy workdays and the need to ‘just get stuff done’.


Apologies to all for missing today. I had a morning meeting that ran late, and from which I couldn’t extricate myself.

I wonder whether "Documenting your Tinderbox work” might be a good topic for next week?


I do think so, all the more so because—in true Tinderbox style—there really is no one right answer.

A relevant point is attribute(attributeNameStr)[keyStr] and what can/can’t be altered via action code. Why does this matter? Because Hoomans nver mak mistaks. Once we define code or attribute is never needs correcting. :roll_eyes:. Except it turns out we’re generally lazy, feckless and often don’t get things right first time.


A simple function to create all your user attributes:

function createUserAttributes_db(theAttributes){
		var myList = anAttr.split(":");
		createAttribute(myList[0], myList[1]);

use it like:


You could use this function to store all you user attributes in a note, copy it to a new file and pass the content to the first function:

function getAllUserAttributes_db(){
	var vAttrList = document["user-attributes"];
	$Text = vAttrList;
		var vAttrKeys = attribute(anAttr)["type"];
		$Text = $Text + anAttr + ":" + vAttrKeys + ";";

just an idea :wink:


And a good one! Now we can do this regular/power users should give it thought. Not all of us need to do this but for a few I think the you code is really useful.

Great idea, @webline. Question: I assume the new file will be a tinderbox file? Could it be a text file? If a text file can be used to externally store the attributes, how would the code change?

Thanks in advance

Hi Tom,

yes you could use an external files to store the configuration data for your attributes.
Maybe the ideas about storing action code in external files could help?! There was an older discussion here and here is something Mark did for reading plain text files into TBX.

1 Like