The name is bad and there is a lot of redundancy. But it works for me, since I’m a very visual person, and using this model allows me to add ease to distinguish notes to an outline, and having those notes displayed in other ways (as summaries in $Text or $DisplayExpression, or as $KeyAttributes for later use).
– this template shows a way to add structured notes (kindA, kindB, kindC) to a container (chapter) in a visual way (with colors and badges);
– the chapter’s $Text will provide a summary of these notes by collecting its descendants (select “myFirstChapter” or “mySecondChapter” to see it);
– the chapter’s $DisplayExpression will also show the $Name of the notes inside it, according to their kind (expand "mySecondChapter to see its content and how it is reflected on its displayed name);
– the chapters parent (i.e. the book) will use the same technique to add the notes $Name to its $KeyAttributes (as sets);
– finally, the books $Text will summarize the notes inside all chapters (select “myBook” to see it)
For equality tests in queries, such as used in the collect_if(), use == and not =.
You don’t need to escape the ‘(’ characters that are inside literal strings.
+ " )" + " \( B- " can be written more simply as + " )( B- ".
the .replace() call is just formatting a list but using a contains-like regex to do this. My understanding is that .format() would be more efficient here - MB may correct me. Efficiency comes into play as the document grows in size/complexity, rather than at the size of a demo.
Some further edge case issues. collect_if() returns a List-type. Lists allow duplicates. Now you probably won’t use the same named character note, e.g. “Donec”, twice in a chapter but if you were to you, you’d get ‘Donec’ twice in the list output via your rule. Also lists built in the order items are interrogated with (I assume) is $OutlineOder. If you want the items in alphabetical order use a chained .isort. Why .isort and not .sort? .sort will sort all capital letters separately from lower case ones (Ant;Bee;ant), whereas .isort returns a more ‘human’ sort result (Ant;ant;Bee).
Below I’ve added both these to the above but omit either both these latter as your own project’s needs demand:
The output can get quite long. On my 13" MBAir it didn’t take much to make the $DisplayName string wrap to a new line. This you might consider putting the data into $HoweverExpression, which works in outline view.
Thanks for the suggestions. Namely the uniqueness issue.
I always keep forgetting to use == instead of = … maybe TBX should throw an error when using a single = … sometimes users need harsh measures
Have you done this with a document with a lot of notes? I wonder if the intensive rules would slow things down.
Why use this approach instead of agents?
Did you know in Tinderbox 7 you can make a selection of notes and the text panel will combine the text from the selected notes in one continuous view. An interesting feature that might play well with your approach.
Thanks. Right now I’m using this on something like 10 books, each with 20 chapters, and each chapter with 10-20 “kind” notes. 10x20x15 = 3000 notes and no problem so far
But I’m planning to have around 100-150 “books”. If things get slow, I can always apply the rules with a stamp instead of them being always updating.
Regarding agents, don’t know … how could they help in this scenario?
Yes, TBX7 has that great feature (altough I’m hoping that it gets possible to edit composites instead of just seeing their contents). But I came up with this model a few months ago, no TBX7 back then
Just curious if an agent could be used to used to gather the pieces of one of your books, handle the $DisplayNames, etc. – add $Badges, etc., – to take off some of the load of all those $Rules.
Yes, agents can do all that. But I think there would be a problem of scope … I am targeting descendants, so I think using a rule inside a prototype is a better way. Otherwise I would need lots of agents! (I guess).
