OK fair enough, I will add it to the top wiki post, but It will be later as I am out to lunch 
I am attempting to accomplish “Publishing an opportunity to learn”, not simply get the end result.
Later I may publish a solution that does what this example documents.
The first example is executable, which you can test.
You see, I can’t tell from your post if there’s something there that I’m interested in learning.
Your first paragraph says
The following is a TiddlyWiki script solution to place multi-line notes on any tiddler, with wikitext, but stored in a data tiddler. This means the tiddler on which the note is added is not touched.
I read this and said to myself, “I already know how to do this. We’ve discussed similar things a number of times here.” I also saw it in the discussions of flags Tones recently started. I’ve never specifically done notes. But I’ve done similar-enough things that this doesn’t affect me. I’ve also never stored the results in a single data-tiddler, usually spreading out the information across many related tiddlers, but I’ve progressed far enough in my TW journey that this is something I can do easily.
So I skipped the explanation, and added the first example to the main site, and saw the behavior. There was a note and it was stored outside the tiddler itself. Got it. I looked up a little and saw $:/tags/Global, so I added that, and added the procedure call to another tiddler. “Look at that, they’re independent. Ok, so how’d he do it?” I glanced at the code, and quickly focused on the $transclude widget near the bottom, saw that it uses <<note-database>>, looked that up near the top, and found that it’s just a single tiddler. I checked that tiddler and the data is stored in a JSON tiddler.
So now I have to decide if this is worth it to me. There are another 1500 words or so in the post, including maybe a dozen code samples. I have no idea where this is going. What’s the end-state? Or is this all explanation for the code sample that preceded it? a scan of the headers doesn’t really tell me. And I make the decision that it’s not worth my time unless I can find out what it is we’re trying to reach. When I ask for that, I guess I find out that I’m not interested in learning. 
The subsequent discussion makes it seem that there is not much more, just an explanation of how this first snippet was accomplished. That’s certainly a useful thing to explain. But for me, unless I have extra free time, I’m not likely to bother.
Right. As I said above, I could not immediately tell if that was just table stakes to be expanded upon or was the end goal on its own.
I’m with you, Scott. On first reading I felt adrift without rudder or compass. I’m still not sure I have a firm grasp of where it’s going. That said, here’s my current “where I’m at”…
I think because of TW’s declarative nature, the “net effect” of what is proposed is kinda already present – TW lends itself to this kind of approach OOTB. The proffered “solution” doesn’t feel like it solves anything – a solution in search of a problem, perhaps.
One part that confounded me is the notion that a notes database is even needed. It feels like an unnecessary level of abstraction. My TiddlyBook system does all this (irony: demonstrated in part to @TW_Tones and @nemo just prior to this post going live) – complete CRUD too – no database/data-tiddlers necessary.
In fairness to @TW_Tones, I think he was pushed into posting this wiki-post here when in fact it isn’t ready. It’s a research project that may have a few tricks that others may find useful. It certainly shouldn’t be presented as a solution in Tips & Tricks when CRUD is not fully supported (yet).
I think there probably are times for this, mostly when you want to avoid a large proliferation of dependent low-complexity tiddlers. This is one of several designs I’ve considered for when I finally get back to my periodic table work: I want users to be able to add their own blocks of information to the Element and Compound tiddlers, but want those tiddlers to remain pristine. This is one technique that would allow for that. I have several other possible techniques, and this one is low down on the list, mostly in an “if everything else fails” manner, but it’s reasonable.
Usually, though, I’m not worried about tiddler proliferation. And it’s easy to add dependent information to other tiddlers that link back to my main one, explicitly with some sort of parent field or implicitly with a naming scheme. (title: MainTiddler/note1).
I am slowly coming to believe that (as I believe Jeremy has suggested) that data tiddlers are mostly a distraction in our “Everything’s a tiddler” environment. But I really doubt they’re going away.
I’ll have to look for that. If it was public, I missed it.
If you use CRUD for create, read, update and delete. It is all possible. If you copy paste the initial example into TW you’ll get all the CRUD elements.
There are some usecases, where data-tiddlers make sense, that’s why we can not remove them.
Especially for 3) many users go a long way, even if technically it would be easier to avoid data-tiddlers.
For my personal wiki, I used them because data tiddlers contain content in the text-field, which is searched in TW by default and I wanted to use them as a timestamped, auditable link log
The data-tiddler is not required for zero-touch. And I take your point where you reference Jeremy’s thoughts – 100% agree. But let’s not conflate zero-touch with the “trick” to use data tiddlers. (Re)consumption/transclusion of a data tiddlers is not as straightforward as a regular tiddler. I’d say most users stick to regular tiddlers.
Zackly. <tiddler-title>-notes here (plus <tiddler-title>-info <tiddler-title>-plot, etc.
It’s starting to sound like I think the OP is a terrible idea – NOT TRUE! I just don’t know what it is… or “why”.
But not Rename. Without intrinsic renaming, it’s a footgun. In some circles it was touted (years ago) that the “R” should be “Rename” – Read after all is a given (I’m reminded of an extremely old April fools joke about “WOM” - write only memory 
).
And yes, I tried the example when it was posted in another thread. It works. But again, not sure what the benefits truly are.
IMO, the major points of Tony’s no-touch approach:
$:/note-database, as defined in the procedure in the OP.MyTiddler/notes, MyTiddler/to-do, and MyTiddler/42 all showing up every time I search for “MyTiddler”, particularly if they’re only ever going to be displayed or modified via a ViewTemplate on MyTiddler itself.I think these points make this a good approach if you have a collection of user notes that you want to quickly transfer between wikis — say, documentation notes for various $:/core tiddlers. It would also make it easy to share notes of this sort with others in a non-destructive way.
Edit: Another potential use: collecting feedback or annotations from multiple reviewers.
Perhaps it could enable a “Guide to TW” plugin, as suggested by @twMat? You could then enable or exclude notes from your (least) favorite contributors, as someone else requested…
Agreed. But I think there are notable exceptions. Another thread explains what I think might be a motivating example, and I can think of another simple one:
{
"HelloThere": {
"score": 4,
"comment": "This is fine for the moment, but some eventual modernization wouldn't go astray",
"priority": 8
},
"Quick Start": { /* ... */ },
/* ... */
"Creating Substories": {
"score": 3,
"comment": "The explanation is reasonable, but it's lacking motivation. //Why would I want this?//",
"priority": 3
}
}
Imagine a tool that let you build a JSON tiddler like this, paired with a ViewTemplate that displayed this information on all non-system tiddlers and a summary tiddler that lets you find all priority 1 element, sort by score, etc.
You could drop my version of this on the main site to see what work I think needs to be done. We could collaborate on a shared version. But it’s extremely unobtrusive, adding only a handful of tiddlers, even though it updates your view of everything.
There are plenty of other possibilities. I still don’t think I’d want it very often, but I can see times.
Edit: It looks like @etardiff beat me to the example (“documentation notes for various $:/core tiddlers”.) Great minds, and all!
Ouch. That point had completely escaped me. Thank you!
@Scott_Sauyet @etardiff (@TW_Tones)
I think it fair to say, I’m suffering from a failure of imagination. Thanks, both.
Not something I would say about you.
Ever.
I agree with @etardiff comments and can see a use for Journal Tiddlers / Calendar Events having attached notes via single or multiple $:/note-database tiddlers.
You could have smart-tabs on a tiddler providing a variety of note topics, categories or projects.
(along the lines of this discussion on the non-JS Calendar by @hoopyfrood and @arunnbabu81 if your interested}
Did you @Scott_Sauyet and @CodaCoder not read the second paragraph in the first post?
Scott, You have being in a range of activities over time, and only you can decide if your are going to make use of this. This solution is different to Flags in a number of ways, the notes are multiline/text area notes. 
perhaps this could be how flags work, note enabled. Select from multiple notes data tiddlers to organise the resulting notes, more than one external note for a tiddler?
All the snippets are pulled out of the first code block and explained.
Are you assuming there is nothing you can learn in the details? The code actually uses backticks crafting a tooltip, shows pragma inside procedures, leveraging the popup attribute for toggling content, shows short and long form of %if, using functions for easy to read conditions, doubling as the retrieval of database records, loading a button with multiple forms of action at once, highlighting the need for tc-popup-handle class, Using a macro in a filter, using blank lines and indents to make code more readable, leveraging other html tags on button content, multi-line data tiddlers, wikifying such content and more…
But its not all about anyone of us, in the community there are all matter of different knowledge levels, there are people like me who like to comb through “interesting” examples of how people do things. As my expertise grows I like to see the details and code tricks people use, so if someone else publishes something like this I will gobble it up.
As I said previously it was not about the solution so much as explaining the code to implement it. So I am somewhat reluctant to defend the solution, here. This is a Wiki Post permitting collaboration overtime to make it clearer. However;
This solution within this code discussion provide the ability to place notes against any tiddler without touching that tiddler, the note is multi-line and can include wikitext. The notes are all stored in a single tiddler which can be dropped on another wiki, so may be helpful to documenting the core tiddlers, or to send to a wiki author for review.
Well this is the first example of pre-emptive publishing with code description. Its a first example and can be improved with contributions. Improved for the reader not necessarily the solution. But yes I wanted to publish before I moved address tomorrow.
I want the community to help me explore this way of discussing concise solutions in detail, with a view to making “explicit” tips and tricks that are often “implicit only”.
Perhaps this will inspire similar sharing of Tips and Tricks or inspire different solutions ?
This is one of many patterns illustrated in my post. Finding ways to make data tiddlers more accessible, eg keys by tiddler title and my get.note function.
Now I have managed to read the whole thread, I see that the solution within the Topic has inspired some ideas, which is one of my desired outcomes. But this experience also reminds me of that apparently a lot of people don’t carry their imagination with them all the time. For me when I see the smallest tip or an exemplar, of something I have not seen before, my imagination runs off to the possibilities. Or if you tell me something cant be done, I try to find a way it can be done.
it has being noted how a renamed tiddler will orphan a note, unlikely to be an issue against a core or plugin tiddler, but we need a solution for this to make it a somewhat complete pattern.
I think capturing and accounting for renaming events is certainly going to be your biggest challenge — and even Relink doesn’t catch all of them. For instance, try the following code in a new tiddler on the Relink demo site to see one instance in which Relink fails to update title references:
<$button>Rename...
<$list filter="[tag[Relink]]">
<br><$link/>
<$action-setfield $field="title" $value=`XX $(currentTiddler)$` />
<$action-deletetiddler $tiddler={{!!title}} />
<!-- when $action-setfield is used to "change" the value of a tiddler's title, it actually makes a copy of that tiddler under the new title. thus, we need to add $action-deletetiddler to remove the original. -->
</$list>
</$button>
And to be clear, I don’t think it’s fair to call this a failing of Relink; it’s not obvious to me how you would catch renaming events like this.
But let’s assume your average TW user isn’t as fond of action widgets as I am 
and they’re just renaming tiddlers in standard edit mode, with or without help from Relink. I think this is your lowest-hanging fruit, and it may still require some $:/core modifications. Here’s how I might approach it:
$:/tags/EditToolbar tag from the existing save button — this is, IMO, the unavoidable core overwrite. Currently, <<save-tiddler-actions>> is hardcoded into $:/core/ui/Buttons/save and defined — again, hardcoded — in $:/core/ui/EditTemplate, so I don’t see any room to redefine it via an external procedure.)[tag[YourDataTag]has:index{!!draft.of}]
{{!!draft.of}} to a new index {{!!draft.title}}, then delete the original {{!!draft.of}} index.Then, stretching a little further, I’d probably want to provide similar support for popular 3rd-party renaming tools like Commander. Again, you’d want to overwrite any buttons used to rename tiddlers with your own updated versions (and probably package the new tiddlers as part of a hypothetical “notes” plugin, along with the core changes and your original procedures/templates).
Belatedly, it occurs to me that if you weren’t determined to have index-updating happen invisibly, you could add a warning to the EditTemplate (as a new tiddler with the $:/tags/EditTemplate tag), akin to the one you already get about backlinks when renaming…
And you could then include your “update index names” button there, rather than trying to incorporate it into the core save button.
The downside, of course, is that you’d have to remember to click the “update” button manually before saving your draft… and if you clicked it and then canceled your draft edits, the index would again be divorced from its parent tiddler. So it’s not an ideal solution, and it wouldn’t be my preference… but it might be a stop-gap “solution” if you were determined not to modify any core tiddlers.
Thanks for the ideas, great minds think alike, or is it fools never differ?
I have raised this over here with @Flibbles and @pmario
Doing my own research it is a little more complex than you would expect initially. Rename can occur a number of ways, and all need to be handled, so it is actually part of the navigator widget and $:/core/ui/EditTemplate/title and the action messages
Yes, I was considering this.
If we think of the data tiddler as a repository and place a viewer on that tiddler, it may be enough to just indicate the missing tiddlers (now they are renamed) in fact it has a behaviour we may want, we can maintain notes on its previous name or even for deleted tiddlers.
All - I think I will move the discussions so far to a separate discussion thread to keep the Wiki post less intimidating.