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:
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.