Apply ViewTemplate to multiple, unknown-in-advance tags

,
#1

Continuing from my previous efforts, I’d like to apply a ViewTemplate to numerous tags, unknown in advance. All the relevant tags will themselves be tagged with a common tag, kind. I thought about using the tagging operator as I did before, but it doesn’t work:

title: coffee
tags: kind

title: Americano
tags: coffee

title: tea
tags: kind

title: Earl Gray
tags: tea

Given the above, the following should be applied to Americano and Earl Gray because they’re both tagged with something that is itself tagged with kind

title: .templateItem
tags: $:/tags/ViewTemplate	
text:
<$list filter="[all[current]tag[kind]tagging[]]">  <!-- Does NOT work :-( -->

<!-- blah blah -->

</$list>

I thought the tagging operator would work similarly to how I used it before, but I’m obviously missing something. How should I build the above filter?

#2

Will making this small change work?

<$list filter="[all[current]tags[]tag[kind]]">

It’s hard to tell without an example.

#3

Unfortunately not, I think this change sets the current tiddler inside items to their kind, instead of themselves.

If you drop grubs.json (2.2 KB) on TiddlyWiki.com and open up the Americano tiddler, you’ll see what I mean. I thought {{!!title}} would say “Americano” but instead it says “coffee” i.e. its kind.

Using [all[current]tag[coffee]] on the ViewTemplate works as expected, but obviously only on coffees

#4

Ah, the problem is with your template. Try this:

<$list filter="[all[current]tags[]tag[kind]]" variable="kind">

* Item Title: {{!!title}}
* Item Kind: <<kind>>

Found on these Places:
<ul>
	<$list 
	filter="[tag[link]link-item{!!title}]">
			<li> <$link to={{!!link-source}}/>  --- <$link to={{!!title}}>🔗</$link></li>
	</$list>
</ul>

</$list>

Without the variable, the content within the list widget treats the TAG (which is what the filter lands on) as the current tiddler. The variable="kind" makes currentTiddler revert back to tracking what currentTiddler meant in the wider context.

Now you can access the kind either as {{!!kind}} or as <<kind>> — and the latter may be more powerful depending on what you go on to do with additional nested content.

#5

Is this correct, kind is not a field is it?

#6

Yup, that did the trick :+1:

I don’t think I would have found this by looking at the documentation or the forums. I’m still not sure how to describe it in a way I could search about it. Is there a specific terminology for this behavior, or a piece of documentation I would have to read to find it? Someplace I could read further about it?

The ListWidget page mentions the variable parameter but I can’t infer what happens when you change the default value of currentTiddler like you suggested:

The name for a variable in which the title of each listed tiddler is stored. Defaults to currentTiddler

#7

A lot of widgets and macros act on the currentTiddler variable by default, the $list widgets filter may return zero or more “titles” so by default the list repeats its content for each title found and setting the currentTiddler variable to each title.

However you can use variable=variablename to use another variable name for each item. An example may be a list filter such as [all[current]fields[]] which will list all fields on the current tiddler, so in this case it would make sense to use variable=fieldname, as a result of not using the currentTiddler (by default) it remains set to the “current tiddler”.

  • Then we can refer to both currentTiddler and fieldname, such as to edit or set a field
#8

You’re absolutely right. The behavior of <currentTiddler> should be made more explicit here. Probably in other places too.

Would you be willing to spend some time on figuring that out? It would be worth it to have your perspective in the documentation. If you edit the ListWidget, there will be a pinkish bar at the top that guides you through offering your suggested documentation changes back to the team.

#9

Perhaps not! Good eye, @TW_Tones!

I admit that I was assuming that it was, simply because of how OP @Lamnatos drafted the list-widget contents (since I didn’t see why else OP would have written {{!!kind}} and expected it to work).

But kind does NOT seem to have been defined as a field in the supplied downloadable json. And if kind is not a field, then the only way to access it is by looking at a tiddler’s tags and seeing which of those tags in turn carries the kind tag (which of course could in theory yield multiple positive results). So, something like the <<kind>> variable reference (or some filter expression that outputs the same thing) is the only way to access it, with the data structure as it stands.

For what it’s worth (addressing @Lamnatos here), my impression is that using tags is fast-and-easy when setting up a wiki for the first time, but to the extent a particular tag like “coffee” is really representing a structurally defined parameter (such as kind), and if a wiki is expected to grow in size and complexity, then using a named field for each important parameter may come to make sense.

Otherwise, as the wiki grows, the tag field may be asked to carry a wide array of signals — category-kinds (such as coffee) but also season-kinds (such as winter and summer) and source-kinds (import and domestic) and tasting-notes like “bitter” and ethnic-food associations “French” or “Thai” and in-stock vs out-of-stock and premium or economy (etc.) — in which case tagging all the tags, and having filters parse the extended list of tags to isolate those tags that are themselves tagged “kind” (or whatever else is doing the work relevant to your purposes here and now)… gets to be a headache.

But tags are indeed convenient, colorful, and user-friendly! And TiddlyWiki is designed to handle them efficiently.

And with a tool such as Commander available, people don’t have to worry as much about getting the ideal structure from the beginning. Make a basic TiddlyWiki, and then refactor it for greater power as needed. (And ask for further guidance, if you do find yourself crossing that bridge and want to create an optimal data-structure. :slight_smile: )

1 Like
#10

Thank you for the thoughtful reply. You’re right, there was no kind field. Having read your reply, there now is :wink:

I’m trying to transition to using a kind field for grouping. There’s some refactoring required and a few kinks to iron out, but I think it will make things simpler going forward, especially when adding new options and categorizing them just like you described.

#11

Cool! If you run into any questions, or any “Surely there’s an easier way…” moments, please do chime in again. Usually there is an easier way. :slight_smile:

1 Like