Those who use Tinderbox's
unique power to 'Explode' long text files and manipulate the many resulting "fragments" may find this tip saves much fiddling and fossicking about. It leverages TB's automatic placement of fragments in convenient containers always named 'Exploded Text', and uses
one simple agent and a
prototype with a self-canceling rule. Altogether three short lines of code.
The problem: After using 'Explode' on a long note, often one needs (like investigators of a physical explosion) to identify where each fragment came from, and keep track of that information after removal from the scene. In Tinderbox one way to do this is to populate some variety of 'MySourceID' attribute and/or other metadata such as the source's url. That can take care and feeding.
One solution: Instead of scrolling to select potentially hundreds of fragments and applying a stamp corresponding to each source note, or fiddling with various and sundry agents to automate the stamps, perhaps leaving rules running constantly in hundreds or thousands of fragment notes with unintended effects when the notes are moved, try this:
1) In each original unexploded source note enter in user attribute '$MyString' an alphanumeric value identifying the source (or whatever other metadata will be wanted in the fragments).
2) Create an 'AllExplodedText' agent that gathers all exploded fragments.
AgentQuery: $Name(parent)=="Exploded Text" AgentAction: $Prototype=protoFragmentNote:
inside("Exploded Text") in the query should also work if only one 'Exploded Text' container is present. But if there is more than one the agent only finds the "first" one.
3) Create the prototype 'protoFragment'
KeyAttributes: As desired to define how a fragment will look when opened Rule: $MyString=$MyString(../..); if (!IsPrototype) {$Rule=""}Now, whenever a source text note is exploded the agent gathers up each fragment and assigns the prototype, whose rule is inherited by each fragment, causing each fragment to grab the desired value from its original source text note (its grandparent) and then clear its own rule in a way that breaks the rule inheritance from the prototype. (Hence
$Rule="" , not
$Rule=; ). The 'if' statement prevents the rule from being cleared from the prototype, so the prototype stands ready to pass the rule on to any "new" fragment, which applies it once and cancels it.
This approach has an added benefit. After applying 'Explode' and looking at fragments, the metadata from the source note may seem inadequate or wrong. Just delete the relevant 'Exploded Text' container and contents, change the offending value in the source note, and 'Explode' again.
Or if the inadequacy is discovered after many links or values already have been added to the fragments, then change the offending value in the source note, and consider applying a 'Reset rule' stamp to all the notes in the relevant 'Exploded Text' container with this action:
$Rule=; . This restores the inheritance from the prototype. The rule runs once, then cancels itself, once again breaking the inheritance.
Note: Using
'../.' or
'parent' as the designator instead of
'../..' or
'grandparent' also works in the prototype rule. Though I couldn't find documentation, it seems each 'Exploded Text' container inherits many attributes from its parent, the original unexploded note.
Comments/critiques appreciated. Any misinformation here? Even easier way to accomplish the same thing? What code would automatically create a link from each exploded fragment to its source, so the links could be visible after fragments and sources are moved to a map and moved around?
Resources and references:
Forum and aTbRef tips and references: here,
here, and
here. (Thanks to Mark, Mark, and Amber.)
User's Manual references: 'Explode' is described in the (long…so scroll) section on 'Importing Notes'.
Example TBX ( 'Exploded Text example' ) posted
here. (Novice coder alert; use at your own risk)
Home
Pages: 1
Sweeping up after a long text 'Explode...' (Read 14127 times)
