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...";
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’.
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. . Except it turns out we’re generally lazy, feckless and often don’t get things right first time.
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?
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.
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:
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.
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.