I’ve read several threads which come close to my exact issue, but I haven’t come across any that tell me the exact solution, and it’s probably simple enough I’m hopeful someone will help elevate me from my ignorance!
I have a wiki with a bunch of tiddlers; for example, some are tagged “character”. For those “character” tiddlers, I have fields, including one field called “settlement” that shows where that character originates and a “source” which indicates which short story the character is from.
I was trying to put together a tiddler for the “settlements” which would list all the “character” tiddlers with that field, but so far I’m not successful. I can do it if I make the “settlements” different tags, but for aesthetic reasons I’m trying to limit tags so I don’t have 9 million tags for 900 tiddlers.
Am I approaching it badly from a design standpoint? Should I just do it as tags (“New York”, “London”, etc.) and be happy it works? I’d still like to know how to do the list to show hits from tiddlers with both a tag and a field, though.
That’s nice! I’ve tested it and I have a further question. So, I put “New York” in the fields as “[[New York]]” since that way it turned into a nice link in the bio I put in the body of the tiddler. That means it won’t match precisely “[settlement[New York]]”. Is there a way to sanitize the field entry to eliminate the brackets? If not, I can do a global search-and-replace using Tiddler Commander.
Also, I haven’t created most of the settlement tiddlers yet, since I wanted to try to get all the characters in first. Would there be a way to make a tiddler for a location and refer to the tiddler title for the “settlement” item? It doesn’t like using <> for field contents, apparently.
I use the following structure for a number of tiddlers - it creates a bulleted list with a third displayed item such as your “source”. You can use any iteration of it that you would like. It sorts by source. Hope this helps:
In general, I highly recommend not putting brackets into your field values, with the one exception being fields that hold lists of values (in which case, double-brackets go around multi-word items within the list).
It seems you’re worried about making sure that references to that field value turn up as links when you retrieve them with {{!!settlement}} notation…
There are various solutions. One is just to use filter notation (or triple-curly braces which are shorthand for “show filter output as links”), so that any value drawn from the field appears as a link:
{{{ [{!!settlement}] }}}
If you don’t want to strip the double-brackets, the other option is to use this alternate filter formulation, which is designed to work well with list fields:
{{{ [[New York]listed[settlement]] }}}
This should accomplish what you were (unsuccessfully) attempting with {{{ [settlement[New York]] }}} but it will capture the [[New York]] value, and will include a tiddler even if there are other values in that field (say, a character somehow must be associated with multiple settlements, so that the field value is [[New York]] Boston or something like that).
Please follow up with any further questions. Good design early in a project saves many headaches later on!
See, this is why I love this community. When I, an amateur (at best), come up with a problem, somebody will show me the right way to do it, and then let me play with the results. The responses here gave me three different ways to solve the same problem, and I really appreciate it! Now, to go ahead and apply best practices by removing the brackets in the fields – I thought I was clever when I did it, but I can see that I was laying traps for myself later on!
For anyone coming later who would like to do something similar, this is what my list code looks like. It generates a bulleted list of characters from New York, followed by their occupation (a field for each character tiddler). I’ll probably refine further as my needs change (I’m considering using a TW to track a read-through of The Wheel of Time – I have a terrible memory, and lose track sometime in book 6 of all of the myriad side characters) but this is a good start.
+[has[settlement]] is not needed since [get[settlement]] only returns tiddlers that have a non-blank value in the settlement field (i.e., it implicitly include a test for has[settlement])
Within the :filter[...] filter run, the <currentTiddler> is automatically set to each matching tiddler, so get[settlement] is equivalent to {!!settlement} (except that it produces a blank result if the settlement field is blank or does not even exist). Since you are then comparing to a specified field value, tiddlers with blank or missing settlement fields are filtered out.
To compare with an exact string match, you can use the simpler match[...] syntax instead of compare:string:eq[...]
In fact, you don’t even need the :filter[...] filter run at all, and you can write:
which tests if the specified fieldname matches the indicated value and returns the filter input value (i.e., the title of the tiddler that was passed into it) only if a match is found, which is exactly what the previous :filter[...] filter run was achieving.
Also note that any unrecognized filter operator (i.e., settlement[...]) is processed as if field:fieldname[...] was used. Thus, settlement[New York] is equivalent to field:settlement[New York], so the filter can be simplified even further to: