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.
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
That sounds exactly right to me.
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.
This is only one example to create a UI on the fly! Your usecase is another example.
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.
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.
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
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?
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.
@etardiff and @Springer may have something to add here, in part because I think missing tiddlers are already close to virtual tiddlers.
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.)
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.
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. 
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.
Thank you for your clarification. From this user’s perspective, tags and system tags in TW are mysterious. Half tiddler, half missing. Mostly missing.