Always check assumptions first . A note’s export template is stored in (inherited as) an attribute. Only intrinsic attributes can have different values for original vs aliases. So is $HTMLExportTemplate intrinsic. You can look at its description page in aTbRef or use the Document Inspector’s system tab, as below:
Hey there, I do this all the time. Can you send me an example file of what you’re doing and I’ll try to fix it for you and explain what’s going on. I don’t have the time right now to create an original, but I can fix and explain yours.
Thanks @mwra, @satikusala and @eastgate for the explanation and the links. Your support is much appreciated.
This works fine and I use it for a few templates.
Maybe I am heading off into the complete wrong direction here…
What I was trying to do, is to export and create different output files with different content based on the same selection of notes out of a master container. The master container in the current story (equal a tbx file) has 80 notes.
I wrongly assumed I could do it by applying different agents on the master container in combination with different templates.
Is there a different strategy you would apply?
Just a little background what my work process looks like:
For a story I usually have a master container of 80 to 100 notes. The number of notes is usually stable once the story is setup. What keeps changing as I review the story are the attributes per note and the views I keep creating and adding.
A view (in my one terminology, not TBX views) is basically an agent which sorts and presents a selection of notes out of the master container. I use views a lot during the revision process to see my notes from different angels. A view could show notes sorted by time, by subject, by conflict type, by player or whatever.
As discussed with @satikusala recently I discovered the export function as extremely useful for revisions. I use the html output as my »cheatsheet« when re-writing the real story in Scrivener.
Thanks everyone for further clarification and your support.
Not sure what you mean by “wrongly assumed.” I do this all the time, in fact it is my exact method. If you want, let’s setup a call and I can give you some pointers. DM me if you’re interested.
I use similar. I’ve a very large dataset where I want all sorts of different exports. I use one agent, that finds the necessary notes. Then for each different export, I make a new note whose job is to export the agent and its child aliases. The calling note simply uses an export of ^include(“agent-name”,“template-name”)^. Simply by changing the template name in each case I get a different export.
There are lots of variations on the theme, as shown by @satikusala’s work.
I’d suggest you try out ^include()^ and ^children()^ in some small test, the latter deliberately being a file other than your main work. The point of that? So you concentrate on getting a grasp of the use of include so that when you then implement it in your main work file there is little if any trial and error. Small test files with minimal but representative data are a great way to learn new methods without the worry about breaking the main file or whether this test will finally work.
Thanks Mark, this sounds good, I will try this out
Just for clarification: How many files are created per exported agent? 1 file containing the contents of all child notes - or - many files, 1 file for each child?
If you selected “Export Selected Note” in the File menu you’d get one file for the children (and their children depending on how you wrote your template)".
Here is a simple example to swap the preview and export results.
NOTE: The citeproc error in this example is there because I swapped in the Markdown HTMLCommandProfile for this file and not the Pandoc preview command, that way others can use it.
Hi @Gernot I’m glad we had our call. I know have a better understanding of what you need.
You are actually asking for two things, 1) apply a unique template to each note before export, and 2) export each child of an agent as a separate note.
For thing 1, the example above works perfectly.
For thing 2, at this time Tinderbox does not natively have a function to export a container’s notes, e.g., agent’s notes, as individual files, it packages them all up and exports them as one file. There has been a request for this capability in Backstage. For the time being, the way to export each file as an individual file is to use the following apple script.
-- Have an export folder ready. Select Tinderbox notes and run.
-- NB. Will overwrite existing files of same name.
set theFolder to (choose folder with prompt "Choose a folder to receive the exported HTML files")
tell front document of application "Tinderbox 9"
repeat with aNote in selections
tell aNote
set theFilePath to POSIX path of theFolder & (value of attribute "Name") & ".html" -- name file after note
set theHTML to evaluate with "exportedString(this,$HTMLExportTemplate)"
do shell script "touch " & quoted form of theFilePath -- create file if doesn't already exist
do shell script "echo " & quoted form of theHTML & "> " & quoted form of theFilePath -- write to file
end tell
end repeat
end tell
What you do is you select all the notes in the agent the then run the AppleScript. The script will ask you where you want to save your files and then it will process each file individually and export them.
This is incorrect. Just going into a meeting but wanted to flag this error. The behaviour applies if you (a) use the default built-in ‘HTML’ template that transcludes all child notes (title and text, at least) and (b) you export just the current note. I’ll try to swing back later if clarification is needed.
I’ll be curious for your response. How else would you tell Tinderbox to export multiple notes as operator files, without using Export as HTML which exports the entire document as separate files? IN this use case, we’re not looking to export the entire document as separately files, but only a select few. True, you could click each one seperately and export as a separate note, but you can not click multiple and export as a separate note. When you select multiple files Tinderbox grays out the Export Select Note option. Even if it were not grayed out, it would be nice to be able to just select the agent and then a menu that exports all the children. Depending on how you constructed your template and code it would either use the template assigned by the agent or the template assigned to the individual note. With this last point, I could see the one action of “Export Children” could lead to exporting multiple notes, each with their won template, which would be wickedly cool.
I’m confused. I thought the problem was that it didn’t.
Let’s pare back:
make a test doc that encapsulates your problem.
add the built-in ‘HTML’ export template
IMPORTANT STEP: delete the line in “HTML page” template that says ^children(/Templates/HTML page/HTML item) - this is what causes the misunderstanding.
Now, your test doc will (should) export any/every note as a discrete file.
I’m suggesting this baseline test as previous posts suggest a misunderstanding based on the —IMO—confusingly configured default ‘HTML’ template.
When we’re all on the same baseline, the real problem can then emerge. Readers, please understand, this isn’t some spat as @satikusala’s Tinderbox’s smarts should be plain to all. I _think _ the disconnect is a different experience of ‘normal’ and in a toolbox app that’s easily achieved!
What I want is for it to export every child as an individual file, with either the template I have assigned by the agent or with the template the file independently has.
To get what I want I’d either need to 1) manually click each child not of the agent and export them individually with Export Selected not, which would be a pain, to 2) select all the child notes and run the above apple script, which would export out all the notes as individual files, .i.e., the ultimate goal.
Yes, you could use Export as HTML to get the individual files but this would export the entire document, say 10,000 notes when I only want a select 10.
No, just untick Export (sets $HTMLDontExport) and Export Children (sets $ExportChildren) via the Export Inspector. then export the file.
Can’t fully test as the test doc has a load of errors on missing templates which is breaking export, but the basic point holds true. Container “Report: Posts (23)” exports as does each child. See this specimen export: x.zip (15 KB)
So the process works as described - not withstanding missing templates in the test doc.
Now we’ve got the baseline, could you please re-state question, in the light of the correct context?
i’m not suggesting the default is everyone’s first choice. Indeed, in 2001 [sic] one of Tinderbox’s roles was to write small static blogs. The world has moved on, which begs the question, do 20-year-old defaults still make sense?
The baseline is that I do NOT want to export the entire file. My files often have many hundreds if not thousands of notes. I don’t want to have to go through the file and have to turn on and off Export when all I want to do is create an agent, find a subset of notes, e.g. 10, and export only those 10 notes as individual files. Again, not the entire file, just the 10 notes the agent found. While the above AppleScript I can accommodate my goal, it requires AppleScript and this can be intimidating for many, and easily forgotten. Therefore, the ides, “wouldn’t it be great if” there was a menu option “Export Child” underneath “Export Selected Note” which when selected would export the child notes as individual files. Not a show stopper that it is not there, as we do have the AppleScript, but most certainly a nice to have which would help reduce some cognitive dissonance.
Indeed, but the point is you don’t have to. That is what those two attributes control. aTbRef’s content is all under a single container as that bar one or two extra notes I set up manually. In my big ACM citation project, pretty much all root containers are set to not export notes or children. Using include offers very powerful control.
I’m too buried in catch-up work after a recent conference to build detailed test but see: export-explained.tbx (106.5 KB)
If you export all you get /Content and its descendants as discrete pages and /Offset Import exports note XX and all its descendants as a single page.
Busy, all I’d write a more fulsome demo. But, all the parts you need are in there. I’m not saying an ‘Export selected container’ isn’t useful. It is the case that if you just use the existing affordances you can do what you need without an extra feature (or AppleScript). I do think better doc controls over HTMLDontExport and HTMLExportChildren would be useful.
The key here is to look at the export settings rather than working back from the desired imagined outcome.
Thanks for your file. For me, there is no need of a more detailed explanation. I get it, you basically set everything to HTMLDontExport and HTMLExportChildren to true by default and only turn on those things you want to export.
I see your point and I do see how this can work, but I struggle with this being the answer to accomplish what I want.
First, it is not obvious that this is how it would need to be set up and you’d need to consider the approach at the very beginning of your file configuration, less you have to go through and run several automations to prepare your file. Moreover, it does not intuitively work well when you just want to run an agent and export a few notes, you’d have to remember to configure in your agent action to turn on and the off the don’t export to keep you file clean.
Second, with a file with hundreds if not thousands of notes, it will be too easy to miss configuring some notes and not others, and you’ll a whole bunch of extra notes when all you want is the 10 that your agent produced.
Third, the mental muscle that will need to be retained to manage this approach, long-term, requires too much load.
In order of simplicity, I would think,
Export children or selected notes as individual files option (or some version of this) would be ideal, but it does not exist. Maybe someday it will. This approach will also easily work with markdown and Pandoc processes.
Use the Apple Script approach, this is straightforward, exists and mimicks the logical approach of option 1.
Go the route of toggle on and off the HTMLDontExport and HTMLExportChildren options. Yes, it works, but…
. A note’s export template is stored in (inherited as) an attribute. Only 
