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 allows the name and date of a user attribute, attribute("name")["description"] allows writing a description to an extant attribute. IOW:

createAttribute("FooBar");
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’.

6 Likes

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?

4 Likes

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.

2 Likes

A simple function to create all your user attributes:

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

use it like:

createUserAttributes_db("AssignPrototype:string;AttributeName:string;DefaultPrototype:string;DoDebugLog:boolean;HeadingLevel:dictionary;SelectPrototype:dictionary;");

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;
	vAttrList.each(anAttr){
		var vAttrKeys = attribute(anAttr)["type"];
		$Text = $Text + anAttr + ":" + vAttrKeys + ";";
	};
};

just an idea :wink:

4 Likes

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
Tom

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

It’s been a while. @webline could you please clarify step-by-step how to use this functions?

the first function createUserAttributes_db(theAttributes) needs one parameter: a list of the attributes you would like to create in the current TBX file. It should look like this:

“AssignPrototype:string;AttributeName:string;DefaultPrototype:string;DoDebugLog:boolean;HeadingLevel:dictionary;SelectPrototype:dictionary;”

The format is name:type. So to create an attribute named “MyFirstAtt” of type string you would add “MyFirstAtt:string” to the parameter string.

After building your parameter string you call the function - like

myAttributes = “MyFirstAtt:string”;
createUserAttributes_db(myAttributes);

That’s it to create the attributes. To store the user attributes of your current file you use the 2nd function. For example you could create a stamp to store the attributes in a note:

$Text = getAllUserAttributes_db();

Now you could copy this note to a new file. Create a stamp like this:

createUserAttributes_db($Text);

and run it on the copied note. Now all user attributes will be available in your new file.

1 Like

Thank you very much!
I’ll try it.

If only there are a way to automatically make a list of all user Attributes and format it for this function - would be great.

$Text = getAllUserAttributes_db();

will do this…

1 Like

The code above (here) for user function getAllUserAttributes_db() appears to set $Text in-function. Note that (a) the current note’s $Text is set within the function and (b) the function has no return statement. If it had the latter, the returned value would overwrite the $Text value just set buy the function code.

But, with this code:

$Text = getAllUserAttributes_db();

Whilst it works, it does so by accident. The correct way to use the getAllUserAttributes_db() is simply call it, with no left side argument used, i.e.:

getAllUserAttributes_db();

This way there is less chance of an accidental unexpected outcome.

2 Likes

Thank you, Mark! Now it works properly.

1 Like