Thank you for your input and the revised wiki post. I prefer to keep my prefix $:/virtual in this special use case for several reasons. For instance, they are not editable (when the Utility plugin is installed), they differ from other missing tiddlers like non-existent tags in use, they don’t appear in normal searches (some searches return missing tiddlers), and they can be quickly and easily selected using [prefix[$:/virtual]], so for example I can use cascades to manipulate the title, tags, colors, etc. However, please note that this is just one use case I apply in my workflow, and it may differ from yours. It is not mandatory or intended to be a standard for all forms of virtual tiddlers.
1 Like
Of course, a prefix is one easy way to flag these nodes for cascade conditions.
I started out by composing cascade conditions for such purposes this way: [enlist{$:/StoryList!!list}!is[tiddler]!is[shadow]match<storyTiddler>] (plus whatever additional conditions I’m looking for) … in order to get at nodes that aren’t real tiddlers.
Then, wanting to get at these nodes easily, I created a function (tagged $:/tags/Global):
\function virt.node(tiddler:<<currentTiddler>>)
[enlist{$:/StoryList!!list}!is[tiddler]!is[shadow]match<tiddler>]
\end
This way I can have, in any view template (or wiki logic), a conditional bit that appears only if the node in question in not a tiddler. For example, in a template for tags:
<%if [virt.node<currentTiddler>] :filter[tagging[]] %>
The tag <<tag>> is not yet a real tiddler. You are looking at a virtual node based on the <<thisTiddler>> template, which offers the following overview…
<% endif %>
(I’m sure you’re familiar with all this, @Mohammad — just spelling out for folks visiting the thread still learning about such things!)
1 Like
!has[title] also works as a slightly shorter alternative to !is[tiddler]!is[shadow]: a shadow tiddler doesn’t pass is[tiddler], but it does have a title. (Conversely, I find has[title] very helpful in finding all extant tiddlers that match a given filter — whether they’re shadows or “real” tiddlers.)
Interesting! I’d never considered using enlist{$:/StoryList!!list} this way.
I imagine one advantage of your virt.node function over [<currentTiddler>!has[title]] (or just [!has[title]] in a ViewTemplate cascade filter, since the <<currentTiddler>> is implicit) is that it would allow you to include virtual nodes in the story river in other more complex filter operations — even outside the template used by the node itself. So if you wanted, for instance, a button that would operate on all the virtual nodes currently open in the river (e.g. to close them all at once, or open them all in external windows, or even to convert them all into real tiddlers), that would be simple to write. 
1 Like
I’m not sure what the purpose of a Virtual Tiddler is.
And: is what is a tag if it hasn’t been assigned a colour or any other field. Is a tag a virtual tiddler?
Tags are just keywords that can be assigned to tiddlers to provide semantic categorization or determine how the TWCore uses/displays those tiddlers (e.g., “system tags” such as $:/tags/Stylesheet to designate a tiddler containing CSS). Tag keywords don’t need to exist as tiddlers for them to be used… so yes, they can be thought of as “virtual tiddlers”.
However, in keeping with TiddlyWiki’s “everything is a tiddler” approach, you can create actual tiddlers whose titles are those tag keywords, which allows you to add extra information that affects the tag, such as assigning a color or setting a list field to customize the order in which tagged tiddlers are listed in the tag’s dropdown. When you use drag-and-drop to re-order a tag list, it automatically creates the corresponding “tag tiddler” in order to store the order in that tiddler’s list field.
2 Likes
Thank you for your clarification. From this user’s perspective, tags and system tags in TW are mysterious. Half tiddler, half missing. Mostly missing.
In some systems, nearly every tag lacks a real “home” tiddler (until and unless there’s a color choice, or a re-ordering of the tiddlers listed undet it). In my systems, I almost always do want to do things with my tags. Most of them (at least the important ones) are real tiddlers, with actual info, explanations, notes.
Even if I don’t put info there, though, I make sure that when I pick the name of my tag (from the top of the tag drop-down), what I see there in the story river (where the name of the tag is displayed as a virtual title) is as informative as possible — like a mini automatic index or x-ray of that tag.
1 Like
I do the same. I always want to give my tiddlers a life; even tag tiddlers.
But shouldn’t they be given existence anyway? Why aren’t they?
I find that with the right view templates, there’s no point in making a tiddler for the tag until/unless I want to add some further data or notes beyond what’s already “in there” (in the wiki overall). My view template (for all tags) includes a “how the wiki looks from here” overview of things under the tag. If we’re talking about a tag that doesn’t need a custom color, and doesn’t require some note-to-self about how to use it (or some special detail about what to include/exclude in an overview of its domain), then there’s no reason to add another line to the JSON for that tiddler. Putting the tag’s title in the story river is enough to “visit” the tag.
In the explanation by @Mohammad above — because of the details of his very specific approach — he spoke about “creating” the virtual tiddlers. But I think this may be misleading. Virtual-tiddler nodes are not so much “created”, as simply opened (added to the story river list).
Given that we already have “links” to tag titles (in the tag pill), all that needs to be created (at some point) is one or more template-based ways of getting interesting relevant things to display at these virtual-tiddler nodes. In simple cases (such as for tags where there’s no “home” tiddler), it may just be a conditional $:/tags/ViewTemplate template that’s equally useful for both real and virtual variants of tag nodes.
2 Likes