Objective: Produce a table that contains attributes and body text of the children. Desired results: when selecting the “Produce Table form children note” the children appear in a table and the ^value($ShortTitle)^ in a child $Text appears in the table along with the other text.
Actual Results: The table appears as desired but the $ShortTitle attribute in the child $Text is not rendered.
Question: It is not clear to me why the $ShortTitle is not rendering properly when in the Table but does so just fine in the Page Normal note; can someone help?
The problem is not with the ShortTitle column; it’s with the text column. (Confusingly, your text reports that value of ShortTitle; that puzzled me for a bit )
The expression
^value(Text)^
gives you the contents of text, considered as a string. If you want the markup in the text to be interpreted, instead use:
The problems here run several layers deep. The bottom line is the ^value($Text)^ exports the actual (plain) text of the target note so inline ^export-code^ is ignored. In this case you want to use ^text^ instead.
Next error noticed: you are calling notes that aren’t templates (i.e. $IsTemplate is not set to `true. So, garbage in, garbage out as the app can’t intuit your meaning (and even if an AI would like guess incorrectly). Just adding a root-level container ‘Templates’ doesn’t add/set the prototypes as are added when adding a built-in template†. Be aware that just citing a note as a template does not make it a template.
Otherwise all seems well.
†.@eastgate, this might have seemed extra in the past, but on reflection if someone one adds a ‘Prototypes’ and/or ‘Templates’ container at root I think it makes a lot of sense to act like they just added a built-in prototype/template and then deleted just to add the necessary infrastructure. As edge case is case sensitivity. FoNow, today, for a new docI’d let anyone add either container in either case but update it to the capitalised default form and add the requisite $OnAdd code and prototypes if a template. In that score there really ought to be discrete one-page and cascading page built-in (HTML) templates.
Ah, yes, you’re absolutely right. Thanks. Tinderbox has that balance of the need for precision and forgiveness. Quite often is will forgive you and properly intuit what you want, but most certainly prefers precision. I like how it (and the community) is teaching me both.
Thanks. As you generously note, Tinderbox is quite forgiving.
However, as past initiatives experiments like AppleScript have shown, free-text coding is a double-edged sword. It lets those who know what they want ask for it in a vernacular they understand. Sadly for the other 99% is just means weird code fails for unguessable reasons IOW, it ought to work in theory but doesn’t, because … free-text code proves insufficiently smart enough to understand (qv any current AI).
Having rules helps those with less understanding. Fall-backs that let experts colour outside the lines are cool but I’'m now seeing such affordances shroud either be documented separately or not at all. After all, if you’re smart enough to colour outside the lines who needs rules? It’s not; like you’ll look at the docs as that would be an admission of weakness.
Any example: you don’t need to close export codes with a final ^. Tinderbox may guess where the code finishes, or likely would have in 2000. 20 years later, theTinderbox code environment is way more complex and ‘may work’ is feels likes throwing shade at the learner. It’s not meant so, but intent is in the eye of the beholder.
)
Works like a charm. Totally AWESOME!!!