Create and Use of Virtual Tiddlers

I don’t see any contradiction here. None of them exist as actual stored tiddlers — they are all generated or computed at runtime. The difference may simply come down to the mechanism being used.

Since the original post is a wiki post, feel free to edit and improve it as you see fit.

I haven’t yet because I felt like our views were too radically different. It seemed to me that you were talking about something only vaguely related to my idea of a virtual tiddler. It seemed better to come to a consensus before starting an edit war.

However…

Interesting, because I still see your description very much at odds with my expectations.

Ok, that does match my conception of virtual tiddlers.

I would not expect there to be any general-purpose mechanism for their usage. They would vary substantially from wiki-to-wiki.

It feels as though you’re trying to explain the concept of virtual tiddlers by way of your—admittedly interesting—but far from universal “simple” system.

I read the following as if it was intended to be a general description of virtual tiddlers:

Key Features

  • A virtual tiddler is created using a button
  • The title of each virtual tiddler begins with the prefix: $:/virtual/

And if you only mean this to be a description of “simple”, then I think there only some minor cleanup of the text necessary, just to make that clear.

If, though, it is meant to be more generic, then I’m going to disagree strongly. A virtual tiddler is not necessarily created using a button. If fact I’ve never created them that way. Nor have I ever created one with the prefix $:/virtual.

To my mind, virtual tiddlers are placeholders for something I may want to create. On one recent project, I was collecting into a wiki scattered links to documentation about a large system at my day job. The form for entering one of them included an authors field, which I fill in with comma-separated list of names that get turned into a title list when the form is submitted. If I fill it in with a list like “Mohammad Rahmani, Scott Sauyet, Elise Springer”, when I view the saved tiddler, my template includes a list of authors:

* [[Mohammad Rahmani|Author/Mohammad Rahmani]]
* [[Scott Sauyet|Author/Scott Sauyet]]
* [[Elist Springer|Author/Elise Springer]]

And if I have already created Author pages for Mohammad and Elise, then you just visit them normally. But if I haven’t yet created one for Scott, you can still visit it. There is a notice that this tiddler hasn’t been created, and so there’s no biographical info on it. But there is a list of documents Scott has authored because I have a template for that which shows on any tiddler titled like Author/Full Name. And I have a sidebar/more tab similar to the “Missing” tab, which shows those authors linked to but not created.

To me that’s what virtual tiddlers are for. I would expect that in @Springer’s bibliography page, on importing a bibtex entry, she automatically adds links to the authors. If they don’t already exist yet, a template shows the works authored/edited. Tiddlywiki.com does this for non-existing Tag Tiddlers. My bingo page does something similar for card numbers.

The commonalities are that they derive information from the title of a nonexistent tiddler in order to apply certain templates to view it.

If your post is meant to capture all of these sorts of virtual tiddlers, then I think it falls far short. If you mean only to document the “simple” system, I think we probably only need a bit more clarification.

But I would also be curious to learn how you use these “simple” virtual tiddlers. I’m having a hard time imagining places where I would use them.

2 Likes

Don’t we already have an established concept for this? https://tiddlywiki.com/#Temporary%20Tiddlers

What is the difference betweehn temporary tiddlers and virtual tiddlers?

A temporary tiddler exists as a tiddler in memory, even if though it’s not stored.

A virtual tiddler does not even exist in memory. There is no JSON Operators tiddler. But if you ask the wiki to open it anyway, it shows you some useful information that can be gleaned just from the title.

1 Like

This is merely related to the approach I used. The reason, I used such title prefix, is to simply recognize them, for example in the open tab. Other reason is this approach allows to handle different scenarios just like TW does. The approach I described can be used for creating helper tools, like a temporary dynamic UI for making a print profile, or dynamic statistics, …

So consider it as one example. I see you have another approach, and it is really useful.

What we need to agree is the definition of virtual tiddler and I see we are very close, but the use cases and implementation approaches are different and this is useful.

This discussion is confusing me.

Is a VT (Virtual Tiddler) –

1 — any transient programmaticly spawned Tiddler;

2 — any Tiddler that is Un-saveable;

3 — a ghost.

AFAICT a virtual tiddler is a missing tiddler, to which a ViewTemplate is applied in order to make it behave like it would exist.

Here is an example I use in some TWs for tag tiddlers, virtual or not.

The cascade filter tiddler, tagged $:/tags/ViewTemplateBodyFilter:

[<currentTiddler>is[draft]then{!!draft.of}else<currentTiddler>tagging[]then[$:/tw-FRed/template/viewtemplate-tag]]

And the (simplified) ViewTemplate itself:

\define btnCreateActions()
<$action-createtiddler
  $basetitle=<<unusedtitle baseName:"$(titre)$" separator:"_">>
  $template={{!!@instance.template}}
  tags={{{[<titre>format:titlelist[]]}}}
>
<$action-sendmessage
  $message="tm-edit-tiddler"
  $param=<<createTiddler-title>>
/>
</$action-createtiddler>
\end


<$let titre={{{ [<currentTiddler>is[draft]then{!!draft.title}else<currentTiddler>] }}}>

!! Tiddlers tagged ''<<titre>>'':

<ul><$list filter="[<titre>tagging[]]"><li><$link/></li></$list></ul>
</$list>

<$button actions=<<btnCreateActions>> class="tc-btn-boxed">
{{$:/core/images/new-button}} Nouveau tiddler « <<titre>> »</$button>
</$let>

<$list filter="[<currentTiddler>!text[]]" variable=none>

---
<$transclude mode=block/>
</$list>

The filter first gets the real tiddler title, even in edit mode, then tests if it’s used to tag other tiddlers, then returns the ViewTemplate title.

The ViewTemplate displays a list of tagged tiddlers, a button to create a new tiddler (similar to “New here” view mode button) and, when the tag tiddler actually exists, displays its text field.

I find this useful with TOC sidebar tab: I can click any topic in the TOC and get a tiddler allowing me to add an item there, whether the tag tiddler is missing or not.

Fred

3 Likes

That sounds exactly right to me.

3 Likes

I see your description here as covering what your package does and how, but I’m not yet understanding why (what problem this kind of $:/virtual tiddler helps us solve).

For all the use-cases I’ve worked on over the years, the value of a virtual tiddler IS its name. It’s an author name, or a tag name, or a field name, or a field-value name, etc… It’s not “created” (by a button or otherwise), but it gets displayed in the story river because a tag-name link is clicked, or an creator-name, or some other field is designed to offers its contents as links, even though not all of them point to tiddlers.

It’s a “node” in tiddler-naming-space, and it’s valuable to show a template for that “virtual” tiddler (for that node) because the template can pull together some useful information for that meaningful node in tiddler name-space, even though there’s no such tiddler (yet). AND, since the node is already a meaningfully-titled node, it’s easy to invoke edit mode to add further details for this tiddler… Saving those changes makes it now real, and one wants it to be real as the helpfully-named tiddler with no special prefix. (Often, the template that showed for the missing tiddler is a kind of view template that will continue to apply to the real tiddler (as a helpful footer or dynamic table, etc.). But occasionally one may want some template to appear only so long as the node is empty ( = tiddler is virtual).)

Like @Scott_Sauyet I suspect that your solution here, @Mohammad, is using the concept of “virtual tiddlers” a bit differently (since I’m still baffled by the $:/virtual prefix — what purpose it serves).

So perhaps an example of how you’d use this $:/virtual approach (with examples that show what kind of problem it solves) would help us appreciate another dimension to what “virtual” could mean.

3 Likes

This is only one example to create a UI on the fly! Your usecase is another example.

Interesting idea @Mohammad

I do subscribe to more advanced use of missing tiddlers and this has a resonably rich set of discussions here in talk.tiddlywiki, these did come close to what I would call a virtual tiddler however I think I see where @Mohammad is comming from (Although I have not tested his solution yet).

It appears what we are talking about is more like virtual tiddlers in the story. Perhaps “virtual story tiddlers” that is they are not tiddlers but appear as such in the story and as a result serve as dynamic user interface objects.

  • From this you can see that they would make sense coming into existence through an action or button
  • Note that missing tiddlers typicaly appear to come into existence through following a link to a title, that does not yet exist.
    • which are rendered in the story with the custom body template and within which other content can be displayed.
    • However editing such a tiddler creates it, and it is no longer virtual.
  • This also suggests why they are (Mohamads) not like other virtual tiddlers such as missing tiddlers, arguably they are more virtual.
  • This mechanisium could be extended to introduce content within other elements than just the story river.

Personaly I would like a method other than the $:/virtual prefix or to introduce a version of my alt-title to for example use the caption as the tiddler title. Visiblle system tiddler titles, are to me “the code leaking through to the user environment” and in someways suggests something that is incomplete.

After testing

Given you can edit a virtual tiddler and becomes a real one, and it depends on its content from simple/Template/BodyTiddler I am not sure it differs from the missing tiddler approach which does the same with $:/language/MissingTiddler/Hint

  • I expect such tiddlers are not saved?

However, I think we could find a way to make even more virtual tiddlers as inspired by @Mohammad I just need to work out how?

1 Like

Some further thoughts.

As you may know there is a mechanisium in tiddlywiki to determin is[tiddler] is[missing] etc… I have hacked the core previously to add some custom tiddler types, and also to use an altenate namespace to $:/ and as for !is[system] you can exclude these from the default search mechanisium, thus such tiddlers can not be found (like system tiddlers) without advanced search.

  • Perhaps we could have is[virtual] and use a cascade to display them.
  • There is also mention of volatile and temp tiddlers not saved to the tiddler store with the wiki.
  • I think in some ways @Mohammad’s virtual tiddlers are more like tempoary tiddlers, because they will exist “In the story” after creation, but not after a reload (as I understand).

@etardiff and @Springer may have something to add here, in part because I think missing tiddlers are already close to virtual tiddlers.

  • Missing tiddlers could be “mentioned” in another tiddler eg: `[[missing tiddler name]]" which implies that such missing tiddlers should be constructed from a nominated “virtual tiddler template”. In which case all fields in the “virtual tiddler template” could be used to generate virtual tiddlers as mohamads solution enables.
1 Like

I realize I’ve dropped away from this thread, because the wiki at top seems to “bake in” the $:/virtual prefix idea, which I understand to be a very narrow variant on the broad power of virtual nodes.

I’m reluctant to edit your wiki, because I still don’t understand what motivates your interest in having a prefix-based namespace for virtual nodes.

Still, I want to chime in that much of my own recent work has indeed involved articulating the virtual-nodes powers of TiddlyWiki. (This is an approach that I’ve been exploring for years, and I believe I was among the first to have really dug in on this front, though I had not devoted much attention to providing a well-annotated demo, until now).

See this overview of my virtual node approach. And @Mohammad, if you’d like me to contirbute to the wiki above, I’m happy to do so. But I’m still unsure how to make my broader approach “fit” into the vision that you clearly had, since I don’t understand what meaning of “virtual” inspired you to offer a solution that does not begin with the power of the name of a node (directly leveraged for template-based information, links, dynamic tables, etc.).

Hi @Springer
I repeat my above post:

This is merely related to the approach I used. The reason, I used such title prefix, is to simply recognize them, for example in the open tab. Other reason is this approach allows to handle different scenarios just like TW does. The approach I described can be used for creating helper tools, like a temporary dynamic UI for making a print profile, or dynamic statistics, …

So consider it as one example. I see you have another approach, and it is really useful.

What we need to agree is the definition of virtual tiddler and I see we are very close, but the use cases and implementation approaches are different and this is useful.

For what it’s worth, I also love to have ways to recognize various facts about nodes as they’re listed in the open and recent menus. If I have lots of nodes open, it can be frustrating to scan for one, and in various ways I try make certain tiddlers stand out, visually. Having a linkstyle attached to some nodes is my current way of doing it.

In general, do you think a css solution would be sufficient (a certain border, or style — like we already have to recognize the difference between internal missing and resolving links, or between external and internal links, etc.)?

For that matter, merely having links to virtual tiddlers rendered in italics (already true of non-tiddler node names in the story river) does already serve to distinguish things in the story river that are not tiddlers, no? (Maybe it helps that I always turn on “display titles as links”, so I get the styling effect in the story river as well as in the sidebar.)

Anyway, would you be relaxed about my modifying the wiki and “demoting” the prefix idea (keeping it out of the “key features” overview), so that having a special prefix is mentioned much later as just one kind of virtual node?

(Tagnames and fieldnames strike me as the obvious cases of virtual nodes that really should by default have their ordinary names, whether in virtual or real-tiddler form. And these are the two useful kinds of virtual overview templates that have natural applications to almost any sufficiently-developed wiki.)

1 Like

5 posts were merged into an existing topic: [Proposal] Updating field handling functionality in TiddlyWiki

A post was merged into an existing topic: [Proposal] Updating field handling functionality in TiddlyWiki

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!)

!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. :clap: