Tinderbox Weekly Meetup - Saturday 27 JAN 2024

Bring your projects and puzzlements! New Tinderbox users very welcome!

9 AM Pacific Time
Noon Eastern time
1300 São Paulo
1600 UTC
1700 London
1800 Paris
2130 Delhi

Join Zoom Meeting

Meeting ID: 617 924 9044
Passcode: tinderbox

For more details and to join the conversation with the Tinderbox community, visit the Tinderbox Forum: https://forum.eastgate.com/.

Mentioned in the demo, a flashback to 2009, the Afghanistan Counter-Insurgency strategy (‘Afghan COIN’) demo where I took on the challenge of deconstructing a Beltway briefing slide into a Tinderbox map: download files

A useful wrinkle arising from the discussion is the relationship of ex[port code ^include(item, template)^ and action code exportedString(item, template). They are essentially doping the same thing, one from an export context and one from an action code context.

Both operators, if not additionally configured use this note’s assigned template to return the (export) output of the template. For instance a note might have $Text with a paragraph of text, but we also want to append an HTML table of data drawn from other attributes in the note. So we make a table ‘t_table’ and add a new paragraph to $Text:

^include(this,"t_table")^

Or, if you don’t want export code in $Text^, alter the note’s export template code from:

^text^

to

^text^
^include(this,"t_table")^

Now, when the note’s export template is evaluated it adds the HTML preambled, etc. then adds the HTMl-encoded $text (via `^text^) and then it reads the contents of the include and so magically exports a table that isn’t in the $text of this note but is created from this note’s data!

So where does exportedString() come in? This allows you to do a similar inclusion trick in action code. In some cases, you’d now use a function to work with text. But occasionally, you may find a need to alter the HTML-marked-up output of $Text before it gets passed to the export stream. For instance, say you wanted to expand an acronym found in $Text, but only do so for exports. By adding an ^action()^ at the top of the template we can working in action code. exported() lets us self-include and return the ^text^
output and read it into an attribute and variable as a text string.

We can now use action code’s large text manipulation toolbox to find and replace the acronym with it’s expanded form, within the HTML encoded string.

Now in the main part of the template we replace a ^text^ code with something like ^value(vModifiedText)^ thus outputting the modified HTML-encoded text. Neat!

I’m deliberately not doing a demo here. the point is to show how codes like ^include()^ and exportedString() can be really useful when you want text export that is other than the literal contents of $Text. Most will never need this, and that’s fine. But having read this, if you stumble on the need, hopefully this ill give to an idea where to look or the genesis of a question here. (It wanting to do so now, please start a new thread with a suitably descriptive title).

See more on:

Separately, I’d re-iterate the point about names, paths and IDs. When learning how export works, it is much easier to use note titles ($Name) or paths ($Path) as you template code will be much easier to read. If you go on to working with a lot of export and automation, then you might choose to use $ID or $IDString). But don’t feel that you’re missing out if you see the latter used. The reason for such use is normally due to more complex contextual issues.

Video: https://vimeo.com/907057248?share=copy

1 Like